Re: [Pharo-project] some patterns I would like to **kill**
On Oct 23, 2010, at 1:58 PM, Igor Stasenko wrote:
On 23 October 2010 14:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best.
<sarcasm> if morph having a random submorphs, inserted out of nowhere, just for fun to see what happen. then yes.. findA is userful, as well as respondsTo: </sarcasm>
I like your sarcasm, we are all in sync on that Open a 3.8 or 3.9 and check findA:
but if we are talking about specific morphs, like Pluggable and friends, who serving a certain purpose (building UI from spec), where no place for 'random', then this truly a bad design.
:)
Stef
On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
Stef,
#respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse@free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill**
Hi
I was reading Pluggable and friends I identified some patterns.
The respondsTo plague Examples:
color := self fillStyle asColor. (self labelMorph respondsTo: #enabled:) ifTrue: [self labelMorph enabled: self enabled]. (self labelMorph respondsTo: #interactionState:) ifTrue: [self labelMorph interactionState: self interactionState]
(self labelMorph respondsTo: #enabled:) ifTrue: [ self labelMorph enabled: aBoolean].
(self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]])
by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed.
Using submorphs to avoid one single inst var makes code quite ugly to read:
labelMorph "Answer the actual label morph."
self hasSubmorphs ifFalse: [^nil]. self firstSubmorph hasSubmorphs ifFalse: [^nil]. ^self firstSubmorph firstSubmorph
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 23 October 2010 15:04, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 23, 2010, at 1:58 PM, Igor Stasenko wrote:
On 23 October 2010 14:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best.
<sarcasm> if morph having a random submorphs, inserted out of nowhere, just for fun to see what happen. then yes.. findA is userful, as well as respondsTo: </sarcasm>
I like your sarcasm, we are all in sync on that Open a 3.8 or 3.9 and check findA:
Actually this is a serious problem: how to keep flexibility, but at same time enforce some specific rules over 'random' cloud of data. My thought about it, that if some morph expects some hierarchical organization from submorphs (like label in button morph), then it should explicitly state that it expects a certain protocol to be supported by its submorphs, like #enabled: #contents: etc. So, then it could send these messages without any checks, and if DNU happens, then its a responsibility of those who made a mistake by putting wrong things inside a button. Another idea is to use a button as a 'decorator' to another morph, called 'label'. A label could have any number of arbitrary submorphs, but button could have only single submorph, up to the point that it could override #submorphs with: submorphs ^ { label } and dispatch #addSubmorph to a label: addSubmorph: aMorph ^ label addSubmorph: aMorph then it having total control over its contents (only single submorph, known that it understand a certain protocol), and everyone is happy: - user could put anything inside button - developer can be sure it will work without any problems, whatever you may put in it There could be other ways to solve that.
but if we are talking about specific morphs, like Pluggable and friends, who serving a certain purpose (building UI from spec), where no place for 'random', then this truly a bad design.
:)
Stef
On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
Stef,
#respondsTo: - no argument. Â More defensive programming (aka masked bugs). Â Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Â Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. Â An instance variable could also cache stale information. Â Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse@free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill**
Hi
I was reading Pluggable and friends I identified some patterns.
The respondsTo plague Examples:
color := self fillStyle asColor. Â Â Â Â (self labelMorph respondsTo: #enabled:) Â Â Â Â Â Â Â Â ifTrue: [self labelMorph enabled: self enabled]. Â Â Â Â (self labelMorph respondsTo: #interactionState:) Â Â Â Â Â Â Â Â ifTrue: [self labelMorph interactionState: self interactionState]
(self labelMorph respondsTo: #enabled:) ifTrue: [ Â Â Â Â self labelMorph enabled: aBoolean].
(self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]])
by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed.
Using submorphs to avoid one single inst var makes code quite ugly to read:
labelMorph     "Answer the actual label morph."
    self hasSubmorphs ifFalse: [^nil].     self firstSubmorph hasSubmorphs ifFalse: [^nil].     ^self firstSubmorph firstSubmorph
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (2)
-
Igor Stasenko -
Stéphane Ducasse