Environment?

Hi.

I see this class hierarchy:

...IdentityDictionary etc.
    SystemDictionary
       Environment
          SmalltalkEnvironment

What are they? I understand that #Smalltalk of class SystemDictionary is
a singleton and a global variables holder, used by the compiler to add
Associations pointing to global variables in method dictionaries for
classes.

But Environment? When was it made? What were the original intentions?
Does it work and is it stable and safe to use?

And what is SmalltalkEnvironment used for? It appears to be an
uncommented empty class.

I'm trying to create a secure, segregated Smalltalk environment in my
image where remotely loaded code has no references to objects that I
don't want it to have (aka "capabilities" ala the E language).

Mikevdg.

On 21.02.2006, at 22:48, Michael van der Gulik wrote:

It was a first experiment for namespaces in Squeak a long time ago.  
Needs to be cleaned up.

> And what is SmalltalkEnvironment used for? It appears to be an  
> uncommented empty class.
>

It's not used.

> I'm trying to create a secure, segregated Smalltalk environment in  
> my image where remotely loaded code has no references to objects  
> that I don't want it to have (aka "capabilities" ala the E language).
>

You should have a look at the Island work of Andreas for Croquet,  
there was a mail to squeak-dev some month ago describing a first  
version.

    Marcus

Thanks for the quick reply, Marcus!

Marcus Denker wrote:
...how did it get into the "production" image if it was an
experiment!!?? Shouldn't experiments be done on experimental images, and
when they are stable, only then add them to the "production" image?

>> I'm trying to create a secure, segregated Smalltalk environment in  my
>> image where remotely loaded code has no references to objects  that I
>> don't want it to have (aka "capabilities" ala the E language).
>
> You should have a look at the Island work of Andreas for Croquet,  there
> was a mail to squeak-dev some month ago describing a first  version.

Yes, I've read a bit about it and I should really look at his code.

I'm interested in how Andreas managed to lock down the image.

The following is only out of interest, and I'm not asking any
questions... I can work out most of this by playing around.

I've just done the following little experiment using the following code
on the class side of ProtoObject:

allReferences
        | literalCollection |
        " Return all references that I have to other objects. Used only for
playing around with the image. "
        literalCollection := Dictionary new.
        methodDict valuesDo: [ :eachCompiledMethod |
                eachCompiledMethod literals do: [ :eachLiteral |
                        (eachLiteral isKindOf: LookupKey) ifTrue: [
                                literalCollection at: (eachLiteral key) put: (eachLiteral value).
                        ].
                ].
        ].
        ^ literalCollection.

(yea, okay it could have been done with collect: or something...)

What is revealing is the following:

ProtoObject allReferences ----> a Dictionary(#Array->Array
#ContextPart->ContextPart #Error->Error
#MessageNotUnderstood->MessageNotUnderstood #Smalltalk->a
SystemDictionary(lots of globals) )

For my purposes, all of these will need to be removed or replaced with
distributable objects... somehow... hmm...

[Object allReferences] is too big to cut and paste here, but includes
such wonderful things as #CardPlayer->CardPlayer and #ScriptingSystem->a
StandardScriptingSystem.

Also, adding the same method to Metaclass also shows the list of
class-side global references.

The big picture here is that I'm trying to move Classes (including
MethodDictionary-s, CompiledMethod-s and all the Association-s to other
objects they have) to remote systems over a network.

Regards,
Mikevdg.

On 22.02.2006, at 00:16, Michael van der Gulik wrote:


This is from the old days, when there was only an experimental image.

But actually I am not that strictly against experimental code... the  
only problem the old scheme had was that *nothing* was ever cleaned
up. Demo hack after Demo hack, experiment on top of experiment, until  
it collapses.

This is clearly not he right strategy. But now the other extreme:  
"only perfect solutions" is not the way to go, either. This way we soon
have the problem that we can't do anything, as nothing is ever really  
perfect.

Refactor mercilessly: http://www.extremeprogramming.org/rules/ 
refactor.html

It was no problem to add that code. The problem is that is was not  
removed after it became clear that this path would not be followed.

      Marcus