On Saturday 19 July 2003 11:32 am, Stephane Ducasse wrote:
> Hi ned
>
> This is the sign that the client interface creation of this class
> is not really good
> then. Either it should provide a good interface or it should break
> directly at creation time.
>
> This also reminds me that having automatic initialize methods
> invoked would be really a step in the future (even if CLOS got that
> now nearly 15 ago at least #Smalltalk has it).

Well, "new" isn't (always) the idiom for getting fully-usable Morphs.

And there are some morphs that aren't really usable by themselves, 
though one could wire them up for testing.

If you look at the return value of #includeInNewMorphMenu you will see 
whether a particular class doesn't want to be instantiated from that 
menu. Also, the classes in 'Morphic-Menus' and 'Morphic-Support' 
don't show up in that list.

I'd argue that #newStandAlone should work for all Morph classes that 
could conceivably be instantiated by themselves. Which leaves the 
question open of how to mark or otherwise handle classes that can't 
do this.

We have (in addition to #new):

* #wantsToBeOpenedInWorld (open in world vs. in hand from New Morph 
menu)
* #installModelIn: (called by some clients but not others)
* #initializedInstance (called by the "sample instance" menu choice)
* #newStandAlone (which is called by #initializedInstance if it's 
defined) (which then calls #initializeToStandAlone)
* #authoringPrototype (which is called when a Morph is put in a flap)
* #descriptionForPartsBin and #supplementaryPartsDescriptions (used 
for the Objects tool)

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE