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

Philip Bernhart philip.bernhart at posteo.de
Tue Jun 11 12:31:35 PDT 2019


Hi,

just a naive question: Why would make it sense to treat the private
category special? Or treat methods prefixed with pvt* special?

The argument as I have seen so far is, that so Smalltalk behaves
more like other languages.

If that is the supposed reasoning for this addition or change,
then another question arises for me: If we implement this behaviour
then we need to implement other behaviours too (e.g protected).

Which goes against what our benevolent dictator (Juan) is intending
to do with Cuis: Making the core small.

Wouldn't that be better in a package like 'ClassicOOP'?

In my small experience with Smalltalk implementations make such
changes the system less understandable.


My 2 cents,
Philip


Phil B via Cuis-dev <cuis-dev at lists.cuis.st> writes:

> (sorry for all the posts on this subject)
>
> Just to clarify, I'm in favor of using pvt*/private* where it makes sense.
> I'm not in favor of extending pvt* visibility class-side as it would create
> a new inconsistency between variables and methods similar to the one that
> this whole thread started to try to resolve. (i.e. we'd be solving one
> problem and creating another)
>
> This kind of brings it back to the method comment that Juan wants to get
> rid of: while I think that a more explicit method name for those setters
> would be a good thing rather than relying on the comment alone, I also
> think that keeping a method comment explaining *why* we made those methods
> in particular private (i.e. we really don't want the methods to even exist
> as we want immutable instances) is a good thing.  Just look at how we're
> trying to reverse-engineer why pvt* works the way it does... some better
> documentation left behind by someone 20 years ago would have avoided this.
>
>
> On Tue, Jun 11, 2019 at 1:56 PM Phil B <pbpublist at gmail.com> wrote:
>
>> Juan/Hernan,
>>
>> On Tue, Jun 11, 2019 at 1:37 PM Juan Vuletich <juan at jvuletich.org> wrote:
>>
>>> 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).
>>>
>>
>> I've done both Java and C++ development and it never even occurred to me
>> that they might have been the inspiration for pvt*.   That makes a lot of
>> sense though as I think this convention was added late-90's.
>>
>> The reason it probably never occurred to me at least is because I've
>> always been bothered by the definition of 'private' as it applies to
>> ivars/cvars vs pvt* for methods.  So I guess the question is, which is more
>> confusing to users: that pvt* wouldn't work the way they're used to in
>> other languages or that pvt* is internally inconsistent with the ivar/cvar
>> concept of privacy.
>>
> -- 
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev


More information about the Cuis-dev mailing list