[Cuis-dev] Why can't you send to super on private (pvt*) methods?

[Andres Valloud]

Take the following method.

Collection>>pvtDoStuff
	"So now people can't do super"


What prevents anybody from doing this?

Array>>indirectPvtDoStuffAnyway

	self pvtDoStuff.  "so now it's a self send"
	self myPvtDoStuff


There is no such thing as "removing any possible misinterpretation". 
The more one pushes in this direction, the more binary the perspective 
(either "super bad" or "acceptable"), and the outcome is that one's 
particular designs become limited by these general restrictions.

In fact, this approach might end up inducing ironic results.  Since the 
programmer will yield the decision of which message to send to the 
system (!), that's yet another instance of enabling not thinking things 
through or understanding what's going on.  And you know the result of 
that: more bad code.

On 6/11/19 10:43, Phil B via Cuis-dev wrote:
> Ah, then count me as a firm 'yes' vote!  I've been in favor of that 
> forever as I agree making things explicitly pvt* removes any possible 
> misinterpretation.  The only problem is that many (most?) the senders of 
> those set* methods tend to come from class-side so pvt* visibility would 
> have to extend there as well for this to work. (What I tend to do 
> currently for those cases in my code currently is use a private* prefix.)
> 
> On Tue, Jun 11, 2019 at 1:28 PM Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>> wrote:
> 
>     __
>     On 6/10/2019 8:15 PM, Phil B wrote:
>>
>>         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'
>>
> 
>     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.
> 
>>
>>     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.
>>
>>     That said, if it really bugs you or others, I will live without
>>     the prefix.  But I do find it helpful.
>>
>>     Thanks,
>>     Phil
> 
>     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).
> 
>     Cheers,
> 
>     -- 
>     Juan Vuletich
>     www.cuis-smalltalk.org  <http://www.cuis-smalltalk.org>
>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>     https://github.com/jvuletich
>     https://www.linkedin.com/in/juan-vuletich-75611b3
>     @JuanVuletich
> 
>