<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 10/1/2019 2:39 AM, Phil B wrote:
<blockquote
cite="mid:CAMJMOei9uB5eg1nfQO3+xz4kz_TMYgjzKm-FsGimDz2Bb0LFbQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div dir="ltr">Juan,</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2019 at
11:24 PM Juan Vuletich <<a moz-do-not-send="true"
href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">Please, let's restart this discussion
with a different focus. Let's <br>
forget for a while about #species, that is a private
message, and lets <br>
focus on external behavior. Let's go to #species or an
alternative <br>
implementation strategy afterwards. Also, please let's use
examples.<br>
</blockquote>
<div><br>
</div>
<div>Well, um, err... you're kind of taking my main objection
out of the scope of discussion. If you don't redefine
#species I'm sort of OK with what you want (i.e. I probably
won't use it for the reasons cited in my response in
Nicolas' thread[1], but I won't try to stand in the way of
you adding the functionality you want)</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<br>
Take a fresh image. Evaluate:<br>
<br>
Color red select: [ :v | v > 0.5 ].<br>
<br>
Color red collect: [ :v | v printString ].<br>
<br>
Both fail. #select: fails because it might answer less than
3 elements, <br>
and a Color must have 3 elements. #collect: fails because
the answer <br>
elements might be of any class, but Color components must be
Float.<br>
</blockquote>
<div><br>
</div>
<div>Yep. Another solution would be to override #select: etc.
for Color with 'self error: 'Not a collection!'' OK, I'm
not serious about all those overrides, but my point (per my
response in the other thread) is that externally we
shouldn't be depending on Color to be a collection.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<br>
Possible solutions might be answering FloatArray (fixes
#select: but not <br>
#collect:) or Array (fixes both). Changesets #3889 and #3890
attempt to <br>
fix #select: by looking for some superclass that doesn't
enforce a <br>
specific number of elements, in #species. In this
implementation, the <br>
answer of #species only changes for classes that do enforce
a specific <br>
number of elements.<br>
</blockquote>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;"><br>
As another example of the #collect: problem, see<br>
<br>
<br>
'Hello' collect: [ :c | c numericValue ]<br>
<br>
String chooses to reimplement #collect: . A more general
solution would <br>
be desirable.<br>
</blockquote>
<div><br>
</div>
<div>String is a good example of another class where it's
collection-ness has been even more abused, IMO.[2] I would
much rather have code that need it, however redundant, do
something along the lines of 'somestring' asCharacters.
That would make it perfectly clear when you need to pierce
it's String-ness and treat it as a sequence of characters.
I expect most Smalltalkers would hate this idea.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<br>
Please provide other actual examples that I can try in a
Cuis image <br>
where the assumptions made for Color become invalid, and
your code <br>
breaks. Or provide examples I can try of how you use
#species, and your <br>
code breaks with #3889 and #3890. I really want to
understand the <br>
problems you see, and I find it very difficult with only an
abstract <br>
description.<br>
</blockquote>
<div><br>
</div>
<div>The first example I ran into was in Vector3>cross:
(you can see an implementation of it here: <a
moz-do-not-send="true"
href="https://github.com/pbella/Cuis-OpenGL/blob/master/3DTransform.pck.st#L2247">https://github.com/pbella/Cuis-OpenGL/blob/master/3DTransform.pck.st#L2247</a>)
though pretty much any sender of #species (I have over 200
in my image) potentially applies: what you're returning
changes the definition of #species and therefore may[3]
break existing code. What's most problematic about this
change is that because it's relatively subtle, it may not be
immediately obvious in all cases what the breakage is
because existing code will kinda-sorta work: you'll get back
a class which may mostly work right up until the point that
it doesn't which might be pretty far from the sender of
#species that resulted in the now problematic instance.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<br>
Thanks,<br>
<br>
-- <br>
Juan Vuletich<br>
</blockquote>
<div><br>
</div>
<div>Thanks,</div>
<div>Phil</div>
<div><br>
</div>
<div>[1] It's not an abstract objection: I actually have
Color-compatible implementations that aren't in the
Collection hierarchy that I want to keep interchangeable at
an instance level.</div>
<div><br>
</div>
<div>[2] This also isn't an abstract objection. I have lots
of object-walking code that I have to specifically say
'enumerate (or whatever) this collection only if it's a
non-String collection' to avoid all sorts of issues. From
the standpoint of my code, String is an atomic type that
logically (usually) doesn't make sense to treat as a
collection.</div>
<div><br>
</div>
<div>[3] Now you may say 'Ha! See... "may" break.. how big a
problem can it be then?' It means it's among the biggest
PITA-type breakage you can have. It won't always, and won't
immediately, break things. When it does, have fun tracking
it down in your code. Great, now you've tracked it down...
oh crap, that method now uses ad hoc polymorphism... now
what?</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
I took a look at your code, and it seems to assume that #species is
a synonym for #class. I'd rather call #class, but that's not the
main issue here. <br>
<br>
The changes I did to #species are not useful, because we need a
better solution that treats #select: (same class of elements,
possibly different number of them) and #collect: (possibly different
kind of elements, but same number of them) in a distinct way.<br>
<br>
Besides, I made Color (the motivation for that change) no longer be
a Collection, as you, Nicolas and Hernán have suggested, and just
told in a separate email.<br>
<br>
So, I removed ArrayedCollection>>#species.<br>
<br>
Thanks for caring.<br>
<br>
Cheers,<br>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
</body>
</html>