<div dir="ltr"><div dir="ltr">Andres,<br></div><div dir="ltr"><br></div><div>(In your first message you suggested asking why the functionality I'm complaining about was designed the way it is. Please re-read my original post in this thread: that's exactly what I was asking. Barring an explicit rationale, my belief is that the current behavior was likely an oversight as opposed to an explicit design decision. Unless someone recalls the discussion from back then or comes across some explicit documentation, we may never know for sure which is the case.)</div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2019 at 6:50 PM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">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">Take the following method.<br>
<br>
Collection>>pvtDoStuff<br>
"So now people can't do super"<br>
<br>
<br>
What prevents anybody from doing this?<br>
<br>
Array>>indirectPvtDoStuffAnyway<br>
<br>
self pvtDoStuff. "so now it's a self send"<br>
self myPvtDoStuff<br>
<br></blockquote><div><br></div><div>Nothing whatsoever. It's also valid in the superclass to send #pvtSubMethod that doesn't exist on super but does on the subclass and that works too. It's only the explicit 'super pvtDoStuff' case (that I've run into so far) that won't work within the class hierarchy the way I'd expect.[1] To me, it's an annoyance because if I really need to send super on it (i.e. a subclass needs to extend, but not replace, the existing functionality), then I'm forced to rename it to something like #private* to do so currently.</div><div><br></div><div>I'm not under the illusion that this mechanism provides any iron clad guarantee that a given method can't/won't be called externally, only that it provides a minimal compiler assist that will slow you down to make an explicit decision when you want to do so. Human beings behaving the way they do, I don't have any illusions that *any* software mechanism put in place would work to truly enforce a concept like privacy. That's fine... it's not what I care about. In my mind, all a mechanism like #pvt* does is signal that 'this method isn't meant to be called by you, it's an internal implementation detail' and if you decide you really need it to be exposed publicly, make an explicit decision to do so in the form of renaming the method. So the compiler error is more a speed bump and one can eliminate said speed bump if/as needed. The problem I see with the super case is that it's an illogical speed bump since as you point out above, there's no other attempt to prevent sending #pvt* up/down the class hierarchy.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There is no such thing as "removing any possible misinterpretation". <br>
The more one pushes in this direction, the more binary the perspective <br>
(either "super bad" or "acceptable"), and the outcome is that one's <br>
particular designs become limited by these general restrictions.<br></blockquote><div><br></div><div>All I am suggesting is that an explicit prefix, as opposed to using method category, would more clearly communicate to developers that those methods were not intended to be called outside the class hierarchy. A problem I've run into numerous times with code that uses say the 'private' category for a given method is that there may be super/subclasses that either forget to categorize it or worse put it in a different category... then what is someone downstream to make of whether or not they should use that method? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In fact, this approach might end up inducing ironic results. Since the <br>
programmer will yield the decision of which message to send to the <br>
system (!), that's yet another instance of enabling not thinking things <br>
through or understanding what's going on. And you know the result of <br>
that: more bad code.<br></blockquote><div><br></div><div>The alternative is relying on inconsistent usage of categories, depending on class/method comments that at best are incomplete etc. I don't see it as yielding to the system as much as the judgement of whoever wrote the code you are using. And in the case of a useful method being made private, a complaint is a useful signal to the developer/maintainer of a piece of code that they need to find some way (either by directly renaming the method in question or by providing an alternative means) of providing the desired functionality externally.</div><div> </div><div>Thanks,</div><div>Phil</div><div><br></div><div>[1] As I've alluded to in my responses to Juan, it also doesn't work going from instance->class or class->instance side. To me, that makes sense: it's (mostly) consistent with how variable visibility works.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 6/11/19 10:43, Phil B via Cuis-dev wrote:<br>
> Ah, then count me as a firm 'yes' vote! I've been in favor of that <br>
> forever as I agree making things explicitly pvt* removes any possible <br>
> misinterpretation. The only problem is that many (most?) the senders of <br>
> those set* methods tend to come from class-side so pvt* visibility would <br>
> have to extend there as well for this to work. (What I tend to do <br>
> currently for those cases in my code currently is use a private* prefix.)<br>
> <br>
> On Tue, Jun 11, 2019 at 1:28 PM Juan Vuletich <<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a> <br>
> <mailto:<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>>> wrote:<br>
> <br>
> __<br>
> On 6/10/2019 8:15 PM, Phil B wrote:<br>
>><br>
>> Why do you think the #privateSetX:setY: looks silly? I think<br>
>> it's a decent placeholder that I read as saying 'we really<br>
>> want this to be immutable and are indicating this as private<br>
>> to reflect that fact until we can actually make it immutable<br>
>> via the VM'<br>
>><br>
> <br>
> Because the comment begs you not to call it. If we just add the pvt<br>
> prefix, then it is way more robust. You need to add a new method to<br>
> set the ivars, and clearly you are on your own then.<br>
> <br>
>><br>
>> Private categories are good for getting methods out of the way in<br>
>> the main browser but I'm not wild about them beyond that. The<br>
>> main issue I have with private categories is that they are so easy<br>
>> to overlook in the browsers. For example, if you're in the<br>
>> message finder and you do a search on 'set', the fact that it<br>
>> shows up as private* makes it very clear that it's not a method<br>
>> you should be using generally. If the private prefix were<br>
>> removed, you'd have to be sure to select an implementor in the<br>
>> right pane (and hope that they are consistently categorized) and<br>
>> then be sure to look for the category buried in the method<br>
>> annotation below (which might be 'private' or 'private -<br>
>> someSubCategory' etc)... ugh! Or if you see a raw selector (i.e.<br>
>> #setX:setY:) in code now you have to do the above as opposed to<br>
>> just looking at the selector name.<br>
>><br>
>> That said, if it really bugs you or others, I will live without<br>
>> the prefix. But I do find it helpful.<br>
>><br>
>> Thanks,<br>
>> Phil<br>
> <br>
> I'm suggesting the opposite! To start adding the pvt prefix to<br>
> methods we intend to be private (i.e. those already in a 'private*'<br>
> category).<br>
> <br>
> Cheers,<br>
> <br>
> -- <br>
> Juan Vuletich<br>
> <a href="http://www.cuis-smalltalk.org" rel="noreferrer" target="_blank">www.cuis-smalltalk.org</a> <<a href="http://www.cuis-smalltalk.org" rel="noreferrer" target="_blank">http://www.cuis-smalltalk.org</a>><br>
> <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a><br>
> <a href="https://github.com/jvuletich" rel="noreferrer" target="_blank">https://github.com/jvuletich</a><br>
> <a 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>
> <br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div></div>