[Cuis-dev] Interesting thoughts about Color

[Phil B]

Ken,

On Sun, Apr 28, 2019 at 10:06 PM <ken.dickey at whidbey.com> wrote:

> On 2019-04-28 17:57, Phil B wrote:
>
> > Ken,
> >
> > I'm not following your thinking here.   What other implementations of
> > things like #darker are you thinking of and how would renaming break
> > encapsulation?
> >
> > As an example, let's say we had Form implement #darker which darkened
> > the image and Color where #darker returns a new, darker color.  I'd see
> > that as semantic overloading, not polymorphism.   And in the event we
> > actually wanted the Form implementation to return a new, darkened Form,
> > how would calling it #asDarkerForm break encapsulation?  To me, that's
> > just making it clear that you are not darkening the existing image but
> > rather creating a new one... I still have no idea what's going on
> > inside the object, only what I expect it to do/return.
>
> I tend to think of immutable, functional data structures.  So I don't
> expect 'foo darker' to return a mutable object.
>
>
OK, now I understand where you're coming from.  I'd simply point out that
in the vast majority of cases, Smalltalk code has not been nor is it
currently immutable or functional 90+% of the time.  If we wanted to make
it be that, I'd be fine with it... as long as it were done consistently
across the image and not just in islands/pockets.


> How would 'foo asDarker' help me?
>
>
To you and me in the short term, it doesn't.  It's work to change
functioning code.  Over the long term, it helps as functionality gets added
to the base image and packages get ported/created.  I believe it would also
help new users who are trying to figure out this whole Smalltalk 'thing'
that people like us tend to go on about.


> Why bother to go through a lot of working code and change #darker to
> #asDarker to distinguish cases where uses of #darker returns a mutable
> object?
>

First: why bother?  Because if we don't, we've either agreed that the
generic #darker message (a one word unary, pretty valuable real estate)
means one of:
a) implementors of it should return a new, darker copy of themselves.
(doesn't sound very universally useful... are we sure we want to use up
this name on it?)
b) implementors of it can do whatever makes the most sense to them ignoring
what other implementors mean when they use it... names are meaningless.[1]

Second: a lot of work. Well, it's actually pretty trivial thanks to
Hernan's refactoring work: you just load the base image with all packages
and refactor a handful of method names... as long as there's no semantic
overloading. (one benefit of avoiding semantic overloading: you don't have
to worry about teasing apart overloaded method names to make changes like
this.  We've had previous refactorings like #value which I found quite
painful to deal with largely because there is/was so much overloading.)


> Where is the semantic distinction helpful?
>

Everywhere.[2]  I'd argue that if we don't minimize semantic
ambiguities/overloading, Smalltalk quickly becomes a middling language at
best since method names largely *are* the language.[3]  The more one has to
scratch their head and peek into otherwise working method implementations
to answer questions like 'why the hell isn't this #foo working the way that
other #foo does?', the less powerful/interesting Smalltalk is as a
language.  Also, isn't needing to either 'just know' or look inside a
method to see why it's behaving differently encapsulation failure in a
different direction? (instead of implementation details leaking out, you
have to crack the method open and look at the implementation details to
understand what is going on because the method name lied to you by doing
something unexpected.)

[1] Use the source, Luke!

[2] I'm not saying it's the only or even the most important thing we have
to worry about, but it is one of the important things.

[3] If in conversation I were to say "There there waiting for there friends
at the club There" most people would have a difficult time following what I
just said.  But I'm not speaking so maybe this helps: "They're there
waiting for their friends at the club, 'There'"  (still not the easiest
sentence to parse, but doable if one is reasonably proficient in English.
Notice that written English tends to include hints in syntax, spelling and
punctuation to help us parse things that sound the same)  Granted, the VM
doesn't care if we semantically overload otherwise identical syntax.  But
to the human reading/writing the code, if there are a handful of
semantically different #darker methods, a dozen semantically different #foo
methods etc. etc. Smalltalk can quickly degenerate into a word salad and
becomes cumbersome for experienced users to follow and (more) confusing for
new users to even get started.  You don't get polymorphism by re-using a
name, you get it by re-using the meaning that goes along with the name.
The former without the latter is just operator overloading.


> -KenD
>

Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190429/827fee38/attachment.html>