[squeak-dev] Namespaces, Packages: Image available for download, screencast.

Michael van der Gulik mikevdg at gmail.com
Wed Jul 16 05:01:03 UTC 2008


On Wed, 16 Jul 2008 03:24:17 +0300
"Igor Stasenko" <siguctua at gmail.com> wrote:

> Cool screencast Michael! :)

Thanks. It was actually more difficult than I thought; thinking and talking at the same time is hard!

> I have played with it few minutes to look how it doing things.
> 
> One thing, which i don't like is how looks a class declaration:
> 
> self inNamespace: 'Kernel.Classes'
> 	createClass: 'ClassCommentReader'
> 	ofType: 'normal'
> 	superclass: 'ClassCategoryReader'
> 	instanceVariableNames: ''
> 	classVariableNames: ''
> 
> to what 'self' refers to?

Er... usually an instance of CodeBuilder.
 
> Do you plan to allow creating classes by subclassing existing ones,
> e.g. by sending a messages to them, like in regular smalltalk?

That could be done; I'm not particularly happy with the syntax myself. It is not very Smalltalkish.

I think my original idea was to put an absolute minimum of functionality in Class, ClassDescription and Behavior for <waves hands in air> security. I think that may have been a bit misguided, because being able to make a subclass is possibly a benign operation.

Also, it keeps all code definition methods in one class, so that at some stage later, that class (CodeBuilder) could be used as a capability.

For now, the code is there and works and can be refactored later. I want to get SecureSqueak working first, and then I'll revisit ugly things like this.

> To my understanding, the above should look like:
> 
> Kernel.Classes addClass: (
>    Kernel.Classes.ClassCategoryReader subclass: #ClassCommentReader
>    type: 'normal'
>    instanceVariableNames: ''
>    classVariableNames: ''
> ).

This looks much more logical, but the problem here is that all globals need a context, meaning that any packages, namespaces, classes and shared variables that you refer to need to be included in the import list of the importer. That could be done, but it is less elegant than what I did above.

> This indicates two separate concepts involved here: namespaces
> (Kernel.Classes) and subclassing by sending message to existing class.
> And #addClass: here is just a convenience method, which can look like:
> 
> Namespace>> addClass: aClassObject
>    ^ self addSymbol: aClassObject name value: aClassObject
> "or, more smalltalk-ish"
>   ^ self at: aClassObject name put: aClassObject

Namespace>>addClass: already exists and does exactly that :-).

Gulik.

-- 
Michael van der Gulik <mikevdg at gmail.com>



More information about the Squeak-dev mailing list