Why packages and namespaces?

Jeff Dyer jodyer at adobe.com
Wed Jan 30 10:04:09 PST 2008


On 1/30/08 9:35 AM, Jeff Dyer wrote:

> 
> 
> 
> On 1/30/08 9:17 AM, Peter Michaux wrote:
> 
>> On Jan 28, 2008 12:04 AM, Peter Michaux <petermichaux at gmail.com> wrote:
>> 
>>> Here is a concrete problem. I tried this in the reference implementation...
>>> 
>>> package org {
>>>   public var ecmascript = {a: 1};
>>> }
>>> 
>>> package org.ecmascript {
>>>   public var a = 2;
>>> }
>>> 
>>> org.ecmascript.a   // 2
>>> 
>>> How do I access the "org.ecmascript.a" that has value 1?
> 
>    import org.*;
>    import org.ecmascript.*;
>    ... = org.ecmascript.a
>    ... = a
> 
> for example. The secret is in the lookup rules for packages: longest match
> works. Perhaps there is a bug in the reference implementation.

Sorry, I misread. Apparently the RI is doing the right thing in this
example. The way to make the package 'org' accessible is to give it higher
precedence than package 'org.ecmascript'. That should be possible by placing
its import directive in a narrower scope than 'import org.ecmascript.*'. Or
leaving the import of 'org.ecmascript' out of the program altogether.

Note: your program doesn't have import directives. It is a bug in the
language that packages that aren't imported are considered in the name
resolution process. (ticket #349 created)

Jd

> 
>>> 
>>> How does the programmer writing the org package know that his "a" will
>>> be clobbered by the "a" in the  org.ecmascript package?
> 
> He doesn't. But it's out of his hands since he can't know what code exists
> outside of his world that a user might intermingle with his.
> 
> Here's another example, which packages won't help with:
> 
>   import org.ecmascript.a;
>   var org = {ecmascript: 4}
> 
>   ... = org.ecmascript.a   // error: a is undefined in 'ecmascript'
> 
> The var 'org' shadows the first identifier in package 'org.ecmascript'.
> 
> This can be worked around by narrowing the scope of the 'import' so that it
> shadows the var 'obj'. At least that is what I would expect. Need to check.
> 
>>> point of packages to avoid this type of problem?
> 
> I'd say "to *help* avoid", yes.
> 
>> 
>> Is this not considered a big problem? It seems like one to me.
> 
> What do you suggest we do differently?
> 
> Jd
>> 
>> Peter
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es4-discuss
> 
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss




More information about the Es4-discuss mailing list