[Cuis] ColorEditor updated

[Dan Norton]

Hi Ken,

Comments in line.

On 1 Nov 2015 at 20:52, KenD wrote:

> On Sat, 31 Oct 2015 22:01:06 -0400
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> > On 29 Oct 2015 at 16:56, KenD wrote:
> ..
> > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > updates.  You can file it in and check senders.
> ..
> > I've done that and I see that messages to SystemChangeNotifier are
> not required in order to  use the method.
> > 
> > Also, the dependency mechanism itself uses #when:send:to:.
> > 
> > Any object can use  #when:send:to: because it is an Object
> instance method. 
> > 
> > So, should this be named a different mechanism or is it just a
> different use of the 
> > dependency mechanism?
> > 
> > If it's a different mechanism, is "Signals" the right name? This
> by Marcel Taeumel:
> > 	
> >
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjec
> ts/wiki/signals#Featu
> > reComparison
> 
> Hi Dan.
> 
> I took a look at the Signals implementation some time ago and my
> recollection is that I found the implementation to be complex and
> less useful than I had hoped.
> 
> For my limited uses, I prefer #when:send:to:
> 
> Simplicity wins.

+1

  In the longer term I hope somebody gets a chance
> to rewrite the older #changed: code to use the #when:send:to:
> mechanism so that we can remove #changed: .
> 
> I agree that having two update mechanisms is one too many.  Adding a
> third dependency update, Signals, would be going in the wrong
> direction IMHO.
>

That's fine. I was casting about for some name besides " #when:send:to: mechanism" for 
use in a brief essay on PluggableListMorph Principles of Operation when I came across 
Signals. I already wrote a paragraph on Dependency Mechanism.

So, the simple principle here is to just use #when:send:to: and forget about or maybe 
deprecate #changed: and #update:? The advantage IIUC is #when:send:to:
	can be sent by any object, 
	the receiver can be any object, 
	the to: parameter can be any object, and 
	the send: parameter doesn't necessarily have to exist because WeakMessageSend 
is used! 

What a deal :).

However, I see a problem common to dependency and #when:send:to: which is the 
identification and explanation of the various symbols which are communicated as the 
parameters for send: or changed: . When you're trying to design a model or view similar to 
something already in existence, the tools are not much help with that.

I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>

Would appreciate any thoughts.

 - Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151102/3d081884/attachment-0004.html>