[Cuis] Where to put the complexity?

[Dan Norton]

Hi,

I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The 
question is how to view it without disabling my antivirus plus surrendering a bunch of 
"required" info. BTW I'm running Win7, IE, and ESET.

Any other possibilities?

 - Dan

On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:

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