Avi Bryant <avi at beta4.com> wrote:
> 
> On Apr 15, 2004, at 6:13 AM, goran.krampe at bluefish.se wrote:
> 
> > IMHO it is pretty damn hard to make it any simpler than this.
> 
> So, looking through the code, one thing that strikes me as overly 
> complicated is all the various modifications around renaming.  Why are 
> they necessary?  I guess so that you can update the 'environment' 
> instance variable, but then, it's unnecessary too - why can't the 
> namespace of a class be a dynamic lookup?
> 
> Class>>namespace
>    ^ Namespace namedOrCreateForName: self name
> 
> I bet this would simplify a lot of code.

Yes, I agree. I just sortof saw the instvar environment and "went with
the flow". :) Good point.
As always "unneeded state" just makes things complex. It is of course
worth remembering that most of these things are only used at "compile
time" so CPU cycles are not at the same priority.

> It also seems odd to me that Namespace is still a subclass of 
> IdentityDictionary, but doesn't have any keys.  I think it should 
> *look* like a Dictionary (it would be nice if #keys and #do: worked, 
> for example), but it probably shouldn't actually be one.  I assume this 
> is left over from your previous implementation strategy.

Yes. I agree. It would be nice if they would work properly with an
inspector etc.

> After the various discussions about namespace granularity, I also 
> wonder at the choice to encourage the user (through the class creation 
> templates) to have one namespace per top-level category.  I'm not sure 
> exactly what we'll want in the long run, but this is probably too 
> fine-grained a default.

Yes, that may be so. We could try to remember the one used when creating
the previous class.

> Very neat to see this all working, though.

Yes, I think so. :) I am currently adapting Environment
class>>reorganizeEverything so that we can run a script to get a
somewhat sliced up image so that we can get a better feel for it.

> Avi

regards, Göran