<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Reflection in Squeak (was: RE: [GOODIE] Delegation and Self like things for Squeak)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>:-) 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)</FONT></P>
<P><FONT SIZE=2>Ahh..I just noticed your other message...been there, done that! ;-)</FONT>
</P>
<P><FONT SIZE=2>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...</FONT></P>
<P><FONT SIZE=2>more below</FONT>
</P>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Stephen Pair [<A HREF="mailto:spair@advantive.com">mailto:spair@advantive.com</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Wednesday, August 22, 2001 12:55 PM</FONT>
<BR><FONT SIZE=2>> To: squeak-dev@lists.squeakfoundation.org</FONT>
<BR><FONT SIZE=2>> Subject: RE: Reflection in Squeak (was: RE: [GOODIE] </FONT>
<BR><FONT SIZE=2>> Delegation and Self</FONT>
<BR><FONT SIZE=2>> like things for Squeak)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Whoa!!!!!!!</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I suddenly see what your after...incredible! If you further associate</FONT>
<BR><FONT SIZE=2>> the current space with a Process (and switch this out when crossing</FONT>
<BR><FONT SIZE=2>> boundaries), then you can, at all times, know what space the receiver</FONT>
<BR><FONT SIZE=2>> currently resides (sort of an optimization of every object holding a</FONT>
<BR><FONT SIZE=2>> reference to the space). If you clamp down (security wise) on</FONT>
<BR><FONT SIZE=2>> reflection, especially on these boundary references and on </FONT>
<BR><FONT SIZE=2>> Process...you</FONT>
<BR><FONT SIZE=2>> should have everything you need to implement a security </FONT>
<BR><FONT SIZE=2>> mechanism (among</FONT>
<BR><FONT SIZE=2>> other things). Each user could have a number of spaces, each with</FONT>
<BR><FONT SIZE=2>> different security settings, and the ability to move owned </FONT>
<BR><FONT SIZE=2>> objects from</FONT>
<BR><FONT SIZE=2>> one space to another. Using this mechansim, you could </FONT>
<BR><FONT SIZE=2>> specify security</FONT>
<BR><FONT SIZE=2>> down to the individual method level if that's what you need (then you</FONT>
<BR><FONT SIZE=2>> would have one space for one object). This would be an optimized</FONT>
<BR><FONT SIZE=2>> implementation of a security mechanism where every object </FONT>
<BR><FONT SIZE=2>> held it's own</FONT>
<BR><FONT SIZE=2>> security context.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The other thing that suddenly becomes possible is running </FONT>
<BR><FONT SIZE=2>> multple VMs in</FONT>
<BR><FONT SIZE=2>> one object memory (to take advantage of SMP) or running a distributed</FONT>
<BR><FONT SIZE=2>> system where some objects are in a different physical object </FONT>
<BR><FONT SIZE=2>> memory (but</FONT>
<BR><FONT SIZE=2>> I think that's exactly what you're after, is it not).</FONT>
</P>
<P><FONT SIZE=2>Sure, why not. Multiple ObjectMemories is an idea with shared GC (first come, first serve?) and SharedObjectMemory, between 2 OS Processes.</FONT></P>
<P><FONT SIZE=2>> You have everything you need to mock it up now. There are two things</FONT>
<BR><FONT SIZE=2>> that I can think of to watch out for:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> - Messages that are not really sent, but optimized in bytecodes (i.e.</FONT>
<BR><FONT SIZE=2>> #class)</FONT>
</P>
<P><FONT SIZE=2>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?</FONT></P>
<P><FONT SIZE=2>> - Messages in ProtoObject (you could probably re-work the </FONT>
<BR><FONT SIZE=2>> users of these</FONT>
<BR><FONT SIZE=2>> messages such an object responding to nothing could live nicely in</FONT>
<BR><FONT SIZE=2>> squeak...you could use Bob's technique for putting those </FONT>
<BR><FONT SIZE=2>> primitives on a</FONT>
<BR><FONT SIZE=2>> different object)</FONT>
</P>
<P><FONT SIZE=2>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:</FONT></P>
<P><FONT SIZE=2>addNum1: num1 num2: num2</FONT>
<BR> <FONT SIZE=2><multimethodPrimitive: 1></FONT>
<BR> <FONT SIZE=2>^ self primitiveFailed</FONT>
</P>
<P><FONT SIZE=2> </FONT>
<BR><FONT SIZE=2>> - Stephen</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> P.S. in the Kats stuff, there is a modification to Process to allow it</FONT>
<BR><FONT SIZE=2>> to carry process specific contexts...it's also in Comanche</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>I am really happy that we are on the minnd meld, now. I have such difficulty in explaining what I envision. Thanks!</FONT>
</P>
<P><FONT SIZE=2>- Rob</FONT>
<BR><FONT SIZE=2> </FONT>
<BR><FONT SIZE=2>> - Stephen</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: squeak-dev-admin@lists.squeakfoundation.org</FONT>
<BR><FONT SIZE=2>> [<A HREF="mailto:squeak-dev-admin@lists.squeakfoundation.org">mailto:squeak-dev-admin@lists.squeakfoundation.org</A>] On Behalf Of</FONT>
<BR><FONT SIZE=2>> Withers, Robert</FONT>
<BR><FONT SIZE=2>> Sent: Wednesday, August 22, 2001 11:24 AM</FONT>
<BR><FONT SIZE=2>> To: 'squeak-dev@lists.squeakfoundation.org'</FONT>
<BR><FONT SIZE=2>> Subject: RE: Reflection in Squeak (was: RE: [GOODIE] </FONT>
<BR><FONT SIZE=2>> Delegation and Self</FONT>
<BR><FONT SIZE=2>> like things for Squeak)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> also embedded. </FONT>
<BR><FONT SIZE=2>> > -----Original Message----- </FONT>
<BR><FONT SIZE=2>> > From: Stephen Pair [<A HREF="mailto:spair@advantive.com">mailto:spair@advantive.com</A>] </FONT>
<BR><FONT SIZE=2>> > Sent: Wednesday, August 22, 2001 7:39 AM </FONT>
<BR><FONT SIZE=2>> > To: squeak-dev@lists.squeakfoundation.org </FONT>
<BR><FONT SIZE=2>> > Subject: Reflection in Squeak (was: RE: [GOODIE] Delegation </FONT>
<BR><FONT SIZE=2>> and Self </FONT>
<BR><FONT SIZE=2>> > like things for Squeak) </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > See embedded comments. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > > -----Original Message----- </FONT>
<BR><FONT SIZE=2>> > > From: squeak-dev-admin@lists.squeakfoundation.org </FONT>
<BR><FONT SIZE=2>> > > [<A HREF="mailto:squeak-dev-admin@lists.squeakfoundation.org">mailto:squeak-dev-admin@lists.squeakfoundation.org</A>] On </FONT>
<BR><FONT SIZE=2>> > > Behalf Of Rob Withers </FONT>
<BR><FONT SIZE=2>> > > Sent: Wednesday, August 22, 2001 3:40 AM </FONT>
<BR><FONT SIZE=2>> > > To: squeak-dev@lists.squeakfoundation.org </FONT>
<BR><FONT SIZE=2>> > > Subject: Re: [GOODIE] Delegation and Self like things for Squeak </FONT>
<BR><FONT SIZE=2>> > > </FONT>
<BR><FONT SIZE=2>> > > </FONT>
<BR><FONT SIZE=2>> > > oops. I wrote: </FONT>
<BR><FONT SIZE=2>> > > > Mirror would implement </FONT>
<BR><FONT SIZE=2>> > > > ------ </FONT>
<BR><FONT SIZE=2>> > > > delegate: selector arguments: argArray </FONT>
<BR><FONT SIZE=2>> > > > </FONT>
<BR><FONT SIZE=2>> > > > ^ self reflectee delegate: selector arguments: argArray </FONT>
<BR><FONT SIZE=2>> > > > ----- </FONT>
<BR><FONT SIZE=2>> > > > </FONT>
<BR><FONT SIZE=2>> > > </FONT>
<BR><FONT SIZE=2>> > > but this doesn't do it. I wanted to execute the delegate </FONT>
<BR><FONT SIZE=2>> > > primitive, without implementing #delegate:arguments: in the </FONT>
<BR><FONT SIZE=2>> > > Forwarder (that may be chained). Additionally, creating a </FONT>
<BR><FONT SIZE=2>> > > mirror will slow it down. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Right...we would need a new delegate primitive that didn't </FONT>
<BR><FONT SIZE=2>> require a </FONT>
<BR><FONT SIZE=2>> > message to be installed on the target (see more on this </FONT>
<BR><FONT SIZE=2>> > below). But, we </FONT>
<BR><FONT SIZE=2>> > do have the delegate bytecodes! You could doctor up a </FONT>
<BR><FONT SIZE=2>> > CompiledMethod to </FONT>
<BR><FONT SIZE=2>> > do what you need (the compiler won't generate any delegate </FONT>
<BR><FONT SIZE=2>> bytecodes </FONT>
<BR><FONT SIZE=2>> > just yet...and I'm not going to make it do so anytime </FONT>
<BR><FONT SIZE=2>> soon)...in fact,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > the delegate bytecode would be the fastest solution and </FONT>
<BR><FONT SIZE=2>> > wouldn't require </FONT>
<BR><FONT SIZE=2>> > a new primitive. Also, don't forget about "Mirror on: </FONT>
<BR><FONT SIZE=2>> > someObject" which </FONT>
<BR><FONT SIZE=2>> > avoids sending the #mirror message (in case you don't want to </FONT>
<BR><FONT SIZE=2>> > implement </FONT>
<BR><FONT SIZE=2>> > #mirror in your object). If you are chaining these things, </FONT>
<BR><FONT SIZE=2>> then you </FONT>
<BR><FONT SIZE=2>> > probably would want to work through a mirror...you can avoid </FONT>
<BR><FONT SIZE=2>> > creating a </FONT>
<BR><FONT SIZE=2>> > mirror on every message if you hold onto the mirror instead of the </FONT>
<BR><FONT SIZE=2>> > target object. </FONT>
<BR><FONT SIZE=2>> I'm with you here...An example of doing this is in </FONT>
<BR><FONT SIZE=2>> ProtoBehavior, where</FONT>
<BR><FONT SIZE=2>> you define the accessor and mutator methods for a new slot</FONT>
<BR><FONT SIZE=2>> (compileSlot:...). That's some interesting code! </FONT>
<BR><FONT SIZE=2>> This architecture of chaining managed references, especially </FONT>
<BR><FONT SIZE=2>> now that we</FONT>
<BR><FONT SIZE=2>> ought to use a Mirror, was why I wanted the thinnest possible managed</FONT>
<BR><FONT SIZE=2>> reference. Let's take three spaces (A, B, C) and an object </FONT>
<BR><FONT SIZE=2>> (a) in space</FONT>
<BR><FONT SIZE=2>> A. If we export the reference to space B, then we want to manage the</FONT>
<BR><FONT SIZE=2>> reference with an access manager to Space A. So in space B, the</FONT>
<BR><FONT SIZE=2>> reference to a would be Forwarder to Space A manager on a, configured</FONT>
<BR><FONT SIZE=2>> for access from B, </FONT>
<BR><FONT SIZE=2>> Fb(a) := F(B->a) := F(Ma(B), a). </FONT>
<BR><FONT SIZE=2>> If Space B then passes this reference to C, then we would have: </FONT>
<BR><FONT SIZE=2>> Fc(Fb(a)) := F(C->F(B->a)) := F(Mb(C), Fb(a)). It </FONT>
<BR><FONT SIZE=2>> would be nice</FONT>
<BR><FONT SIZE=2>> if we could resolve this to: Fc(a), since they ought to be identical,</FONT>
<BR><FONT SIZE=2>> and since there is no aspect of B filtering access to Fa. Of course</FONT>
<BR><FONT SIZE=2>> there could be, if the access priviledges are degraded for </FONT>
<BR><FONT SIZE=2>> C's use of B</FONT>
<BR><FONT SIZE=2>> references - C may not be able to access A.</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > > Is there a way to invoke a primitive against a different </FONT>
<BR><FONT SIZE=2>> > > receiver, in Squeak? For example, In a doIt, invoke </FONT>
<BR><FONT SIZE=2>> > > <primitive: 1> and supply the 2 numbers - one the receiver </FONT>
<BR><FONT SIZE=2>> > > and the other the argument. </FONT>
<BR><FONT SIZE=2>> > > </FONT>
<BR><FONT SIZE=2>> > > - Rob </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > No...not unless you write a new primitive...which is what </FONT>
<BR><FONT SIZE=2>> > I've done for </FONT>
<BR><FONT SIZE=2>> > a few things that are required by Mirror to avoid sending a </FONT>
<BR><FONT SIZE=2>> message to</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > the reflectee. In fact, there are a lot of things that you </FONT>
<BR><FONT SIZE=2>> might want</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > to invoke in this way. I'm starting to believe that a lot </FONT>
<BR><FONT SIZE=2>> of the very</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > basic primitives should be re-implemented such that they do </FONT>
<BR><FONT SIZE=2>> > not require </FONT>
<BR><FONT SIZE=2>> > that the method be installed the subject. However, this </FONT>
<BR><FONT SIZE=2>> allows one to</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > break encapsulation...but if we could find some way for an </FONT>
<BR><FONT SIZE=2>> object to </FONT>
<BR><FONT SIZE=2>> > restrict (or disable entirely) who is allowed to use reflection </FONT>
<BR><FONT SIZE=2>> > primitives against it, I think it just may be the way to go. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> Right...Primitives shouldn't push the receiver, but rather </FONT>
<BR><FONT SIZE=2>> that would be</FONT>
<BR><FONT SIZE=2>> an explicit argument to the primitive method context. Nice.</FONT>
<BR><FONT SIZE=2>> cheers, </FONT>
<BR><FONT SIZE=2>> Rob </FONT>
<BR><FONT SIZE=2>> > There are some basic operations in Squeak that require the </FONT>
<BR><FONT SIZE=2>> ProtoObject</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > protocol, those operations could be re-written such that if </FONT>
<BR><FONT SIZE=2>> > the message </FONT>
<BR><FONT SIZE=2>> > they are sending isn't implemented, then they fall back on a </FONT>
<BR><FONT SIZE=2>> > reflection </FONT>
<BR><FONT SIZE=2>> > primitive (like #== for example). Certain operations that </FONT>
<BR><FONT SIZE=2>> really need</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > the method natively implemented would not send the message to </FONT>
<BR><FONT SIZE=2>> > the object </FONT>
<BR><FONT SIZE=2>> > at all, and use the reflection primitive instead (like </FONT>
<BR><FONT SIZE=2>> #nextObject for</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > example...that one absolutely has to return an answer </FONT>
<BR><FONT SIZE=2>> appropriate for </FONT>
<BR><FONT SIZE=2>> > itself, or infinite looping can happen (or inaccurate </FONT>
<BR><FONT SIZE=2>> results from a </FONT>
<BR><FONT SIZE=2>> > references search)). </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > - Stephen </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
</BODY>
</HTML>