:-)  Now add pumped message queues and future that reply value/exception to
the sending queue. The queues are bound to a particular process
(MorphicTask/Task) enabled by dynamically sending aSecretary foreground or
aSecretary background.   I need to sort out a viable impl.  (avoiding IP
issues)

Ahh..I just noticed your other message...been there, done that!  ;-)

I like to think of Spaces having different properties, and the external
references would build appropriate access actions based on those properties.
For instance: remote, persistent, different language environment...

more below

> -----Original Message-----
> From: Stephen Pair [mailto:spair at advantive.com]
> Sent: Wednesday, August 22, 2001 12:55 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Reflection in Squeak (was: RE: [GOODIE] 
> Delegation and Self
> like things for Squeak)
> 
> 
> 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).

Sure, why not.  Multiple ObjectMemories is an idea with shared GC  (first
come, first serve?) and SharedObjectMemory, between 2 OS Processes.

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

Mmm...yes, a problem.  I was thinking that when a JIT arrives, that we can
let that do inlining.  For that matter, what are the implications of
delegation with Jitter?

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

sigh...yes, this is the last core step I think.  I didn't really understand
Bob's example with <primitive:1> since I really wanted is:

addNum1: num1 num2: num2
	<multimethodPrimitive: 1>
	^ self primitiveFailed

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

Yes!  I have a SecretaryMap, with a default global secretary in the
foreground.  This allows me to pump the queues and stay process loyal.  In
my testing, I can run thousands of simultaneous asynchronous tasks (in the
background) and print to the Transcript without problems (well, morphic
refresh of overlapped windows causes problems).  All garbage is cleaned up,
too.

I am really happy that we are on the minnd meld, now.  I have such
difficulty in explaining what I envision.  Thanks!

- Rob
 
> - 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 
> > 
> > 
> > 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010822/93df6d3a/attachment.htm