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

Juan Vuletich juan at jvuletich.org
Tue Jun 11 10:28:21 PDT 2019

On 6/10/2019 8:15 PM, Phil B wrote:
> Juan,
> On Mon, Jun 10, 2019 at 6:24 PM Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>> wrote:
>     On 6/10/2019 5:09 PM, Phil B via Cuis-dev wrote:
>     > Something I've never understood is why you can't send super on pvt*
>     > methods?  The sends are still contained to the class hierarchy and
>     > it's legal for a superclass to send to a pvt* that is only
>     defined on
>     > a subclass... so why isn't going in the other direction allowed?
>     Good question! I see no reason. Given that a class can assign
>     values to
>     inherited variables, there's already no protection. So I think that
>     calling super pvt* method should be allowed. Anybody can see a reason?
> 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?
>     BTW, we'd really make methods such as #setCollection:,
>     #setNumerator:denominator:, actually all methods set*, all methods
>     private* and all methods in a 'private*' category actually private...
>     For example the comment at #privateSetX:setY: looks so silly.
> 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).


Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190611/5129aa80/attachment.htm>

More information about the Cuis-dev mailing list