To Traits Or Not To Traits (Was: Re: Stefs roadmap for 3.9, time to get it nailed down)

Tim Rowledge tim at sumeru.stanford.edu
Thu Feb 24 22:28:55 UTC 2005


OK, I read the papers. Basically I'm in favour of using Traits; it's a
nice concept that seems to have potential to make it easier to build
neat classes and keep them neat. Keeping classes neat makes it
easier for people to understand the _intent_ of class and thereby keep
it on track. I have this theory that the main reason Morphic classes
have become such disgusting piles of foetid bytecodes is that almost
nobody that has changed them had a clue what was supposed to be
happening. 

I'm not so sure about the browser UI shown in the papers - using
colours like that isn't something I feel very comfortable with for
example - but so long as there are tools that actually work they can be
improved upon later.

The pervasive use of accessor methods reminds of my dislike of having
accessors for everything; it invites C-hacker rape and pillage. The
problem is that they are not at all private and so expose the
underlying structure of the class to any voyeur. We don't need to go far
to see appalling code that abuses such methods and violates all the
Laws of Demeter. We need to find a better way to handle this issue;
some way to make such methods private in a suitable form would be
useful. I suppose we could make a trivial hack by specifying the
setter/getter messages to have a name that is always trtGetBlah for
example. It would be a little ugly but probably functional enough for a
beginning.


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
"Bother," said Pooh, reading his bank statement from Barings.



More information about the Squeak-dev mailing list