Why should this not work?
Locked
 
|
X := StarMorph new.
X openInWorld. X turn: 135. X forward: 100. You can do it with scripts, so why not for code? |
|
|
Because scripts control players not morphs. Try this instead:
X := StarMorph new. X openInWorld. player := X assuredPlayer. player turn: 135. player forward: 100. Robert Hawley wrote: > X := StarMorph new. > X openInWorld. > X turn: 135. > X forward: 100. > > You can do it with scripts, so why not for code? > > |
|
|
Hi Andreas
... that's the fix, but my question is "why not?". Why should morphs not be able to move forward without having to fiddle with the player? ... why should this not be a morph functionality? ... why should assuredPlayer be a coding inconvenience when it is not so for scripts? It seems very odd and idocyncratic - particularly when morphs are also such a fundamental of computation independantly of eToys. >From the point of view of teaching initial programming (as opposed to using scripts) in Smalltalk, this is an arbitary separation - clumsy and artifactual - for example, liftPen and lowerPen assure the player for themselves, so why not for forward: ?. Also, if I implement a script it associates with a player, but if I want to call it using the code as code why should the morph not know to check whether the player implements it? There are probably good reasons for the way morphs and players have been implemented - I am not clear whether these are stylistic, driven by efficiency issues, or what. I have a fix that makes this issues transparent - effectively it gives multiple inheritance from either morph or player. Are there reasons why this is not a good idea? doesNotUnderstand: aMessage (self hasExtension not or: [self player isNil]) ifTrue: [ (Player includesSelector: aMessage selector) ifTrue: [^self assuredPlayer perform: aMessage selector withArguments: aMessage arguments] ifFalse: [^super doesNotUnderstand: aMessage]]. ^self player perform: aMessage selector withArguments: aMessage arguments Yours Bob -----Original Message----- From: Andreas Raab [mailto:[hidden email]] Sent: Sun 25/02/2007 5:21 AM To: The general-purpose Squeak developers list Subject: Re: Why should this not work? Because scripts control players not morphs. Try this instead: X := StarMorph new. X openInWorld. player := X assuredPlayer. player turn: 135. player forward: 100. Robert Hawley wrote: > X := StarMorph new. > X openInWorld. > X turn: 135. > X forward: 100. > > You can do it with scripts, so why not for code? > > |
|
|
Robert Hawley wrote:
> ... that's the fix, but my question is "why not?". Why should morphs not be able to move forward without having to fiddle with the player? ... why should this not be a morph functionality? ... why should assuredPlayer be a coding inconvenience when it is not so for scripts? It seems very odd and idocyncratic - particularly when morphs are also such a fundamental of computation independantly of eToys. It's not a "fix" it's documenting a design decision. It is intentional that scripts act on players so that their costumes (morphs) can be changed at will. Why that is the case requires a bit more history and explanation of the player architecture than I feel like giving right now (but from an architectural point of view it was a very wise decision). >From the point of view of teaching initial programming (as opposed to using scripts) in Smalltalk, this is an arbitary separation - clumsy and artifactual - for example, liftPen and lowerPen assure the player for themselves, so why not for forward: ?. Also, if I implement a script it associates with a player, but if I want to call it using the code as code why should the morph not know to check whether the player implements it? There are probably good reasons for the way morphs and players have been implemented - I am not clear whether these are stylistic, driven by efficiency issues, or what. They are driven by the need for flexibility (as mentioned above, one goal is to be able to change costumes) and robustness. And while you may find this "clumsy and artificial" please keep in mind that the goal for these methods was scripting not whatever it is you are doing. > I have a fix that makes this issues transparent - effectively it gives multiple inheritance from either morph or player. Are there reasons why this is not a good idea? Yes. I'm not even sure where to start. But since you seem to come from education, one of the reasons why this is a horrible idea is that you are introducing multiple inheritance in a system that assumes single inheritance without even documenting it. People using Squeak are used to (and being taught) to look at the inheritance chain to find whether a class/object implements a message. You are just breaking this assumption big-time and without giving anyone a clue that you are doing so. That message, doesn't even have a comment! Besides the code is broken too, since it doesn't check for player subclasses, will not handle DNUs correctly in all cases etc. etc. etc. Cheers, - Andreas |
|
|
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). Sorry - I grabbed the wrong version of my 'fix' for the previous post. The following is the best I've got so far (and it does have a comment). (Is it less horrible, and does the comment make it any more acceptable?(!)). I am not advocating multiple inheritance - this is something of a tongue-in-cheek solution. It will always be a dilemma as to how to make a composite object look as if it is a single object - arranging for some form of relay is always going to be necessary. Either the programmer will have to know how to address the internal objects (not always easy to learn however because of all the tracking this entails), or instead a set of messages have to be provided. The doesNotUnderstand: hack may not be desirable, but there is no law against it, it is good fun, and it does do the job! In trying to provide a consistency it is (afterall) having to bypass behaviours that are a bit side-effectual and modal. It also allows the illusion of the simple message sending OOP paradigm to be maintained for morphs for a bit longer without actually interfering with the underlying player/costume design. 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. Yours Bob > ... that's the fix, but my question is "why not?". Why should morphs not be able to move forward without having to fiddle with the player? ... why should this not be a morph functionality? ... why should assuredPlayer be a coding inconvenience when it is not so for scripts? It seems very odd and idocyncratic - particularly when morphs are also such a fundamental of computation independantly of eToys. It's not a "fix" it's documenting a design decision. It is intentional that scripts act on players so that their costumes (morphs) can be changed at will. Why that is the case requires a bit more history and explanation of the player architecture than I feel like giving right now (but from an architectural point of view it was a very wise decision). >From the point of view of teaching initial programming (as opposed to using scripts) in Smalltalk, this is an arbitary separation - clumsy and artifactual - for example, liftPen and lowerPen assure the player for themselves, so why not for forward: ?. Also, if I implement a script it associates with a player, but if I want to call it using the code as code why should the morph not know to check whether the player implements it? There are probably good reasons for the way morphs and players have been implemented - I am not clear whether these are stylistic, driven by efficiency issues, or what. They are driven by the need for flexibility (as mentioned above, one goal is to be able to change costumes) and robustness. And while you may find this "clumsy and artificial" please keep in mind that the goal for these methods was scripting not whatever it is you are doing. > I have a fix that makes this issues transparent - effectively it gives multiple inheritance from either morph or player. Are there reasons why this is not a good idea? Yes. I'm not even sure where to start. But since you seem to come from education, one of the reasons why this is a horrible idea is that you are introducing multiple inheritance in a system that assumes single inheritance without even documenting it. People using Squeak are used to (and being taught) to look at the inheritance chain to find whether a class/object implements a message. You are just breaking this assumption big-time and without giving anyone a clue that you are doing so. That message, doesn't even have a comment! Besides the code is broken too, since it doesn't check for player subclasses, will not handle DNUs correctly in all cases etc. etc. etc. Cheers, - Andreas |
|
|
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 |
|
|
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:[hidden email]] 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 |
|
|
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:[hidden email]] >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 |
|
|
In reply to this post by Andreas.Raab
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! ! |
|
|
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! ! |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |