<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 6/12/2019 1:19 AM, Luciano Notarfrancesco wrote:
    <blockquote
cite="mid:CAL5GDyofRS8xhZfnY4ktgui9nwmJ9gsrP7X5OuvYaQ2-azNtGQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Awesome, thanks! (That's a google-suggested automatic
          reply, first time I try it, but really thanks).</div>
      </div>
    </blockquote>
    <br>
    :)<br>
    <br>
    BTW, be sure to update to #3798. With this and previous updates,
    this runs in 20 minutes in my PC (without halting):<br>
    <br>
    instances := Object allSubInstances.<br>
    { 'Total: '. instances size} print.<br>
    Time now print.<br>
    1 to: instances size do: [:i|<br>
        i \\ 1000 = 0 ifTrue: [ i print ].<br>
        a := instances at: i.<br>
        aHash := a hash.<br>
        i+1 to: instances size do: [:j|<br>
            b := instances at: j.<br>
            (a = b and: [(aHash = b hash and: [b = a]) not]) ifTrue:
    [self halt]]].<br>
    Time now print.<br>
    <br>
    BTW, I found the StackSizeWatcher in ProcessBrowser (by Hernán
    Wilkinson) extremely useful for dealing with the bugs this snippet
    made visible.<br>
    <br>
    <blockquote
cite="mid:CAL5GDyofRS8xhZfnY4ktgui9nwmJ9gsrP7X5OuvYaQ2-azNtGQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>So to make it clear, the current implementation of
          Collection>>hash implies that if two Collections are
          equal, then they must at least 1) be the same species, and 2)
          have equal elements. New Collections can have more
          requirements in order to be equal, but those two are necessary
          otherwise the hashes won't match. This is the essence of a
          Collection's identity.</div>
      </div>
    </blockquote>
    <br>
    Agreed.<br>
    <br>
    <blockquote
cite="mid:CAL5GDyofRS8xhZfnY4ktgui9nwmJ9gsrP7X5OuvYaQ2-azNtGQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>BTW, do you think 'aCollection includes: anObject' should
          work without errors for arbitrary anObject instance of any
          class? </div>
      </div>
    </blockquote>
    <br>
    Yes. Any errors is a bug or at least a smell, and we'd discuss it...
    Well, no. Adding this as I come to the end of your message. See
    comments there.<br>
    <br>
    <blockquote
cite="mid:CAL5GDyofRS8xhZfnY4ktgui9nwmJ9gsrP7X5OuvYaQ2-azNtGQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>I had a similar problem with algebraic structures (what I
          call Domains), and I ended up implementing #includes: to work
          for arbitrary objects, and a new message #contains: (not the
          best name, might think a better one in the future) that is
          faster and simpler and assumes the objects are of a certain
          type. </div>
      </div>
    </blockquote>
    <br>
    I guess I'd call it something like #containsDomain:, including in
    the selector the assumption about the type. A matter of style, of
    course.<br>
    <br>
    <blockquote
cite="mid:CAL5GDyofRS8xhZfnY4ktgui9nwmJ9gsrP7X5OuvYaQ2-azNtGQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>I don't think we need two messages like that for
          Collections, but I still don't know what's the correct way of
          thinking about Collection>>includes:, and if we think
          that it should work for arbitrary objects we can try a similar
          script to test 'aCollection includes: Object new' in all
          instances of Collections... without trying that, I know that
          Interval fails for anything that is not a Number, not sure if
          should be fixed or not. What do you think?</div>
      </div>
    </blockquote>
    <br>
    Many collections can hold any kind of object. Those should not fail
    when evaluating `aCollection includes: anObject`, for any object.
    Others are specific for some kind of content, like String,
    ByteArray, FloatArray, etc. It is ok for those to raise an error
    when evaluating `aCollection includes: anObject`, if trying to add
    that anObject would also fail. I see no problem there. Still, I
    wouldn't object if people prefer to just make #includes: answer
    false in those cases.<br>
    <br>
    <blockquote
cite="mid:CAL5GDyofRS8xhZfnY4ktgui9nwmJ9gsrP7X5OuvYaQ2-azNtGQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2019 at 5:25
          PM Juan Vuletich <<a moz-do-not-send="true"
            href="mailto:juan@jvuletich.org" 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;">On 6/11/2019 8:49 AM, Luciano
          Notarfrancesco via Cuis-dev wrote:<br>
          > I did this to fish for inconsistencies:<br>
          ><br>
          > instances _ OrderedCollection new.<br>
          > Object withAllSubclassesDo: [:each| instances addAll:
          each allInstances].<br>
          > instances _ instances asArray.<br>
          ><br>
          > 1 to: instances size do: [:i|<br>
          >     a _ instances at: i.<br>
          >     aHash _ a hash.<br>
          >     i+1 to: instances size do: [:j|<br>
          >         b _ instances at: j.<br>
          >         (a = b and: [(aHash = b hash and: [b = a]) not])
          ifTrue: [self <br>
          > halt]]]<br>
          ><br>
          > (I typed it manually here, I hope I copied it right, but
          you get the <br>
          > idea.)<br>
          ><br>
          > Found out this:<br>
          > - FeatureRequest forgets to implement hash;<br>
          > - #() = Semaphore new, but not the other way around, and
          hashes also <br>
          > differ;<br>
          > - similarly, LinkedList new = Semaphore new;<br>
          > - RunArray new = Object new fails because it assumes the
          argument is a <br>
          > Collection and sends isSequenceable;<br>
          > - RunArray new = Text new, but hashes differ;<br>
          > - Set new = Dictionary new but hashes differ;<br>
          ><br>
          > And there are more, I stopped before finishing.<br>
          ><br>
          > I don't know how to fix some of those, and the
          implications of <br>
          > changing the behavior of #= or #hash are not obvious in
          some cases. <br>
          > But I think we should change Collection>>hash to
          set the initial value <br>
          > to 0 instead of 'self species hash', and that would fix
          two of the <br>
          > issues above. What do you think? Other ideas?<br>
          <br>
          I just pushed fixes to most of them. For Semaphore and
          RunArray it is a <br>
          matter of implementing and honoring #species. For Set, it was
          making <br>
          aDictionary is: #Set to answer false. For the others it was
          adding a new <br>
          #hash or #= methods. I don't expect much breakeage.<br>
          <br>
          I'll run now a tweaked (hopefully faster) version of your
          script.<br>
          <br>
          Cheers,<br>
          <br>
          -- <br>
          Juan Vuletich<br>
          <a moz-do-not-send="true" href="http://www.cuis-smalltalk.org"
            rel="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" 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" 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" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a><br>
          @JuanVuletich<br>
          <br>
        </blockquote>
      </div>
    </blockquote>
    <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>