Why packages and namespaces?

João Eiras joao.eiras at gmail.com
Mon Feb 4 07:18:52 PST 2008


I'd vote for a runtime error like:

  Declaration of "var ecmascript" conflicts with
  existing package declaration "org.ecmascript".

This check would be made at runtime when the var declaration is ran.
This behavior would then be unambiguous, and would be compatible with
other programming languages.


2008/2/4, Johan Sundström <oyasumi at gmail.com>:
> On Jan 30, 2008 7:15 PM, T. Michael Keesey <keesey at gmail.com> wrote:
> > On Jan 30, 2008 9:35 AM, Jeff Dyer <jodyer at adobe.com> wrote:
> > > 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'
> > >
> > [...]
> > >
> > > What do you suggest we do differently?
> >
> > The obvious thing would be to change package reference syntax, e.g.,
> > by using a symbol other than periods. But this would break backwards
> > compatibility, so it's not an option.
> >
> > In prior cases of language ambiguity, an alternate syntax was created.
> > For example "Array(x)" was ambiguous, so "x as Array" was created as
> > another way to cast variables. Similarly, there could be an alternate
> > syntax for inline package references, e.g.,
> > "package(org.ecmascript).a".
>
> Or perhaps package["org.ecmascript"].a if that can be made to work
> syntactically.
>
> > This kind of seems like language bloat, though. In practice, just
> > about everyone uses capitalized camel-humped names for classes and
> > lower-case camel-humped names for fields and methods, so this issue
> > doesn't come up.
>
> I disagree; being able to clobber identifiers like this is just the
> kind of thing that is useful to malicious code, opening attack vectors
> on code by changing its meaning and function underfoot.
>
> And while this particular allegation might not constitute a
> designed-in security hole, I still consider it bad form to devise new
> orthogonal ways of populating the identifier namespace, without at the
> same time devising matching orthogonal ways of unambiguously
> traversing those structures.
>
> (The above reasoning is for the case where no imports have been made.
> >From my point of view, if you use import, you explicitly ask for
> clobbering your namespace. Not that I'd mind solutions to ambiguity
> cases that creep up there either, but it ranks lower on my issue
> meter. :-)
>
> --
>  / Johan Sundström, http://ecmanaut.blogspot.com/
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>



More information about the Es4-discuss mailing list