>> 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?

Lars will release a non-commercial version soon (around 
november-december)

> I'm curious how classes can share (essentially
> static) information in this system.

He has a :: notation to access variable or classes in other namespaces.
I'm not sure that I like that.

> Also, is each class defined in its _own_
> namespace

No

> or is sharing achieved by defining the classes in a common
> namespace?
Yes

In fact class and namespace are the same and we had a lot of 
discussions especially at breakfast ;)
  because I think that this is a mistake because you use then a class as 
a module and you can end up
having nested classes.

I think that at implementation level, doing that is ok but not at the 
language design level.

We also tried to convince him that havinf class extension is important 
because this is orthogonal
and provide a cheap and really powerful package mechanism (try a 
visitor in java).

> And does one then import namespaces if the same information is
> needed from two (disjunct) name spaces?

Yes I have the impression. His ideas were to really target C 
programmers and to have the simpliest model
he could think of. So no import just direct reference with absolute and 
relative paths.


>
>>> 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.

Exact. Where is this code then?

>>>> 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 classVariable this is the same in VW

In VW30 I got a lot of problem
because if I had a PoolDict with myPoolVar in

Then
method1
....

	myPoolVar

was containing the value that myPoolVar got at compiled time and I 
found that
features crashing my code a lot.

I saw that in Squeak people use

	PoolDict at: #myPoolVar  instead of directly myPool in the method body
Is this required or just a style?

>  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.

;( I can imagine, in VW the browser just opened a lot of debuggers :)

> 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 really have to have a look inside because I do not understand why 
changing
the value of one poolvar requires to invalidate all the other bindings.
Do you know the reason?
>
>> (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.

Exact
For me this was more the static aspect of Pool that I hated not really 
the lack of tool support.

>  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.

I agree. I was referring to staticness of pool.

In fact I was wondering why lars introduced namespace in a mini 
smalltalk and this is because he needed a
place to add privacy and support "static-global" variables. This was 
really interesting to think about that.

Stef

> Cheers,
>   - Andreas
> <BrowsePools-ar.2.cs>