[Cuis] ColorEditor updated

[Juan Vuletich]

(inline)

On 11/2/2015 5:58 PM, Dan Norton wrote:
> 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 forsend: 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.
>

Well, doing senders on any symbol (method selectors, but also event 
names) shows all references to it. I don't think it is that bad, but, do 
you have ideas for improvements on this?

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

Let me disagree. Cuis includes 204019 characters in class comments. That 
would be like 2000 to 4000 lines, right? For a system with less than 
100kLOC. Top 10 classes with extensive class comments are: BitBlt 
SmartRefStream Float ClosureScanner Color ContentPack Monitor 
AndreasSystemProfiler EventSensor ReferenceStream. Just check them. 
Several of these are rather recent, some were written specifically for 
Cuis.

We also have  27058 bytes of comments at the top of methods. Some 
methods with great comments are #vmParameterAt: #entriesIn: 
#eliotsClosureMeasurements2On: #getCurrentWorkingDirectory 
#whatIsAPrimitive #asUtf8: #howToModifyPrimitives #applySimpleGamma:to: 
#linearTosRGBGamma: #localMicrosecondClock #findBinaryIndex:do:ifNone: 
#findBinary:do:ifNone: #spyAllOn: , etc.

There is a lot to be learnt about the system from reading comments. And 
we want to improve.

(BTW, querying the system to find this out took me less time than 
writing this email)

> Would appreciate any thoughts.
>
>  - Dan
>

I think that both comments and tools are useful and should be enhanced.

Cheers,
Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20151106/8f076245/attachment-0004.html>