[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