RE: [croquet] get a handle to an object

> Just send a future message, e.g., assuming you have a reference to  
> the window just do:
>
>   frame := window future windowFrame.
>   frame future colorize: Color red.
>
> Cheers,
>   - Andreas
>
> haggai wrote:
>> How can I get a handle to an existing object? Say for example I  
>> would like to change a parameter on the window frame of a 2d  
>> portal such as changing the color of the frame. My guess is that  
>> it would have to happened with the method "colorize:" in the  
>> "TWindowFrame".  but How do I access the ID of the portal, which  
>> its frame I want to colorize, and what is the sequence of events  
>> that need to happened for the frame to be rendered with the new  
>> color?  Can anyone give me a little example?
>> h

> Howard,
>
> Thank you for the wonderful answer!  I went no problem through the  
> lesson and was able to manipulate the frame colors as you suggested.
>
> It is probably because I am coming from a "different school" that I  
> am still having troubles with it:  Am I getting this right that  
> there is no passing around of objects IDs in Squeak???  Some  
> article I glanced through in the context of 'teatime' called it an  
> 'old habbit'  and not real object oriented.   Hmmm. I think I have  
> a lot to learn here. I'm having hard time seeing how I can program  
> serious code without dynamic referencing. In both your examples we  
> had to resort to selecting the object in order to manipulate it.  
> But what if you want to manipulate more than one object at the same  
> time? What if you want to automate certain things? surely you can't  
> rely on just selecting things interactively?  there was a  
> mentioning of 'query strings' but I haven't quite figured it out.
>
> Ok, I am hoping to not stir things in  a wrong way here - the  
> momentum is too important!!!
> Buy really looking forward to your comments.
>
> (If you like to keep the thread continuity please feel free to copy  
> this email to the group until I manage to log-in)
>
> Again, thank you for your great input!
>
> h
>
>
> Haggai Goldfarb
> LiquidBits
> office: 617.401.2225
> cell: 818.648.5158
> [hidden email]
>
>
> ----- Original Message ----
> From: Howard Stearns <[hidden email]>
> To: [hidden email]; haggai <[hidden email]>
> Sent: Saturday, January 27, 2007 11:44:53 AM
> Subject: Re: [croquet] get a handle to an object
>
> [I remember it being quite a challenge to figure out how to ask a
> Croquet question, and now I find it quite a challenge to figure out
> what people are asking! Fortunately, both challenges are  
> stimulating...]
>
> There are several context you might have in mind. I'm going to try to
> illustrate this with some inspectors. I'm going to START by taking
> you through the WRONG way to get to stuff, but it fits the Squeak and
> Pre-Croquet view of things, so I'm guessing that it fits with the
> question you THINK you're asking.
>
> 1. Open a Croquet(Master). Do a cmd/alt-click on the Morphic window
> to get the Morphic halo. There is a small gray button on the right
> hand side of the halo, second from the top, with an icon of a wrench.
> Click it to get a Morphic menu, and choose 'explore morph' to get a
> Morphic inspector.
>
> 2. Drill down through the tree using the triangles: root->harness-
> >islandsByName->'Master'->myValue->globals->#masterSpace-
> >frameChildren->6 (the first TWindow). Click on '6: a TWindow
> [5]:'aTWindow''. We're now inside that object, with 'self' bound to  
> it.
>
> 3. In the lower pane of the explorer, type
>    self colorize: Color red
> and press cmd/alt-d to 'do it'.  You've just made Allen turn red!
>
> We've just gone behind the scenes, barging our way through proxy
> objects. If we were collaborating with others in the same world, they
> would not see Allen turn red.  We did all this in a Morphic process
> outside of the Croquet island process that takes care of
> collaboration. We broke Croquet.
>
> You want to write things so that most stuff happens as normal
> programming within the simulation. We call this being "on-island."
> We're going to do an example of that now.
>
> 1. Let's break some TWindows. Leaving everything open, bring up a
> class browser. (Click on the grey desktop to get the Morphic world
> menu and select open->class browser.)  Click the tiny little black
> square at the top of the scroll bar for the upper left pane of the
> browser. (Hey, I didn't design it.) Select 'find class...'. Type in
> 'twin' and select TWindow. We're going to add to and then modify the
> Croquet class that Allen is in an instance of.
>
> 2. Click on --all-- in the second pane from the right. Move your
> mouse to the code pane at the bottom without clicking.  Type
>    frob
>       self colorize: Color white.
> Click the tiny black square above the scroll bar for the code pane
> and select 'accept'. You've just added the #frob method.  Check this
> out by going back to the explorer and replacing the old code with
>    self frob.
> 'Do it' again. It works!
>
> 3. Now we've made a normal method that works from off island, and now
> we're going to show that it works on-island, too.  Edit the method
> definition to say 'Color red' instead of 'Color white' and accept it
> again. Now click on --all-- at the top of that second-from-the right
> pane again, and in the rightmost pane, scroll down to pointerDown:.
>
> 4. We're going to change pointerDown: to use our #frob method.
> #pointerDown: is part of the UI for Croquet, which carefully arranges
> #pointerDown: to be executed from WITHIN the island (meaning that
> every participant executes the same method at the same "time"), not
> from within Morphic.  Highlight everything in the #pointerdown:
> method except for the method name and arguments, and replace them
> with just
>    self frob.
> just like we did in the explorer. Accept it.
>
> 5. Now move your mouse over the window FRAME and left-click. Allen
> turns red. When the mouse button is released back up you also get an
> error because we've broken the little dance that TWindow does with
> #pointerDown: and #pointerUp:, but that's ok. Just press the 'x' in
> the debugger window frame -- or examine the stack and see if you can
> figure out the dance!
>
> Most of you application programming will be to just define normal
> methods like #frob. They refer to instance variables of the classes
> that methods are defined on. (Sometimes it's convenient to refer to
> self parent or self frameChildren, but this is often the path to hell
> compared with explicitly maintained instance variables. But that's a
> programming issue that isn't specific to Croquet.)  Then you use your
> methods (e.g., #frob) to event handlers (e.g., #pointerDown:).  Not a
> #future in sight.
>
> How do you get objects into the world in the first place? Either your
> application framework has operations for users to interactively add
> stuff (e.g. as the KAT code does), or the stuff is created when the
> island is first created. See the #initialize method of the various
> subclasses of BaseWorld.  Note that such world initialization is also
> done on-island.
>
> There is also opportunity to create stuff from off-island as though
> you were creating a new kind of event. That is, ONE participant
> executes some code from Squeak/Morphic (e.g., with the inspectors
> like we were doing), or perhaps from some user interface mechanism
> that they've built (e.g., Tweak application menus).  This is where
> you deal with proxy objects called TFarRefs, using the #future
> message like Andreas showed.  There are several threads on this, like
> https://lists.duke.edu/sympa/arc/croquet-dev/2006-12/msg00000.html,
> but the chances good that this is NOT really what you want to do.
> Here's how to relate those other discussions to the stuff we were
> doing in the explorer, above. You'll notice that some of the stuff in
> the explorer is a TFarRef.  A Kosher way to interactively get a
> TFarRef to the current space is as follows. I hope you'll use this to
> explore and begin to understand on-island vs off-island and to debug,
> but not as the principle way to be thinking about constructing
> applications!
>
> 1. Explore the Morph as we did before, and just click on root.
>
> 2. Type
>          harness activeSpace explore
> and 'do it'.
>
> 3. click on the TFarRef in the new explorer.  Now you can do stuff  
> like
>    self future addChild: (self island future new: TCube)
>
> On Jan 27, 2007, at 6:36 AM, haggai wrote:
>
> > Andreas,
> >
> > thank you for the answer but I am still not getting it.  I have a
> > reference to the outside window (some demo world) How do I get a
> > reference to a window inside, another words: How do I find a 2d
> > portal id. (and I may have more than one)
> >
> > h
>
> On Jan 27, 2007, at 12:16 AM, Andreas Raab wrote:
> > Just send a future message, e.g., assuming you have a reference to
> > the window just do:
> >
> >   frame := window future windowFrame.
> >   frame future colorize: Color red.
> >
> > Cheers,
> >   - Andreas
> >
> > haggai wrote:
> >> How can I get a handle to an existing object? Say for example I
> >> would like to change a parameter on the window frame of a 2d
> >> portal such as changing the color of the frame. My guess is that
> >> it would have to happened with the method "colorize:" in the
> >> "TWindowFrame".  but How do I access the ID of the portal, which
> >> its frame I want to colorize, and what is the sequence of events
> >> that need to happened for the frame to be rendered with the new
> >> color?  Can anyone give me a little example?
> >> h
>
>
>
>

> For the sake of discussion let's say that what I am trying to  
> accomplish is
> writing a script to modify a world full of objects. I am assuming  
> though that
> there will be events that the system will have to react to. for  
> example: an
> animation rig.
>
> Obviously you always have to set the name somehow before you can  
> get it.
> [...snip...]

> On Jan 28, 2007, at 20:15 , haggai wrote:
>
>> For the sake of discussion let's say that what I am trying to  
>> accomplish is
>> writing a script to modify a world full of objects. I am assuming  
>> though that
>> there will be events that the system will have to react to. for  
>> example: an
>> animation rig.
>>
>> Obviously you always have to set the name somehow before you can  
>> get it.
>> [...snip...]
>
> Okay, so this is where your problem is. You have to grok the  
> concept of "objects" first. There is no need whatsoever to *name*  
> an object to be able to refer to it. You just refer to the object  
> itself.
>
> For example, when you want to let the user pick an object from a  
> textual list, what is *displayed* might be some String property  
> like the object's name or its ID, but what is actually *selected*  
> is the object itself. And then you can just start sending messages  
> to the object.
>
> - Bert -
>
>

> On Jan 29, 2007, at 12:51 , kiran wrote:
>
>>        As far as C++ goes( same with Squeak) you need to inherit two
>> squares as descendants of some base square.
>
> No. You only need to do that in C++ to convince the compiler you know
> what you're doing. It's a poor form of static typing.
>
> In Squeak you just implement the method you want to be able to send it
> to some object, this is totally independent of inheritence. It's
> called dynamic typing (or, nowadays, duck typing
> http://en.wikipedia.org/wiki/Duck_typing)
>
> On a related note, Squeak uses strong typing (an object is always what
> it is) and not weak typing like C++ (you can override an object's type
> by casting, and do terrible things to it).
>
> - Bert -
>
>
>
>

> Just a terminology correction.   "Strong typing" in the literature  
> means that an object has a type that is enforced at "compile  
> time".  Weak typing implies that enforcement is not done at compile  
> time.
>
> Squeak doesn't enforce anything at compile time.   While not as  
> extreme as Self, one can indeed change the set of protocols that an  
> object accepts in Squeak at run time.   In particular, you can add  
> methods to an object by, for example, patching its class object  
> reference (carefully), or augmenting its class object's methods in  
> a way that only affects that object (check for the object id in the  
> method you add).
>
> It would be bad to confuse the world by saying that Squeak or  
> Smalltalk is "strongly typed".
>
> Bert Freudenberg wrote:
>> On Jan 29, 2007, at 12:51 , kiran wrote:
>>
>>>        As far as C++ goes( same with Squeak) you need to inherit  
>>> two squares as descendants of some base square.
>>
>> No. You only need to do that in C++ to convince the compiler you  
>> know what you're doing. It's a poor form of static typing.
>>
>> In Squeak you just implement the method you want to be able to  
>> send it to some object, this is totally independent of  
>> inheritence. It's called dynamic typing (or, nowadays, duck typing  
>> http://en.wikipedia.org/wiki/Duck_typing)
>>
>> On a related note, Squeak uses strong typing (an object is always  
>> what it is) and not weak typing like C++ (you can override an  
>> object's type by casting, and do terrible things to it).
>>
>> - Bert -

> David P. Reed wrote:
>  
>> Just a terminology correction.   "Strong typing" in the literature means
>> that an object has a type that is enforced at "compile time".  Weak
>> typing implies that enforcement is not done at compile time.
>>    
>
> In the literature I read the terms used are "static typing" when it is
> done at compile time and "dynamic typing" when the run time uses tags in
> the objects themselves to deal with types. The strong/weak/none
> dimension is a totally separate issue.
>
> I do see blog entries and stuff like that which use the terms as you
> said, so there is a real possibility that eventually conference papers
> will adopt this use as well. But it hasn't happened yet. Is this a
> losing battle (like trying to hold on to the original meaning of
> "hacker" back in the 1980s, for example)? I don't think so, and think
> that for now it is best to try to educate people.
>  
>  
>> Squeak doesn't enforce anything at compile time.   While not as extreme
>> as Self, one can indeed change the set of protocols that an object
>> accepts in Squeak at run time.   In particular, you can add methods to
>> an object by, for example, patching its class object reference
>> (carefully), or augmenting its class object's methods in a way that only
>> affects that object (check for the object id in the method you add).
>>    
>
> Right, that goes a bit beyond the usual definition of dynamic typing.
> Let's call that "very dynamic" since it is still in the same dimension.
>
>  
>> It would be bad to confuse the world by saying that Squeak or Smalltalk
>> is "strongly typed".
>>    
>
> The world is already confused. Very much so. Agreeing with people who
> have mixed up ideas won't help.
>
> Just to reinforce my viewpoint, we can classify types along three
> orthogonal axis:
>
> - strong / weak / none
> - static / dynamic
> - concrete / abstract
>
> So I claim that Squeak's types are very dynamic, strong and abstract.
>
> -- Jecel
>
>
>