2008/7/27 Michael van der Gulik <mikevdg at gmail.com>:
> 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... "
>

Could be more elegant single send, like :

( PackageManager
       addPackage: #Universe
       uuid: ...
       namespaces: #(
          #A
          #B
          #C )
       imports: #(
          uuid
          uuid ... )  ) beDefaultScope

there can be a lot of variants.. :)
Just, don't let PackageManager be shadowed by greedy namespace.


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

You don't need it.
A scoping should follow the chuck format scoping e.g:
----
!SomeNamespace beDefaultScope!
  " here we in  SomeNamespace scope "

!SomeSubNamespace beDefaultScope!
   " here we in sub namespace scope "
!
  " here we back again in SomeNamespace scope "
!
----
So, before entering a sub-chunk, simply remember the outer scope:

evalChunk: aChunk
    oldEnv := Compiler currentEnvironment.
    Compiler evaluate: aChunk.
    Compiler currentEnvironment: oldEnv.

and Namespace>>beDefaultScope  can be just:

Compiler currentEnvironment: self.


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

May the God hear your words!
But we live in file-based reality :) So, we need to interact with it somehow.


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



-- 
Best regards,
Igor Stasenko AKA sig.