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

[Hernan Wilkinson]

A few comments:
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*().
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.
So, my guess is that the current restriction on super pvt* came from that
understanding "private".
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...
2) About treating methods in private categories as private methods, I think
it is not a good idea because the category of a method can change from a
"public" category to a "private" one and valid message send would become
invalid which is impossible to check in a dynamic env. as Smalltalk. Using
pvt in the beginning of the message name solves that problem. (BTW, this
made me realize that the rename message does not handle this situation
correctly, I mean when renaming a public to a private selector).

Cheers
Hernan.

On Tue, Jun 11, 2019 at 3:05 AM Phil B via Cuis-dev <cuis-dev at lists.cuis.st>
wrote:

> Juan,
>
> After reading Luciano's response I realized I probably completely
> misunderstood what you were saying here...
>
> On Mon, Jun 10, 2019 at 6:24 PM Juan Vuletich <juan at jvuletich.org> wrote:
>
>> 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.
>>
>
> Are you proposing that we extend the visibility to class-side as well and
> make these methods #pvt* or treating members of the 'private' category[1]
> as if they were #pvt*?  I'm still not feeling like I completely understand
> what you're suggesting...
>
> Thanks,
> Phil
>
> [1] If it's the latter, keep in mind from my previous response that there
> are often multiple private* categories in other people's code... would we
> handle those (based on a private prefix?) or simply say only 'private' is
> private?
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190611/1010d3c9/attachment.htm>