[Cuis] Where to put the complexity?

[Dan Norton]

On 29 Jun 2015 at 13:23, Juan Vuletich wrote:

> Hi folks,
> 
> On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> > On Mon, 29 Jun 2015 07:09:43 -0400
> > "Phil (list)"<pbpublist at gmail.com>  wrote:
> >> ..  Is it
> >> worth having a class for this vs. raising the more general
> Notification
> >> and then checking for a #ReparseAfterSourceEditing signal, and if
> it
> >> isn't, re-raise Notification in its sole handler?
> >> ..
> >> This is a specific example of the more general question of where
> to draw
> >> the line on having single, or very limited, use classes and
> methods vs.
> >> adding a tiny bit of complexity in one or two methods to simplify
> the
> >> overall image or package in question.  Thoughts?
> > I would say the overriding goal is clarity.
> >
> > It is important work to refactor code to have the same behavior
> but be easier to understand.
> >
> > A Smalltalk style goal is to have small methods which do things
> clearly.  This tends to lead to lots of small methods.
> >
> > Specializing classes for one or just a few methods may seem
> wasteful, but computer resources are cheap.
> >
> > Look at class #PartsBinMorph.  Would you say the having the
> additional class is wasteful?
> >
> > It is a tough balance.  Aesthetics and restraint require judgement
> and we don't always get it right.  It takes time.
> >
> > I only have so many life hours left.  I feel my time is valuable. 
> I prefer to understand.
> >
> > Thank you so much for taking the time to make Cuis more
> comprehensible.
> >
> > $0.02
> > -KenD
> 
> I fully support Ken. I don't think that a general answer is correct
> in 
> all cases here. It is a matter of making code easy to understand.
> But 
> also making it consistent and pretty.
> 
> In general, I don't like making general classes know much about
> details 
> of specific use cases. But there might be exceptions.
> 
> If you feel like experimenting with this kind of stuff, send your 
> suggestions to the mail list so we can discuss.
> 
> In the particular case of ReparseAfterSourceEditing, I agree that a
> class that does nothing is a bit strange. But, what is the
> alternative? 
> How would the sole exception handler know what to do with a general
> Notification? I think the handler looks quite reasonable right now.
> And 
> the pollution of the global space might be tolerable if the
> alternative 
> is more convoluted code...
>

Making code easy to understand is very valuable. Simple things should be simple to 
accomplish, but achieving this in an API may not always be easy.

This weekend I spent lots of "quality time" with the debugger, trying to figure out why I could 
not get a new window with a PluggableListMorph to work like another one which had exactly 
the behavior I wanted. The bug was that a method referred to by the #indexSetter: keyword 
needed to send the #selectedItem: message, which is not mentioned by keyword. Not sure 
what the answer is for that one but I'm working on notes to try to avoid that stupid mistake in 
the future. :)

I'm just saying we should do anything we can to enhance clarity as well as simplify.

 - Dan