Mantis - Squeak
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4280 Morphic tweak always 07-18-06 18:36 07-21-06 09:39
Reporter: wiz Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
Summary: 0004280: The message #transform is used with two incompatible meanings. Gaaahhh!
Description: In 7046 request the implemetors of #transform:

It is used by several morphs and classes as an accessor to set a transformation.

It is used by MorphicTransform and CompositeTransform as a verb meaning applyTo:

 
Steps To Reproduce:
Additional Information: This makes if very diffcult to follow code. You have to guess the context an then be very lucky.

And somewhere along the line we are likely to get to a point where the messages shadow each other.

I highly recommend the message be reserved as an accessor and the message #applyTo: be used when that is what is meant.

Yours in service, --Jerome Peace
Relationships
related to 0005560new  MatrixTransformationMorph needs examining and fixing. 
Attached Files:

Notes
(0005979)
wiz   
07-18-06 20:03   
upon more reflection:

gaaahhh!

In the context of squeak 7046 the implementors of #transform: gave:

BalloonState transform: {accessing}
MatrixTransformMorph transform: {accessing}
PostscriptDummyWarp transform: {dummy}
TransformMorph transform: {accessing}

are the routines that use transform and transform; as accessors. And

CompositeTransform transform: {transformations}
MorphicTransform transform: {transformations}
View transform: {transforming}

use it in the sense of applyTo:

of these the first two classes are leaf classes ( at least in 7046) BUT
View has subClasses to spare and history on its side too.

The mvc iVar for a transform is 'transformation' with the accessors deriving from that. So refactoring the first set of classes by renaming their iVars and accessing methods would eliminate the confusion.

I would dearly love for this to happen. Getting the transformation message in good order would make squeak much more maintainable.
there are too many abiguous message names and you can only maintain as much as you can keep in your head at one time.

So, would it be a problem to rename the iVars and their accessors?

Yours in service, -- Jerome Peace


Side Note: There is one other class that uses #transform:
for MessageNode you get a definition which does some special encoding and returns a boolean. its argument is the encoder. So this is a third definition of the message. I am leaving this out of the main discussion because it is in a sufficiently different context to avoid confusion.