Whoa!!!!!!!

I suddenly see what your after...incredible!  If you further associate
the current space with a Process (and switch this out when crossing
boundaries), then you can, at all times, know what space the receiver
currently resides (sort of an optimization of every object holding a
reference to the space).  If you clamp down (security wise) on
reflection, especially on these boundary references and on Process...you
should have everything you need to implement a security mechanism (among
other things).  Each user could have a number of spaces, each with
different security settings, and the ability to move owned objects from
one space to another.  Using this mechansim, you could specify security
down to the individual method level if that's what you need (then you
would have one space for one object).  This would be an optimized
implementation of a security mechanism where every object held it's own
security context.

The other thing that suddenly becomes possible is running multple VMs in
one object memory (to take advantage of SMP) or running a distributed
system where some objects are in a different physical object memory (but
I think that's exactly what you're after, is it not).

You have everything you need to mock it up now.  There are two things
that I can think of to watch out for:

- Messages that are not really sent, but optimized in bytecodes (i.e.
#class)
- Messages in ProtoObject (you could probably re-work the users of these
messages such an object responding to nothing could live nicely in
squeak...you could use Bob's technique for putting those primitives on a
different object)

- Stephen

P.S. in the Kats stuff, there is a modification to Process to allow it
to carry process specific contexts...it's also in Comanche

- Stephen

-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of
Withers, Robert
Sent: Wednesday, August 22, 2001 11:24 AM
To: 'squeak-dev at lists.squeakfoundation.org'
Subject: RE: Reflection in Squeak (was: RE: [GOODIE] Delegation and Self
like things for Squeak)


also embedded. 
> -----Original Message----- 
> From: Stephen Pair [mailto:spair at advantive.com] 
> Sent: Wednesday, August 22, 2001 7:39 AM 
> To: squeak-dev at lists.squeakfoundation.org 
> Subject: Reflection in Squeak (was: RE: [GOODIE] Delegation and Self 
> like things for Squeak) 
> 
> 
> See embedded comments. 
> 
> > -----Original Message----- 
> > From: squeak-dev-admin at lists.squeakfoundation.org 
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> > Behalf Of Rob Withers 
> > Sent: Wednesday, August 22, 2001 3:40 AM 
> > To: squeak-dev at lists.squeakfoundation.org 
> > Subject: Re: [GOODIE] Delegation and Self like things for Squeak 
> > 
> > 
> > oops.  I wrote: 
> > > Mirror would implement 
> > > ------ 
> > > delegate: selector arguments: argArray 
> > > 
> > >     ^ self reflectee delegate: selector arguments: argArray 
> > > ----- 
> > > 
> > 
> > but this doesn't do it.  I wanted to execute the delegate 
> > primitive, without implementing #delegate:arguments: in the 
> > Forwarder (that may be chained). Additionally, creating a 
> > mirror will slow it down. 
> 
> Right...we would need a new delegate primitive that didn't require a 
> message to be installed on the target (see more on this 
> below).  But, we 
> do have the delegate bytecodes!  You could doctor up a 
> CompiledMethod to 
> do what you need (the compiler won't generate any delegate bytecodes 
> just yet...and I'm not going to make it do so anytime soon)...in fact,

> the delegate bytecode would be the fastest solution and 
> wouldn't require 
> a new primitive.  Also, don't forget about "Mirror on: 
> someObject" which 
> avoids sending the #mirror message (in case you don't want to 
> implement 
> #mirror in your object).  If you are chaining these things, then you 
> probably would want to work through a mirror...you can avoid 
> creating a 
> mirror on every message if you hold onto the mirror instead of the 
> target object. 
I'm with you here...An example of doing this is in ProtoBehavior, where
you define the accessor and mutator methods for a new slot
(compileSlot:...).  That's some interesting code!  
This architecture of chaining managed references, especially now that we
ought to use a Mirror, was why I wanted the thinnest possible managed
reference.  Let's take three spaces (A, B, C) and an object (a) in space
A.  If we export the reference to space B, then we want to manage the
reference with an access manager to Space A.  So in space B, the
reference to a would be Forwarder to Space A manager on a, configured
for access from B, 
        Fb(a) := F(B->a) := F(Ma(B), a).  
If Space B then passes this reference to C, then we would have:  
        Fc(Fb(a)) := F(C->F(B->a)) := F(Mb(C), Fb(a)).  It would be nice
if we could resolve this to: Fc(a), since they ought to be identical,
and since there is no aspect of B filtering access to Fa.  Of course
there could be, if the access priviledges are degraded for C's use of B
references - C may not be able to access A.
> 
> > Is there a way to invoke a primitive against a different 
> > receiver, in Squeak?  For example, In a doIt, invoke 
> > <primitive: 1> and supply the 2 numbers - one the receiver 
> > and the other the argument. 
> > 
> > - Rob 
> 
> No...not unless you write a new primitive...which is what 
> I've done for 
> a few things that are required by Mirror to avoid sending a message to

> the reflectee.  In fact, there are a lot of things that you might want

> to invoke in this way.  I'm starting to believe that a lot of the very

> basic primitives should be re-implemented such that they do 
> not require 
> that the method be installed the subject.  However, this allows one to

> break encapsulation...but if we could find some way for an object to 
> restrict (or disable entirely) who is allowed to use reflection 
> primitives against it, I think it just may be the way to go. 
> 
Right...Primitives shouldn't push the receiver, but rather that would be
an explicit argument to the primitive method context.  Nice.
cheers, 
Rob 
> There are some basic operations in Squeak that require the ProtoObject

> protocol, those operations could be re-written such that if 
> the message 
> they are sending isn't implemented, then they fall back on a 
> reflection 
> primitive (like #== for example).  Certain operations that really need

> the method natively implemented would not send the message to 
> the object 
> at all, and use the reflection primitive instead (like #nextObject for

> example...that one absolutely has to return an answer appropriate for 
> itself, or infinite looping can happen (or inaccurate results from a 
> references search)). 
> 
> - Stephen 
> 
> 
>