On Sat, 26 Jul 2008 10:24:54 +0300
"Igor Stasenko" <siguctua at gmail.com> 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..
!
!(Earth package lookup: 'Something.Somewhere') beDefaultScope! " Go somewhere else in the package to define more namespaces / classes / methods. "
!
----------------

I'm tempted to invent some sort of script format for Squeak that uses variables, so that packages like this can be stored as scripts that are simply executed.

For the meanwhile, however, I'm not going to change the format that I currently have. Yes, it is ugly and stupid, but it is intended to be a temporary measure and it works for now. I don't like chunk format; I don't like files in general. Code should be a bunch of objects in images that can be passed, as objects, to other images. Computers should have persistent object stores, not filesystems!lopp is a well-developed squeak-based image app

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 <mikevdg at gmail.com>