<div dir="auto"><div>Hi Juan,</div><div dir="auto">Something strikes me.</div><div dir="auto">Isn't this example a pathological case of inheritance? Is Color really kind of Collection? Wouldn't any object potentially be a collection of its instances variables in this case?<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Le lun. 30 sept. 2019 à 22:51, Juan Vuletich via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">cuis-dev@lists.cuis.st</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
    
    
  
  <div bgcolor="#ffffff" text="#000000">
    (inline)<br>
    <br>
    On 9/30/2019 4:46 PM, Phil B wrote:
    <blockquote type="cite">
      <div dir="ltr">OK, now I understand what you are going for... this
        seems like a convenience optimization in the wrong place. 
        Wouldn't it make more sense to have this logic in something like
        #elementSpecies?  </div>
    </blockquote>
    <br>
    No, this is not what I tried to do. 'Color red species = FloatArray'.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">Most of my code that uses #species with collections
        is expecting it to return what kind of collection it should use
        when creating some sort of collection-based copy/result, not an
        individual element.  </div>
    </blockquote>
    <br>
    That is exactly what I tried to do. For instance, Color is a suclass
    of FloatArray, that adds the restriction that it must have 3
    elements. TranslucentColor is similar, but must be of size = 4. If
    you do a #select: on them, the answer could have less than 3 (or 4)
    elements, and then, the correct class for the answer is FloatArray
    and not Color. See what happens with 'Color red select: [ :v | v
    > 0.5 ]'.<br>
    <br>
    Does this reasoning apply to the examples you are seeing?<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">Also, sometimes the collection *is* the element
        (i.e. Vector*) as far as most code is concerned.</div>
    </blockquote>
    <br>
    Not sure how this relates to what #species answers... Maybe
    elaborate a bit on this.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Lots of FFI code uses ArrayedCollection subclasses for
          buffers of various types and you typically want #species to
          return the appropriate collection type (not always of the same
          class) when doing something with it. <br>
        </div>
      </div>
    </blockquote>
    <br>
    Exactly. Besides, any collection class is free to redefine #species
    appropriately.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div> It also seems a bit weird for ArrayedCollection to
          sometimes return the class of its elements while other
          collections return the class of the collection itself (which
          it pretty much has to for heterogeneous collections.)</div>
      </div>
    </blockquote>
    <br>
    It should always be a collection class, that is appropriate as a
    result.<br>
    <br>
    The problem I do see is that, perhaps, 'Color red collect: [ :v | v
    / 2 ]' could answer an instance of Color. So maybe  we could make
    the search for an appropriate superclass in a separate message, like
    #speciesForPotentiallyShorterResult (uhg that's ugly), and only call
    this other method from #select:, but not from #collect: or #=.<br>
    <br>
    Thanks,<br>
    <pre cols="72">-- 
Juan Vuletich
<a href="http://www.cuis-smalltalk.org" rel="noreferrer noreferrer" target="_blank">www.cuis-smalltalk.org</a>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a href="https://github.com/jvuletich" rel="noreferrer noreferrer" target="_blank">https://github.com/jvuletich</a>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
    <br>
    <br>
    <blockquote type="cite">
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2019 at 7:49
          AM Juan Vuletich <<a href="mailto:juan@jvuletich.org" rel="noreferrer noreferrer" target="_blank">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">
          <div bgcolor="#ffffff"> <br>
            Oh, apologies. I thought those were harmless and didn't even
            comment about them. You can get by by removing #3889 and
            #3890 until we understand and fix.<br>
            <br>
            The idea is to fix things like<br>
            <br>
            Color red select: [ :v | v > 0.5 ]<br>
            <br>
            This shouldn't answer an instance of Color, but of the
            closest superclass that can have instances of any size. The
            same happens for many other classes in optional packages.
            How is this affecting your code? I guess you have
            ArrayedCollection classes that answer a non-zero value to
            #numElements, but their #species should be the class, right?
            What would happen if a #select: answers a smaller instance?
            And more important, what else are we using #species for?<br>
            <br>
            Thanks,<br>
            <pre cols="72">-- 
Juan Vuletich
<a href="http://www.cuis-smalltalk.org" rel="noreferrer noreferrer" target="_blank">www.cuis-smalltalk.org</a>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a href="https://github.com/jvuletich" rel="noreferrer noreferrer" target="_blank">https://github.com/jvuletich</a>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
            <br>
            On 9/30/2019 7:29 AM, Phil B wrote:
            <blockquote type="cite">
              <div dir="ltr">Juan,
                <div><br>
                </div>
                <div>Could you explain the why behind the
                  ArrayedCollection #species change?  I understand what
                  you're doing, but not why... (rather important since
                  my subclasses are now breaking and I'm not following
                  the reasoning yet)</div>
                <div><br>
                </div>
                <div>Thanks,</div>
                <div>Phil</div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">On Sun, Sep 29, 2019
                  at 1:57 PM Juan Vuletich via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" rel="noreferrer noreferrer" target="_blank">cuis-dev@lists.cuis.st</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">Hi Folks,<br>
                  <br>
                  After many requests made during a long time, it is
                  finally here. We can <br>
                  now serialize almost any BlockClosures, including
                  those that use outer <br>
                  temps, self, instance variables, etc.<br>
                  <br>
                  The only closures that can't be serialized are those
                  that do non-local <br>
                  returns (^stuff) or super sends. These are usually not
                  passed around or <br>
                  stored in variables, so I don't expect this to be a
                  limitation.<br>
                  <br>
                  Updates now at GitHub.<br>
                  <br>
                  Cheers,<br>
                  <br>
                  -- <br>
                  Juan Vuletich<br>
                  <a href="http://www.cuis-smalltalk.org" rel="noreferrer noreferrer noreferrer" target="_blank">www.cuis-smalltalk.org</a><br>
                  <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a><br>
                  <a href="https://github.com/jvuletich" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/jvuletich</a><br>
                  <a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a><br>
                  @JuanVuletich<br>
                  <br>
                  -- <br>
                  Cuis-dev mailing list<br>
                  <a href="mailto:Cuis-dev@lists.cuis.st" rel="noreferrer noreferrer" target="_blank">Cuis-dev@lists.cuis.st</a><br>
                  <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
                </blockquote>
              </div>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </div>

-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" rel="noreferrer noreferrer" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div></div>