[Cuis] Where to put the complexity?

[Nicolas Cellier]

2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:

> 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
>
>
Since you are using the right keywords, maybe it's time to view it again
Simple made easy
http://www.infoq.com/presentations/Simple-Made-Easy

_______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150701/06743c77/attachment-0003.html>