Hi Stef,

> > Very simple to do (both in theory and praxis) but what do 
> > you replace it with once they are removed? "Namespace variables"
> > seem like a somewhat ... err .. abstract concept to me which
> > may turn out harder to explain than class variables or pools.
> 
> It depends in the Smalltalk of lars bak he has:
> 	a class is defined in a namespace and you can define 
> variable in namespace too.
> 	He does not have any pool or classVar.

Is this available somewhere? I'm curious how classes can share (essentially
static) information in this system. Also, is each class defined in its _own_
namespace or is sharing achieved by defining the classes in a common
namespace? And does one then import namespaces if the same information is
needed from two (disjunct) name spaces?

> > But how do you deal with (intentional) sharing and (intentional) 
> > locality?
> 
> Only namespace would offer that. And may be we need to keep classVar.
> Thanks for the question.
> 
> BTW:
> Character>>initialize
> 	"Create the table of unique Characters. This code is 
> not shown so that the user can not destroy the system by
> trying to recreate the table."
> 	
> How can I see this method....I found that really frustrating.
> I tried Character class sourceMethodAt: #initialize but 
> without success.

The code for this method isn't even there. Though it seems odd to me - it'd
be trivial to write it as
	CharacterTable ifNil:[...]
and not having the initialization code around doesn't really prevent us from
destroying the character table either.

> >> Then Pool are really ugly and static (try to change the value of
> >> a pool variable and see how the method refering to it can break :))
> >
> > How do "namespace variables" address this problem?
> 
> they have nothing magic if you do not have pool variables whose value
> are computed at compiled time and put in the compiled method 

This isn't the case in Squeak. Your compiled method contains the _binding_
and not the _value_ of the variable - otherwise things like:

Foo>>default
	^Default ifNil:[Default := self new]

wouldn't work. So while the bindings are static, their value is not. For
pools, essentially the same is true but changing the pools can have nasty
side effects since you're not removing just a single binding but a whole set
of them. That's kinda like removing _all_ of the class vars and the tools
are rather dumb when it comes to these changes.

Incidentally, I don't really see how namespace variables would address this
problem either. To me, it seems more a question of working style and tool
support than one of the "variable types" (though I would agree that having
less variable types is likely to give us better tool support too ;)

> (I should replay with these to be sure but in VW it was like that),
> but only have message send or variable access then you do not get
> the problem

Actually, you do. The above is conceptually the same as (for example)
removing an instance variable. Try to remove all instance variables from
Morph and see how far this gets you ;-) The difference is that the tools are
much more geared towards "other than pools" as (for example) they don't tell
you all the "references to a pool" variable. But there's really no reason
they couldn't do this. Just for the heck of it I've added a little inquiry
which allows you to ask queries like

(SystemNavigation new)
	browseAllReferencesToPool: B3DEngineConstants from: B3DRenderEngine.

(SystemNavigation new)
	browseAllReferencesToPool: #TextConstants from: ParagraphEditor

Hooked up properly to the UI this provides the same "level of safety" which
you have with other kinds of variables. For example, the browser could check
if the pool bindings of some (removed) pool are still in use and offer you
the choice to remove it.

Cheers,
  - Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BrowsePools-ar.2.cs
Type: application/octet-stream
Size: 1304 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030907/c144801a/BrowsePools-ar.2.obj