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

Juan Vuletich juan at jvuletich.org
Tue Jun 11 10:37:05 PDT 2019


On 6/11/2019 8:56 AM, Hernan Wilkinson wrote:
> 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...

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).

> 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.

Yes. What I suggest is to start adding the pvt prefix to existing 
methods we want to be private. For example, those in 'private*' 
categories and selectors starting with 'private'.

> (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).

Cool. Hope you'll fix it then :)

>
> Cheers
> Hernan.
>
> On Tue, Jun 11, 2019 at 3:05 AM Phil B via Cuis-dev 
> <cuis-dev at lists.cuis.st <mailto: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
>     <mailto: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 <mailto:Cuis-dev at lists.cuis.st>
>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>
>
>
> -- 
> *Hernán Wilkinson
> Agile 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

Cheers,

-- 
Juan Vuletich
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

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


More information about the Cuis-dev mailing list