[squeak-dev] Re: isKindOf: in Morphic code...

Tobias Pape Das.Linux at gmx.de
Tue Jul 5 17:02:45 UTC 2016

On 05.07.2016, at 18:46, tim Rowledge <tim at rowledge.org> wrote:

>> On 05-07-2016, at 6:17 AM, karl ramberg <karlramberg at gmail.com> wrote:
>> A lot of the isKindOf: sends is used to find specific submorphs.
>> ButtonMorph>>label
>> 	| s |
>> 	s := ''.
>> 	self allMorphsDo: [:m | (m isKindOf: StringMorph) ifTrue: [s := m contents]].
>> 	^ s
>> One could give names to the submorphs as they are initialized, all morphs understand 'name:'
>> Would that be a solution ?
> That’s close to what I was suggesting except that I don’t much like the idea of giving a morph a name; it would be more effective to have an instvar in the *owner* and properly track the owned morph that way. For  example in a ButtonMorph I suggest we should have an instvar ‘label’ and when we set the label morph it should be put in that instvar as well as in the submorphs list. That way we can find it quickly, correctly, without the isKindOf: or even isTextMorph. And after all, both of those prevent a graphic label.

What If I drop some other StringMorph onto the Button morph and make it a submorph of it?
It's simple morph composition and the new morph  would just act as label. This is captured by the 
behavior above or some protocol-testing methods but not if ButtonMorph itself would manage
what its label morph is. I know this sounds arcane, but Morphic is a very direct-manipulation
environment and a lot of things are determined by structure rather than explicit management.
I find that noteworthy, interesting, and a little bit intriguing. After all, "only" the development
tools make little use of that. It's different in etoys as far as I can tell.

If you make a development tool, its imho wise to maintain all the administrative stuff flying around,
labels, lists, buttons, check boxes, the like. But in "general" Morphic, determination by looking
at what your submorphs are or can do (sic!) seems fine.

Best regards
	-Tobias :)

> tim

More information about the Squeak-dev mailing list