<div dir="ltr">(sorry for all the posts on this subject)<div><br></div><div>Just to clarify, I'm in favor of using pvt*/private* where it makes sense.  I'm not in favor of extending pvt* visibility class-side as it would create a new inconsistency between variables and methods similar to the one that this whole thread started to try to resolve. (i.e. we'd be solving one problem and creating another)</div><div><br></div><div>This kind of brings it back to the method comment that Juan wants to get rid of: while I think that a more explicit method name for those setters would be a good thing rather than relying on the comment alone, I also think that keeping a method comment explaining *why* we made those methods in particular private (i.e. we really don't want the methods to even exist as we want immutable instances) is a good thing.  Just look at how we're trying to reverse-engineer why pvt* works the way it does... some better documentation left behind by someone 20 years ago would have avoided this.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2019 at 1:56 PM Phil B <<a href="mailto:pbpublist@gmail.com">pbpublist@gmail.com</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 dir="ltr"><div>Juan/Hernan,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2019 at 1:37 PM Juan Vuletich <<a 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"><u></u>

  
    
  
  <div bgcolor="#ffffff">
    On 6/11/2019 8:56 AM, Hernan Wilkinson wrote:
    <blockquote type="cite">
      <div dir="ltr">A few comments:
        <div>1) super pvt* it is not allowed because "private" parts of
          a class are only visible to its instances, at least that it is
          how c++/java and the like treat private stuff (methods, vars,
          etc). So in Java you can not do super.prvt*(). </div>
        <div>The behavior you are proposing Phil would be like
          "protected" in those languages. In fact, we could say that
          inst. vars. in Smalltalk are protected in the c++/java
          parlance.</div>
        <div>So, my guess is that the current restriction on super pvt*
          came from that understanding "private".</div>
        <div>Having said that, I see no problem to change that
          restriction and treat pvt* messages as they were protected
          although it will be confusing to explain when compared to
          other languages. I think it would be better in that case to
          have prt* (protected) instead of pvt* but that would generate
          a migration problem...</div>
      </div>
    </blockquote>
    <br>
    Mhh. Difficult decision. We could keep the 'pvt' prefix, but in
    methods that handle them, we could add comments stating that it is
    like what c++/java calls "protected". The error could be "Protected
    messages may only be sent to self" (protected instead of private).<br></div></blockquote><div><br></div><div>I've done both Java and C++ development and it never even occurred to me that they might have been the inspiration for pvt*.   That makes a lot of sense though as I think this convention was added late-90's.</div><div><br></div><div>The reason it probably never occurred to me at least is because I've always been bothered by the definition of 'private' as it applies to ivars/cvars vs pvt* for methods.  So I guess the question is, which is more confusing to users: that pvt* wouldn't work the way they're used to in other languages or that pvt* is internally inconsistent with the ivar/cvar concept of privacy.</div></div></div>
</blockquote></div>