<!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 6/10/2019 8:15 PM, Phil B wrote:
    <blockquote
cite="mid:CAMJMOegvfCsVurJHrq+wbRhF1RcVRouCBqsJzmLHBZkBhW71hg@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, Jun 10, 2019 at 6: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;">On 6/10/2019 5:09 PM, Phil B via
            Cuis-dev wrote:<br>
            > Something I've never understood is why you can't send
            super on pvt* <br>
            > methods?  The sends are still contained to the class
            hierarchy and <br>
            > it's legal for a superclass to send to a pvt* that is
            only defined on <br>
            > a subclass... so why isn't going in the other direction
            allowed?<br>
            <br>
            Good question! I see no reason. Given that a class can
            assign values to <br>
            inherited variables, there's already no protection. So I
            think that <br>
            calling super pvt* method should be allowed. Anybody can see
            a reason?<br>
            <br>
          </blockquote>
          <div><br>
          </div>
          <div>Cool... I too would be curious if anyone is aware of a
            historical reason why this should not be allowed or was it
            just an oversight?</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;">
            BTW, we'd really make methods such as #setCollection:, <br>
            #setNumerator:denominator:, actually all methods set*, all
            methods <br>
            private* and all methods in a 'private*' category actually
            private... <br>
            For example the comment at #privateSetX:setY: looks so
            silly.<br>
            <br>
          </blockquote>
          <div><br>
          </div>
          <div>Why do you think the #privateSetX:setY: looks silly?  I
            think it's a decent placeholder that I read as saying 'we
            really want this to be immutable and are indicating this as
            private to reflect that fact until we can actually make it
            immutable via the VM' <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Because the comment begs you not to call it. If we just add the pvt
    prefix, then it is way more robust. You need to add a new method to
    set the ivars, and clearly you are on your own then.<br>
    <br>
    <blockquote
cite="mid:CAMJMOegvfCsVurJHrq+wbRhF1RcVRouCBqsJzmLHBZkBhW71hg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>Private categories are good for getting methods out of
            the way in the main browser but I'm not wild about them
            beyond that.  The main issue I have with private categories
            is that they are so easy to overlook in the browsers.  For
            example, if you're in the message finder and you do a search
            on 'set', the fact that it shows up as private* makes it
            very clear that it's not a method you should be using
            generally.  If the private prefix were removed, you'd have
            to be sure to select an implementor in the right pane (and
            hope that they are consistently categorized) and then be
            sure to look for the category buried in the method
            annotation below (which might be 'private' or 'private -
            someSubCategory' etc)... ugh!  Or if you see a raw selector
            (i.e. #setX:setY:) in code now you have to do the above as
            opposed to just looking at the selector name.</div>
          <div><br>
          </div>
          <div>That said, if it really bugs you or others, I will live
            without the prefix.  But I do find it helpful.</div>
          <div><br>
          </div>
          <div>Thanks,</div>
          <div>Phil </div>
        </div>
      </div>
    </blockquote>
    <br>
    I'm suggesting the opposite! To start adding the pvt prefix to
    methods we intend to be private (i.e. those already in a 'private*'
    category).<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>