Hi Robert --

And there's no reason why you can't put the creation of your wrapped 
objects in Class Morph itself. So instead of

X := MorphicObject on: StarMorph.

you would have something that looked more like:

X := StarMorph newer.

(or some such) that would manifest your MorphicObject wrapper.

Cheers,

Alan


At 09:40 PM 2/27/2007, Robert Hawley wrote:
>Hi Alan and Andreas
>
>Thank you for replying and for your inputs.  I have looked at Tweak 
>- and likewise Croquet - and love them both!  I don't know when or 
>how the Tweak/Morphic issue will develop, so for now, Morphic 
>remains a useful tool for my quick demo programming needs.
>
>I have had further thoughts on the issue I am persuing.  These 
>discussions are helping.  I think I have a simple solution - one 
>that doesn't interfer with the existing morph and player code at 
>all.  I've created a new class called MorphicObject that simply 
>encapsulates the morph - it then relays the messages to the morph or 
>to the player as appropriate.  The relaying is not done within the 
>morph class so morphs exist with no interference from me. It still 
>works by trapping and forwarding the dnus - but in a way that is not 
>really MI - it just steers the messages to either the morph or the 
>player as appropriate. (All it does is what a programmer would have 
>to know to do when using assuredPlayer; so from the 'learning' point 
>of view it does what I wanted; it bypasses the player/costume 
>complexity and keeps the morphicObject behaving like a simple 
>object.)  I think that because this solution is simple it is 
>relatively easy to track and debug things when they go wrong.  I've 
>put my code at the bottom of the page - it's not very tested yet but 
>it works (I haven't yet looked at the issue of the other subclasses 
>of Player yet however).
>
> >From the point of view of someone coding, the only thing that is 
> odd is the creation line:
>
>X := MorphicObject on: StarMorph.
>
>then ordinary messages can be sent quite transparently:
>
>X openInWorld.
>X forward: 99.
>X lowerPen.
>
>- obviously the openInWorld and the lowerPen go to the morph, and 
>the forward: goes to the player.
>
>A thing I've been after is easy browser access to the scripts.  This 
>is now provided by:
>
>X editScripts
>
>I'm happy with this solution; it bridges the gap between scripts and 
>coding, it is simple, and it is independant of the rest of the system.
>
>Yours
>
>Bob
>
>
>--------------------------
>
>Re: Why should this not work?
>
>Alan Kay alan.kay at squeakland.org
>Tue Feb 27 16:05:13 UTC 2007
>Previous message: Why should this not work?
>Next message: squeaksource.blueplane.jp down
>Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>Hi Bob --
>
>You could (and maybe should) consider just making an architecture in
>Squeak that serves your purposes. The Player architecture in Etoys
>was an attempt to make a much simpler (but still comprehensive)
>object model, and a viewing architecture that lies "between" (if that
>is a reasonable term) Morphic and MVC. One needs to do make simple
>ticking scripts like:
>
>       foo forward 20
>       foo turn 10
>       Holder's cursor increase by 1
>       foo look like Holder's player at cursor
>
>And there are also many needs for multiple views. One of the things
>that occurred to us many years ago, and was intensified when
>Hypercard came out, is that if you only had "cards": as one's graphic
>type, could embed them in each other as much as needed, they could be
>any shape (a generalized curve with holes), etc., then you would have
>a very capable but extremely simple way to think about manifesting
>visible properties. This came from the observation that a Hypercard
>card could easily be made to be a view of any set of cards. Morphic
>does some of this but it really incorporates the Model and the View
>in one object. There needs to be a way to have more than one view,
>and this where the costume idea came from.
>
>You might like to look at Andreas' Tweak architecture, which is most
>easily seen (and is kept up to date) in Croquet (opencroquet.org).
>This (in my opinion) is a much better and more useful graphics
>architecture than Morphic (and it had the advantage of learning from
>quite a bit of Morphic experience). The Tweak graphics architecture
>is kind of a grown up version of Etoys.
>
>Cheers,
>
>Alan
>
>
>
>
>At 07:35 AM 2/27/2007, Robert Hawley wrote:
> >Hi Andreas
> >
> >I agree that standardly defined things like forward: could be relayed
> >from the morph to the player using messages that do the assuredPlayer
> >job. I don't know if there is any fundamental reason why this should not
> >be included in the released image? (I wonder if the design decisions
> >include factors to do with efficiency for example?). This relaying does
> >provide trackable messages and it answers part of the issue I am
> >questioning.
> >
> >However, this won't work for user provided scripts, as they are specific
> >to an individual player. These associate with a specific named class
> >(e.g., Player57) and so it would not be possible to automatically plant
> >relaying calls in the (more generic) morph class. My 'fix' (hack) deals
> >with this case too. I don't (yet) understand the issue of subclasses of
> >Player you mention (the scripts are already in a named subclass of
> >player and they are being picked up ok) - I will look into it.
> >
> >Yours
> >
> >Bob
> >
> >-----Original Message-----
> >From: Andreas Raab [mailto:andreas.raab at gmx.de]
> >Sent: 27 February 2007 07:44
> >To: The general-purpose Squeak developers list
> >Subject: Re: Why should this not work?
> >
> >Robert Hawley wrote:
> > > Hi Andreas
> > >
> > > If you argue that morphs are designed only for eToy scripting then I
> >suppose I have no point to make.
> > >
> > > However, morphs are also used for other things.  In fact many serious
> >Squeak programmers profess 'chosen ignorance' of eToys and yet use
> >morphs all the time - to the extent that several want to throw away the
> >eToys so that they can use morphs the way that they want to and clean
> >the system up.
> > >
> > > The transition from eToys scripting to programming with Smalltalk is
> >clumsy when trying to use it for teaching.  When scripts become
> >limiting, the shift to using proper browsers is not very straight
> >forward (or well documented).  I would like to be able to go more
> >naturally through this transition - and without having to assume
> >expertise at the guru level.  Given that scripts can do forward: then it
> >is observably odd not to be able to the same thing when coding Smalltalk
> >(hence my simple initial question).
> >
> >None of the above really changes what I said (and which I think you
> >misunderstood). I didn't claim that morphs were only designed for eToys
> >scripting but this particular aspect (logo-like behavior) was. Because
> >of that you can only really use it via its player and you should expect
> >to find a certain amount of idiosyncrasies (like #assuredPlayer) when
> >you deal with it. If you wanted to change that it would amount to a
> >serious bit of redesign.
> >
> > > doesNotUnderstand: aMessage
> > >       "RHawley 9/18/2006 06:23"
> > >       " Redirects the message to the Morph's player if it can respond.
> > >               Allows commands like forward: to be sent to the morph
> >directly
> > >               (prevously they would have to be directed to the morph's
> >player explicitly.
> > >               Now use, X forward: 10    instead of    X assuredPlayer
> >forward: 10).
> > >               This is useful for actions associated with the 'Press
> >Me' button"
> > >       self hasExtension ifFalse: [
> > >               (Player lookupSelector: aMessage selector) ifNil: [
> > >                       ^super doesNotUnderstand: aMessage]].
> > >       (self assuredPlayer respondsTo: aMessage selector) ifTrue: [
> > >               ^self assuredPlayer perform: aMessage selector
> >withArguments: aMessage arguments].
> > >       ^super doesNotUnderstand: aMessage
> > >
> > > With this code, it becomes possible to use standard browsers to write
> >code in a way that is more naturally consistent with the scripts the
> >students have already met.
> >
> >That version is a definitive improvement (though it still suffers the
> >issues about Player subclasses) but generally I just don't think we
> >should "introduce MI" in a singular place in the system. I'd rather add
> >a method like:
> >
> >Morph>>forward: amount
> >         ^self assuredPlayer forward: amount
> >
> >which seems much more straightforward for the things you're trying to
> >do.
> >
> >Cheers,
> >    - Andreas
>
>Previous message: Why should this not work?
>Next message: squeaksource.blueplane.jp down
>Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>More information about the Squeak-dev mailing list
>
>Squeak-dev list courtesy of The InternetOne and tric, the new way
>
>
>
>
>Object subclass: #MorphicObject
>         instanceVariableNames: 'morphClass morph'
>         classVariableNames: ''
>         poolDictionaries: ''
>         category: 'Morph-MorphicObject'!
>!MorphicObject commentStamp: 'rjh 2/28/2007 04:32' prior: 0!
>Useful for coding in the main system in a way that is more 
>compatible with scripts in eToys.
>
>Example:
>X := MorphicObject on: StarMorph.
>X openInWorld.
>X forward: 99.
>X lowerPen.
>X editScripts
>
>MorphicObject:
>         - provides a consistency with the way scripts behave.
>         - provides this consistency fairly transparently.
>         - enables convenient access to eToy scripts within main 
> system browsers.
>         - provides wrappers for morphs - these automatically relay 
> messages to either the morph
>            itself or to the morph's player (as appropriate).
>         - eliminates the need to use #assuredPlayer (as is needed - 
> when coding - to address a
>            morph's player):
>                         Rather than:     morph assuredPlayer forward: 99
>                         Have instead:    morphicObject forward: 99
>         - extends the simple OOP message paradigm more fully by 
> hiding the fact that eToys are
>           actually composite objects
>                 (An eToy morphic object is actually in two parts; 
> the costume and the player).
>                  In the example above the messages are 
> automatically redirected to the appropriate
>                  component:
>                              X forward: 99     sends the message to 
> the morph's player.
>                              X lowerPen           sends the message 
> to the morph itself
>         - opens up a browser on the player in response to the 
> editScripts message. (Currently this
>            only works if at least one script has already been 
> created.)  Note that once edited or
>            created in the browser, scripts will not then be 
> editable using tiles,  and newly created
>             methods in the broswer will not tidily appear in the eToys world.
>!
>
>
>!MorphicObject methodsFor: 'initialize' stamp: 'rjh 2/28/2007 02:58'!
>on: aMorphClass
>         morphClass := aMorphClass.
>         morph := aMorphClass new! !
>
>
>
>
>!MorphicObject methodsFor: 'relay' stamp: 'rjh 2/28/2007 03:33'!
>doesNotUnderstand: aMessage
>         " Redirects the message to the Morph if it can respond, or 
> to the Morph's player if it can respond, otherwise generates an error."
>         (morphClass lookupSelector: aMessage selector) ifNotNil: [
>                         ^morph perform: aMessage selector 
> withArguments: aMessage arguments].
>         morph hasExtension ifFalse: [
>                 (Player lookupSelector: aMessage selector) ifNil: [
>                         ^super doesNotUnderstand: aMessage]].
>         (morph assuredPlayer respondsTo: aMessage selector) ifTrue: [
>                 ^morph assuredPlayer perform: aMessage selector 
> withArguments: aMessage arguments].
>         ^super doesNotUnderstand: aMessage ! !
>
>
>!MorphicObject methodsFor: 'scripts' stamp: 'rjh 2/28/2007 03:57'!
>editScripts
>         Browser newOnClass: self assuredPlayer class! !
>
>"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
>
>MorphicObject class
>         instanceVariableNames: ''!
>
>!MorphicObject class methodsFor: 'as yet unclassified' stamp: 'rjh 
>2/28/2007 02:56'!
>on: aMorphClass
>         ^super new on: aMorphClass! !