Aha.  I thought yours had a big security piece, and you're already
decided about imports etc.  I was thinking we could give Göran's
strategy (or something close to it) a try.

Anyway, I don't have anything against your solution.  I'm hopeful it
works out, but I'm a bit weary of the security focus.  Security is on
one side of a sliding scale and ease of use on the other.  I'm more
worried about ease of use for my dev environment.

But if it shows to be transparent to me as a developer then I think
your solution is probably the best on the table.

On 10/4/07, Michael van der Gulik <mikevdg at gmail.com> wrote:
>
>
> On 10/4/07, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> > Ok, I've stated my reasons why I don't like Göran's approach, now time
> > to give a suggestion myself:
> >
> > What if namespaces were just objects that behave like dictionaries
> > with the key being a string and value being a meta-class?
> >
> > They could be used as in:
> >
> > Seaside at: #Component
> >
> > or perhaps with a special shorthand:
> >
> > Seaside Component   "maybe Component needs a #?"
>
> This is exactly what my approach is. Namespace is a subclass of Dictionary.
>
> In a method, class definition or Workspace, you can use either either of:
>
> Seaside at: #Component. " Look it up at runtime "
> Seaside.Component "Look it up at compile time"
>
> I'm sure if you really wanted the "Seaside Component" notation, it would be
> possible for you to add this as well.
>
> Gulik.
>
>
> --
> http://people.squeakfoundation.org/person/mikevdg
> http://gulik.pbwiki.com/
>
>
>