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

> >>>>> "Michael" == Michael van der Gulik <[hidden email]> writes:
>
> Michael> Caveat emptor; there are bugs, but it does work. To prove it works,
> Michael> I've managed to make a screencast under Linux in beautiful high
> Michael> resolution, which Google video managed to munge into a pixellated
> Michael> mess:
>
> Michael> http://video.google.com/videoplay?docid=771491032612949488&hl=en
>
> Michael> (Excuse my heavy breathing.)
>
> Get a free vimeo.com account.  They allow HD uploads and playback now.
> Limited in uploads per week, but hey, if you're producing that much video, you
> don't need free any more. :)

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

> Oh, and also, i'm missing a code for a namespace definition. E.g. in
> same way as browser shows a code how to define new classes, it should
> show a code how namespaces are defined, like:
>
> Morphic addNamespace: #Kernel
>
> or, with predefined list of imports:
>
> Morphic addNamespace: #Kernel
> imports:  'Kernel.Objects Collections'
>
> or:
> Morphic addNamespace: #Kernel
> imports:  'Kernel.Objects<xx> Collections<yy>'

> On Wed, 16 Jul 2008 03:24:17 +0300
> "Igor Stasenko" <[hidden email]> 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.
>

> >> 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.
> >
>
> Sure, but in SecureSqueak, you always compiling code in some context -
> some instance of Namespace, which is first which will be asked for
> returning a symbol's associated value.
> So, for a file-ins you have to work out (if you don't have it already)
> the model, how to switch to different namespace, before compiling some
> code.
> In same manner, as you open 'Scoped workspace' , all fileins should be
> scoped as well.
> And since browser is scoped already, the code above should be
> interpreted just fine by compiler.

> One more thing is about namespace imports. I find it not quite
> convenient in having each namespace keep own imports.
>
> This could lead to complexity issues:
> Suppose package having 10 namespaces, and each one of them could have
> own list of imports. And there can be probability that two different
> namespaces importing two different versions of same package. This
> means, that by occasion, developer can make his package depending from
> some Package X v1, and Package X v2, which i think can't be his real
> intention :)

> So, the definition here is superfluous:
>
> IdentityDictionary subclass: #Namespace
> instanceVariableNames: 'name imports package fullyQuantifiedName parent'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Namespaces'
>
> it should be only:
>
> IdentityDictionary subclass: #Namespace
> instanceVariableNames: 'name parent'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Namespaces'
>
> fullyQuantifiedName can be computed based on name + parent(s).
> Also, i don't see a real need in having namespace directly pointing to
> package. Package is the root parent of namespace, isn't? So it can be
> computed at any time. Why referencing to it directly?

> On Wed, 16 Jul 2008 16:40:42 +0300
> "Igor Stasenko" <[hidden email]> wrote:
>
>> >> 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.
>> >
>>
>> Sure, but in SecureSqueak, you always compiling code in some context -
>> some instance of Namespace, which is first which will be asked for
>> returning a symbol's associated value.
>> So, for a file-ins you have to work out (if you don't have it already)
>> the model, how to switch to different namespace, before compiling some
>> code.
>> In same manner, as you open 'Scoped workspace' , all fileins should be
>> scoped as well.
>> And since browser is scoped already, the code above should be
>> interpreted just fine by compiler.
>
> Umm... thinking...
>
> Your code snippet above would be read as a chunk, and then compiled into a temporary class in a temporary method in the Kernel.Classes namespace, and then executed. It would make sense for the browser and scoped workspaces. It would certainly make some of the code there more elegant. The importer (when filing in) would somehow need to know that this particular chunk needed to be scoped in Kernel.Classes. Hmm. You'd need to implement some way of determining which context each chunk would be compiled and evaluated in. That would be a bit yuck.
>

> For now, I'll put a comment in CodeBuilder giving this as another option, and revisit this later. I need to think about it more; I have a funny gut feeling about this that I can't put my finger on.
>
>> One more thing is about namespace imports. I find it not quite
>> convenient in having each namespace keep own imports.
>>
>> This could lead to complexity issues:
>> Suppose package having 10 namespaces, and each one of them could have
>> own list of imports. And there can be probability that two different
>> namespaces importing two different versions of same package. This
>> means, that by occasion, developer can make his package depending from
>> some Package X v1, and Package X v2, which i think can't be his real
>> intention :)
>
> I was planning to let the tools deal with issues like this. It gets equally messy if you're working with multiple packages referring to different versions of other packages, so I was going to implement a "Upgrade all" method on the package manager to make sure everything referred to the latest versions of all packages in the package manager.
>
>> I think it would be better to make only packages having imports, and
>> regular namespace should have only parent.
>
> This has advantages and disadvantages. Thinking...
>
> If all imports were defined only on the package rather than individual namespaces, then management of package dependencies would be made a lot simpler, avoiding problems like you mention above and giving a very quick oversight of what dependencies the package has.
>
> However, this makes it harder to resolve an overloaded literal name. Say for example you have XML.Parser.Document and Network.Mime.Document. If a package wants to refer to both of these, it will need to refer to them using a fully quantified name rather than just "Document". This is no big deal, I guess, as the same would apply if classes in the same namespace wanted to do the same.
>
> I'm undecided. I can see the merit in your suggestion, and I'll give it some serious thought as I work with Namespaces some more.
>
>> So, the definition here is superfluous:
>>
>> IdentityDictionary subclass: #Namespace
>>       instanceVariableNames: 'name imports package fullyQuantifiedName parent'
>>       classVariableNames: ''
>>       poolDictionaries: ''
>>       category: 'Namespaces'
>>
>> it should be only:
>>
>> IdentityDictionary subclass: #Namespace
>>       instanceVariableNames: 'name parent'
>>       classVariableNames: ''
>>       poolDictionaries: ''
>>       category: 'Namespaces'
>>
>> fullyQuantifiedName can be computed based on name + parent(s).
>> Also, i don't see a real need in having namespace directly pointing to
>> package. Package is the root parent of namespace, isn't? So it can be
>> computed at any time. Why referencing to it directly?
>
> I agree on all of this. I'll add TODOs in my code and refactor it later. I want to push on with other parts of SecureSqueak for now.
>

> Compiler should always known in which environment it compiles a method.
> Then, it is up to environment to install and run the above code
> snippet in proper class/namespace.
> And you mistaken (or mislead) here: the above code should not use
> Kenel.Classes namespace.
>
> Lets imagine a following code chunk:
>
> -----------
> Packages addPackage: #Universe !   " a "
> Universe addNamespace: #Earth !  " b "
>
> !Universe beDefaultScope!  " c "
>
> Earth addClass: (  "d"
>    Kernel.Classes subclass: #House
>    type: 'normal'
>    instanceVariableNames: ''
>    classVariableNames: ''
> ).
> !
>
> !Earth beDefaultScope!  " e "
>
> !House methodsFor:.... blabla!  " f "
>
> .. here comes the House class methods..
> !
> !

> On Sat, 26 Jul 2008 10:24:54 +0300
> "Igor Stasenko" <[hidden email]> wrote:
>
> <snip - techy Namespaces stuff>
>
>> Compiler should always known in which environment it compiles a method.
>> Then, it is up to environment to install and run the above code
>> snippet in proper class/namespace.
>> And you mistaken (or mislead) here: the above code should not use
>> Kenel.Classes namespace.
>>
>> Lets imagine a following code chunk:
>>
>> -----------
>> Packages addPackage: #Universe !   " a "
>> Universe addNamespace: #Earth !  " b "
>>
>> !Universe beDefaultScope!  " c "
>>
>> Earth addClass: (  "d"
>>    Kernel.Classes subclass: #House
>>    type: 'normal'
>>    instanceVariableNames: ''
>>    classVariableNames: ''
>> ).
>> !
>>
>> !Earth beDefaultScope!  " e "
>>
>> !House methodsFor:.... blabla!  " f "
>>
>> .. here comes the House class methods..
>> !
>> !
>
> A few changes will need to be made to the above to make it work:
>
> ----------------
> " Packages need a persistent UUID that is used when imports are looked up. "
> " We assume that PackageManager can be seen in the current scope. "
> Package new;
>    name: #Universe;
>    uuid: '3ee26f83-58ee-4972-85ee-7e0b7e5ca691' );
>    addNamespace: #Earth;
>    " Add Kernel.Objects from the Kernel package as an import so Object can be referred to to make subclasses. "
>    addImport: ((PackageManager findPackageByUUID: '7b073ea1-aafb-443a-85fb-af673d2267f0') lookup: #'Kernel.Objects');
>    " Maybe the following could be: <<thisStream setContext: p>>? "
>    p beDefaultScope!  " I have no idea how beDefaultScope would actually be implemented... "
>

> Earth addClass: (
>   Object subclass: #House  "Classes makes subclasses. Kernel.Classes is a namespace. "
>   type: 'normal'
>   instanceVariableNames: ''
>   classVariableNames: ''
> ).
> !
>
> !Earth beDefaultScope!
>
> !House methodsFor:.... blabla!  " f "
>
> .. here comes the House class methods..
> !

>
> When I start refactoring Class, Behavior, etc for SecureSqueak, I'll be looking at how classes and namespaces would be defined. There might be security issues, so I'll need to think long and hard about it.
>
>> > I agree on all of this. I'll add TODOs in my code and refactor it later. I want to push on with other parts of SecureSqueak for now.
>> >
>>
>> I'm glad to see you taking my points into consideration :)
>
> Of course! It's free code review :-).
>
> Gulik.
>
> --
> Michael van der Gulik <[hidden email]>
>
>