[Cuis] Where to put the complexity?

[Phil (list)]

On Mon, 2015-06-29 at 13:23 -0300, 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
> 

Thanks for the feedback Ken.  I wasn't concerned with the computing
resources (at all) but rather the overall system complexity that results
from these one-shot types of classes and methods.  i.e. is it worth an
extra class or method here and there to save 1-2 lines of code in a
single, or even a couple, method(s).  Just spit-balling there are
probably ~100 (maybe as many as 200) classes, and who knows how many
methods, like this left in Cuis.  Agreed that this is getting into an
area of diminishing returns.

One thing that is different to me about PartsBinMorph, at least at first
glance, is that it involves both state and behavior.  I was really
thinking more of the extremes where classes exist purely to do one or
the other since they are often at best saving 1-2 lines of code
somewhere else.

> 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...
> 

And thank you Juan.  In the case of these one-shot exceptions, I was
thinking that the information could be communicated via the signal:
text.  i.e. rather than raising ReparseAfterSourceEditing, one could
instead raise Notification signal: #ReparseAfterSourceEditing.  However,
that would require that the exception handler trigger on Notification,
check the signal text in the handler, and if it isn't
#ReparseAfterSourceEditing re-raise the Notification if it determines
that it's not handling it after all.

> $0.02, not really a strong opinion.

I could go either way on this as well which is why I asked...

> 
> Cheers,
> Juan Vuletich
> 

Thanks,
Phil