I'm trying to create a button that will delete a morph named JeffsTestMorph (sublass of Morph). Through inheritance, JeffsTestMorph inherits the delete method does it not? On mouseDown for my button, I have the following:
mouseDown: evt JeffsTestMorph delete.
But when I click on the button I get MessageNotUnderstood: delete. Could someone tell this Squeak newbie what he's doing wrong?
Thanks, Jeff
On Tue, 26 Aug 2003, Jeff Longland wrote:
I'm trying to create a button that will delete a morph named JeffsTestMorph (sublass of Morph). Through inheritance, JeffsTestMorph inherits the delete method does it not? On mouseDown for my button, I have the following:
mouseDown: evt JeffsTestMorph delete.
But when I click on the button I get MessageNotUnderstood: delete. Could someone tell this Squeak newbie what he's doing wrong?
What you are doing wrong is sending the #delete message to the class JeffsTestMorph rather than an instance of JeffsTestMorph, which would be the actual morph you see. In Smalltalk, you can have instance methods and class-side methods... Since you want to delete a specific JeffsTestMorph, it is an instance-side method, and you send it to the instance.
How to fix it? Change "JeffsTestMorph delete." to "self delete." and you should be OK.
And a couple other tips- 1. Message names are case sensitive. The subject line you used reads "Morph>>Delete" - the message is delete, and Delete wouldn't work.
2. The format for specifying a message is Class>>#message ; that is your message should have read Morph>>#delete.
3. Your code attempts to call JeffsTestMorph class>>#delete, but as I say above, you mean to call JeffsTestMorph>>#delete.
Regards, Aaron
-- "a system based on exchanging products inevitably channels wealth to a few, and no governmental change will ever be able to correct that." :: daniel quinn
On Tue, 26 Aug 2003, Aaron J Reichow wrote:
How to fix it? Change "JeffsTestMorph delete." to "self delete." and you should be OK.
The mouseDown: method he's implementing is on a button, not on an instance of JeffsTestMorph. So "self" is not, in fact, what he wants.
Jeff, try this to get started. In a workspace, evaluate each of these lines in turn:
jeffInst := JeffsTestMorph new. jeffInst openInWorld. jeffInst delete.
You can see there that #delete needs to be sent to a variable which is holding onto the particular instance of JeffsTestMorph that you created; not to the JeffsTestMorph class.
The trick is that your button needs to have a way of accessing this same instance.
- The format for specifying a message is Class>>#message ; that is your
message should have read Morph>>#delete.
Really? I use #delete to talk about the message, but Morph>>delete to talk about a particular method.
On Tue, 26 Aug 2003, Avi Bryant wrote:
The mouseDown: method he's implementing is on a button, not on an instance of JeffsTestMorph. So "self" is not, in fact, what he wants.
D'oh, I wasn't paying attention.
So, Jeff, you'd need some way to refer to your particular instance.
- The format for specifying a message is Class>>#message ; that is your
message should have read Morph>>#delete.
Really? I use #delete to talk about the message, but Morph>>delete to talk about a particular method.
The convention is to use the #. It's kind of neat actually- do a print-it on "Morph>>#delete" in a workspace- the CompiledMethod for that method is returned. #delete can be passed (a symbol), and delete cannot.
Regards, Aaron
Aaron J Reichow wrote:
- The format for specifying a message is Class>>#message ; that is your
message should have read Morph>>#delete.
Really? I use #delete to talk about the message, but Morph>>delete to talk about a particular method.
The convention is to use the #. It's kind of neat actually- do a print-it on "Morph>>#delete" in a workspace- the CompiledMethod for that method is returned. #delete can be passed (a symbol), and delete cannot.
Yes, "Morph>>#delete" is a valid Smalltalk expression and "Morph>>delete" is not. However, in discussing Smalltalk code, I observe that "Morph>>delete" is by far the more common style in actual usage (at least on the Squeak list, but I expect elsewhere, as well). This is doubtles related to the fact that Squeak itself reports method references in this syntax in debuggers, MessageTallies, and elsewhere. Doing a "method strings with it" search for '>>' turned up a hundred or so examples in my working image (mostly deprecation messages), and only one example of Class>>#selector, TestCase>>printOn:.
-Jesse
Lots of appearance things were nicer before the Smalltalk-80 release efforts. I wasn't there at the time, but I think they decided (probably rightly) to use the existing character set in the outside world. And, today, it would be nice to do something like your suggestion (maybe a different one) and many other cosmetic possibilities, but several folks have pointed out that even a slight deviation from unadorned text is not supported by all email clients (sigh).
Cheers,
Alan
-----
At 4:30 PM -0800 12/4/03, Andrew P. Black wrote:
Aaron J Reichow wrote:
- The format for specifying a message is Class>>#message ;
that is your
message should have read Morph>>#delete.
Really? I use #delete to talk about the message, but Morph>>delete to talk about a particular method.
The convention is to use the #. It's kind of neat actually- do a print-it on "Morph>>#delete" in a workspace- the CompiledMethod for that method is returned. #delete can be passed (a symbol), and delete cannot.
Yes, "Morph>>#delete" is a valid Smalltalk expression and "Morph>>delete" is not.
I've always found the # symbol to be a blot on the otherwise elegant syntax of Smalltalk. Its a bit surprising to me that Smalltalk didn't adopt a different convention, such as typing all symbols in bold face. delete would be an identifier reference, whereas delete would be a symbol, and myMorph delete would send the message delete to the object bound to myMorph.
However, I'm about 25 years too late in proposing this, so I don't expect that it will be adopted real soon now.
Andrew
On Dec 4, 2003, at 4:52 PM, Alan Kay wrote:
Lots of appearance things were nicer before the Smalltalk-80 release efforts. I wasn't there at the time, but I think they decided (probably rightly) to use the existing character set in the outside world. And, today, it would be nice to do something like your suggestion (maybe a different one) and many other cosmetic possibilities, but several folks have pointed out that even a slight deviation from unadorned text is not supported by all email clients (sigh).
We could still use styled text within Squeak, and have conventions for writing code in plain text when necessary. For example, I always write := instead of _ when sending email, even though I much prefer the left arrow where it's supported.
Re: Morph>>Delete
... but several folks have pointed out that even a slight deviation from unadorned text is not supported by all email clients (sigh).
What can we do when the 'Least Common Denominator' is also the most common (sigh).
Only if we strive for the "Largest Common Denominator" then even the sky is not the limit ;-)
Cheers,
PhiHo.
----- Original Message ----- From: Alan Kay To: The general-purpose Squeak developerslist Sent: Thursday, December 04, 2003 4:52 PM Subject: Re: Morph>>Delete
Lots of appearance things were nicer before the Smalltalk-80 release efforts. I wasn't there at the time, but I think they decided (probably rightly) to use the existing character set in the outside world. And, today, it would be nice to do something like your suggestion (maybe a different one) and many other cosmetic possibilities, but several folks have pointed out that even a slight deviation from unadorned text is not supported by all email clients (sigh).
Cheers,
Alan
-----
At 4:30 PM -0800 12/4/03, Andrew P. Black wrote: Aaron J Reichow wrote: > > > > 2. The format for specifying a message is Class>>#message ; that is your > > > message should have read Morph>>#delete. > > > > Really? I use #delete to talk about the message, but Morph>>delete to > > talk about a particular method. > > The convention is to use the #. It's kind of neat actually- do a > print-it on "Morph>>#delete" in a workspace- the CompiledMethod for that > method is returned. #delete can be passed (a symbol), and delete cannot.
Yes, "Morph>>#delete" is a valid Smalltalk expression and "Morph>>delete" is not.
I've always found the # symbol to be a blot on the otherwise elegant syntax of Smalltalk. Its a bit surprising to me that Smalltalk didn't adopt a different convention, such as typing all symbols in bold face. delete would be an identifier reference, whereas delete would be a symbol, and myMorph delete would send the message delete to the object bound to myMorph.
However, I'm about 25 years too late in proposing this, so I don't expect that it will be adopted real soon now.
Andrew
Aaron J Reichow wrote:
- The format for specifying a message is Class>>#message ; that
is your
message should have read Morph>>#delete.
Really? I use #delete to talk about the message, but Morph>>delete to talk about a particular method.
The convention is to use the #. It's kind of neat actually- do a print-it on "Morph>>#delete" in a workspace- the CompiledMethod for that method is returned. #delete can be passed (a symbol), and delete
cannot.
Yes, "Morph>>#delete" is a valid Smalltalk expression and
"Morph>>delete" is not.
Actually, the convention is to use "Object>>selector" without the hash mark. This can be verified by selecting ">>" and pressing Ctrl-E.
Now, in 1999 some guy decided it would be neat if this *was* valid Smalltalk and added #>> to Behavior as a shortcut for #compiledMethodAt:. Of course, this requires you to use a Symbol as parameter, hence the #. Maybe we should punish him for that? And remove the method? Bad boy, me, bad, bad boy ...
Re: Morph>>Delete
However, I'm about 25 years too late in proposing this,
Chuck Moore seems to think it's never too late for innovation. Even his pride in the past did not seem to hinder his self improvement for the future, IMHO .
Talking of future, currently he always walk with a hiking stick :
"I regret taking a walk without it."
and had this to say :
"I too used to think a hiking stick whimpy. Now I'm older and wiser and have carried one 1,000 miles. For reasons I'd never anticipated"
http://www.colorforth.com/stick.html
Colortalk, any one ;-)
Cheers,
PhiHo.
----- Original Message ----- From: Andrew P. Black To: The general-purpose Squeak developers list Sent: Thursday, December 04, 2003 4:30 PM Subject: Re: Morph>>Delete
Aaron J Reichow wrote: > > > > 2. The format for specifying a message is Class>>#message ; that is your > > > message should have read Morph>>#delete. > > > > Really? I use #delete to talk about the message, but Morph>>delete to > > talk about a particular method. > > The convention is to use the #. It's kind of neat actually- do a > print-it on "Morph>>#delete" in a workspace- the CompiledMethod for that > method is returned. #delete can be passed (a symbol), and delete cannot.
Yes, "Morph>>#delete" is a valid Smalltalk expression and "Morph>>delete" is not.
I've always found the # symbol to be a blot on the otherwise elegant syntax of Smalltalk. Its a bit surprising to me that Smalltalk didn't adopt a different convention, such as typing all symbols in bold face. delete would be an identifier reference, whereas delete would be a symbol, and myMorph delete would send the message delete to the object bound to myMorph.
However, I'm about 25 years too late in proposing this, so I don't expect that it will be adopted real soon now.
Andrew
------------------------------------------------------------------------------
--- Avi Bryant avi@beta4.com wrote:
On Tue, 26 Aug 2003, Aaron J Reichow wrote:
How to fix it? Change "JeffsTestMorph delete." to
"self delete." and you
should be OK.
The mouseDown: method he's implementing is on a button, not on an instance of JeffsTestMorph. So "self" is not, in fact, what he wants.
Jeff, try this to get started. In a workspace, evaluate each of these lines in turn:
jeffInst := JeffsTestMorph new. jeffInst openInWorld. jeffInst delete.
You can see there that #delete needs to be sent to a variable which is holding onto the particular instance of JeffsTestMorph that you created; not to the JeffsTestMorph class.
The trick is that your button needs to have a way of accessing this same instance.
That trick can sometimes be a not insignificant design challenge. One quick and easy to get onscreen results is to give the morph a name upon creation:
jeffInst := JeffsTestMorph new. jeffInst openInWorld. jeffInst name: 'jeffInst'.
Now the button mouseDown or any other method can access the instance by saying:
World submorphNamed: 'jeffInst'
Keep in mind that this approach doesn't eliminate design decisions and it may also introduce a few new ones.
Hope this helps!
- The format for specifying a message is
Class>>#message ; that is your
message should have read Morph>>#delete.
Really? I use #delete to talk about the message, but Morph>>delete to talk about a particular method.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Just from taking a quick look at the Morph class, I see "initialize" where instance variables are set. Should I have a similar area to set the instance variables and open my morphs?
Thanks, Jeff
That trick can sometimes be a not insignificant design challenge. One quick and easy to get onscreen results is to give the morph a name upon creation:
jeffInst := JeffsTestMorph new. jeffInst openInWorld. jeffInst name: 'jeffInst'.
Now the button mouseDown or any other method can access the instance by saying:
World submorphNamed: 'jeffInst'
Keep in mind that this approach doesn't eliminate design decisions and it may also introduce a few new ones.
Jeff Longland wrote:
Just from taking a quick look at the Morph class, I see "initialize" where instance variables are set. Should I have a similar area to set the instance variables and open my morphs?
If your morph has instance variables that must be initialized, #initialize is a fine place to do it. Don't forget to call "super initialize" from YourMorph>>initialize!
Opening the morph in the world from #initialize isn't really appropriate, though.
-Jesse
squeak-dev@lists.squeakfoundation.org
-
Aaron J Reichow -
Aaron J Reichow
-
Alan Kay -
Andrew P. Black -
Avi Bryant -
Bert Freudenberg -
Jeff Longland -
Jesse Welton -
Laurence Rozier -
smallsqueak.net