[Cuis-dev] Interesting thoughts about Color

[Phil B]

On Mon, Apr 29, 2019, 9:11 AM <ken.dickey at whidbey.com> wrote:

> Phil,
>
> Naming is important. I am always for better naming.
>
> asNumber, asString, asRope, .. I expect an #asDarker method to answer an
> object of class #Darker.
>

Notice that in my response to Juan I said that what I came up with was
#asDarkerColor for precisely that reason.  As I think about it more, if we
were to explicitly decide that Color is to be treated as an immutable
object (which I'm in favor of), the issue I have with Color's definition of
#darker (and other similar methods) is probably more that I'm not convinced
that it is the strongest use of those valuable terms. (i.e. requesting a
new instance vs instructing an existing one to do something to itself for
other mutable cases which are likely to be more common).

So I believe either we've used a strong term for a weak purpose or people
will have to semantically overload it to use it elsewhere.  Again, I also
like immutable classes but that doesn't mean I'm going to ignore the fact
that 90%+ of the classes in the image *aren't* immutable.


> With respect to polymorphism, I will give a couple of examples where the
> code does not care about the shape or immutability of the underlying
> data:
>
>
> vvv=== "foo and bar don't care" ===vvv
>
> Feature require: #'Ropes'. "immutable strings"
>
> foo := [ :s | s asLowercase].
>   "both answer  'año Comé tomá Camión' "
> (foo value: 'año Comé tomá Camión') asString.
> (foo value: ('año Comé tomá Camión' asRope)) asString.
>
> (foo value: ('año Comé tomá Camión' asRope)) class. "--> FlatRope"
>
> bar := [ :v | v at: 2 ].
> "all answer $b"
> bar value: {#a. $b. 'c'.}.
> bar value: ('abc' asRope).
> bar value: 'abc'.
> bar value: #abc.
>
> ^^^=== "foo and bar don't care" ===^^^
>
> Does this make sense?
>

Of course... both of the classes in your example are String-like things for
the subset of methods they both respond to.  As long as they behave
consistently for that subset of methods, and don't contradict other methods
in the image, things are as they should be.  But I also wouldn't
necessarily expect 'bar value: Morph new' to work or make any sense.

Now, if you implemented a #darker method on one or both of those
String-like classes which returned a darker (in a prose sense i.e. bleaker)
version of the text contained, I would have a problem because now you're
semantically overloading #darker.  (And that's ignoring that this new
#darker method is probably also language specific (i.e. English, Spanish,
whatever))  That's an issue: using generic terms for narrow and/or
inconsistent purposes.

This highlights both a strength and weakness of the Smalltalk approach:
because the language has a very prose-like approach in a single namespace,
what you call things becomes vital because any given class can throw a
wrench into the works with bad (ambiguous, inconsistent or overloaded)
names.


> Cheers,
> -KenD
>

Thanks,
Phil

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190429/839fc27c/attachment.html>