<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 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 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>