<!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">
    Hi Nicolas,<br>
    <br>
    On 9/30/2019 8:36 PM, Nicolas Cellier via Cuis-dev wrote:
    <blockquote
cite="mid:CAKnRiT5ZSbMsOhx++inQcr6VGrUw6SmZr4xLagbueCZrm0dVMw@mail.gmail.com"
      type="cite">
      <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>
        </div>
      </div>
    </blockquote>
    <br>
    It can be considered a space optimization. Just like Squeak's
    encoding of RGB in a SmallInteger. Other examples in Cuis packages
    include Float32Matrix3x3, Float32Vector3, Float64Matrix?x?,
    Float64Quaternion, Float64Vector?, GPSPosition, All these could use
    ivars, but dont, and inherit from FloatArray or Float64Array.<br>
    <br>
    This makes sense especially on 64 bit images for objects whose parts
    can be 32bit or shorter immediates, and if we build many instances.
    In this cases, I think the space saving overwheights the
    inconvenience of not having real ivars.<br>
    <br>
    <blockquote
cite="mid:CAKnRiT5ZSbMsOhx++inQcr6VGrUw6SmZr4xLagbueCZrm0dVMw@mail.gmail.com"
      type="cite">
      <div dir="auto">
        <div dir="auto">
          <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
                moz-do-not-send="true"
                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: 0pt 0pt 0pt
              0.8ex; border-left: 1px solid rgb(204, 204, 204);
              padding-left: 1ex;">
              <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 moz-do-not-send="true" href="http://www.cuis-smalltalk.org" rel="noreferrer noreferrer" target="_blank">www.cuis-smalltalk.org</a>
<a moz-do-not-send="true" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a moz-do-not-send="true" href="https://github.com/jvuletich" rel="noreferrer noreferrer" target="_blank">https://github.com/jvuletich</a>
<a moz-do-not-send="true" 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
                        moz-do-not-send="true"
                        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 moz-do-not-send="true" href="http://www.cuis-smalltalk.org" rel="noreferrer noreferrer" target="_blank">www.cuis-smalltalk.org</a>
<a moz-do-not-send="true" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a moz-do-not-send="true" href="https://github.com/jvuletich" rel="noreferrer noreferrer" target="_blank">https://github.com/jvuletich</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
                                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 moz-do-not-send="true"
                                href="http://www.cuis-smalltalk.org"
                                rel="noreferrer noreferrer noreferrer"
                                target="_blank">www.cuis-smalltalk.org</a><br>
                              <a moz-do-not-send="true"
                                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 moz-do-not-send="true"
                                href="https://github.com/jvuletich"
                                rel="noreferrer noreferrer noreferrer"
                                target="_blank">https://github.com/jvuletich</a><br>
                              <a moz-do-not-send="true"
                                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 moz-do-not-send="true"
                                href="mailto:Cuis-dev@lists.cuis.st"
                                rel="noreferrer noreferrer"
                                target="_blank">Cuis-dev@lists.cuis.st</a><br>
                              <a moz-do-not-send="true"
                                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 moz-do-not-send="true"
                href="mailto:Cuis-dev@lists.cuis.st" rel="noreferrer
                noreferrer" target="_blank">Cuis-dev@lists.cuis.st</a><br>
              <a moz-do-not-send="true"
                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>
    </blockquote>
    <br>
    <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>