Mantis Bugtracker
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0004280 [Squeak] Morphic tweak always 07-18-06 18:36 07-21-06 09:39
Reporter wiz View Status public  
Assigned To
Priority normal Resolution open  
Status new   Product 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:

 
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
Attached Files

- Relationships
related to 0005560new  MatrixTransformationMorph needs examining and fixing. 

- Notes
(0005979 - 1564 - 1774 - 1774 - 1774 - 1774 - 1774)
wiz
07-18-06 20:03
edited on: 07-21-06 03: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.
 

- Issue History
Date Modified Username Field Change
07-18-06 18:36 wiz New Issue
07-18-06 20:03 wiz Note Added: 0005979
07-21-06 03:03 wiz Note Edited: 0005979
07-21-06 09:39 MarcusDenker Severity major => tweak
07-05-07 00:53 wiz Relationship added related to 0005560

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
44 total queries executed.
33 unique queries executed.
Powered by Mantis Bugtracker