[Seaside] A new critical blog discussing Seaside - Using getters/setters

[Keith Hodges]

TheSmalltalkBlog at gmx.ch wrote:
> Thank you for these statements confirming my proposals:
>
>   
>> It is a fact that many squeak codings usually access instance variables 
>> directly, what makes some coding hard to read and to understand.
>>     
>
> Conclusion:
>
> It would be very simple to use accessor methods in Squeak and it's generally a good idea - not my (C) btw. 
>
>   
If I recall from my distant memories of Kent Beck's Smalltalk with Style
(I am feeling too lazy for find it) he doesnt agree, and neither do I.

I have some classes which handle a lot of data and the end up with so
many accessors that I cant see the real public api. It is more important
that the public interface is clear and easy to understand, than it is to
have a load of accessors to private instVars, which aren't part of the
public interface, but look like they are in squeak.

Another example would be that In some cases the rule which says split
this big method into tiny methods can be taken too far. Ten little
methods that do the job of one method, make the public interface to the
class look 10 times as confusing.

Since you have 10 years of experience in Smalltalk as a 10 year old you
are dutifully putting in all the accessors because its part of the
doctrine. I find myself as 16 year old have been there, but now I find
myself taking accessors out and going back to direct instVar access for
entirely different reasons. And it was reading Kent Becks advice that
started me on this new enlightened path.

newThis: newThat: is not a universal convention I certainly don't use
it. It is only needed for corecion, #newFromString: There is another
convention that states that instanciation should be as readable as
possible, and methods in the category "instanciation" should instanciate
a fully operational objects, e.g. Point x:y: is perfectly acceptable.
Point new setX: 1 y: 3; yourself would also be acceptable, but (Point x:
3) y: 4 wouldnt. i.e #new signifies a potentially incomplete object,
whereas #x:y: returns a complete object.
> I fully agree!
>
> So why aren't the Seaside authors willing to learn from such advice?
I happen to think that the Seaside coding standards are quite good they
may not be perfect, but they are there, they have been thought about and
there is some rationale behind them.

I have two concerns with your criticisms. Firstly you appear to be
criticising seaside 2.8 which is for all practical purposes for this
discussion old news. And secondly you are assuming that no one has
thought about any of this before, and that no one is wrestling with it
now. You are accusing people of ignorance because they don't happen to
agree with you, or you dont happen to agree with them.

The seaside team has a policy of removing methods that are not actually
used by the framework. They have thought about it, and they are willing
to defend their stance. I dont agree with them because this means that
some useful accessors are not provided just because seaside itself
doesnt use them for its own needs (an example of this is that
#hasGroupNamed: is not provided in the interface to the application
configuration because seaside has no need of it. The fact it is missing
renders a useful aspect of configuration needlessly  inaccessible to
client code.

The fact that I disagree with this approach doesnt make them idiots, it
means they have intelligently thought about it, and for some reason
however odd to me, have come up with a different conclusion. You never
know you might learn something, by listening to their rational first
before attacking it.

/seaside/blah is silly I agree, but there are reasons, it has been
discussed before, there are solutions available, and those who have
looked at the alternatives have their opinions which they are willing to
defend, if you will let them.

>  Are these poults wiser than the hens? There was no argument brought up to justify this bad practice of direct instVar usage!
>
>   
One mans garbage is another mans dinner, its all about perspective. I
disagree its not necessarily bad practice.
> More on: http://thesmalltalkblog.blogspot.com
>   

Keith