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

[Phil B]

Very well said.  This is actually a big part of the reason I prefer the
#pvt*/#private* conventions: since it's baked into the name, the meaning
remains clear when all you have to look at is a selector.   As you say,
categories/pragmas don't give you that.

On Tue, Jun 11, 2019 at 4:18 PM Nicolas Cellier via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> One thing to remember: I see too many reasoning about methods, some
> methods can have meta information in pragmas or classification (category).
> But in Smalltalk we must not be reasoning about method. We must think in
> term of messages. Smalltalk is messaging all the way down. So if the
> message does not carry privacy information, how is it going to work? One
> implementor could be private, the other not, we cannot tell at compile time
> if not expressed in the message. With methods, we can only instrument at
> execution time. We can even check the sender... But at compile time, every
> bit of information must be in the message.
>
> Le mar. 11 juin 2019 à 22:00, Gerald Klix via Cuis-dev <
> cuis-dev at lists.cuis.st> a écrit :
>
>> Why can't we just add some pragma, let's name it "scope" or
>> "protection"? We can add those without renaming methods,
>> we could easily add other protection levels
>> and they won't clutter otherwise nice methods-names with
>> 'irrelevant' prefixes. With some additional effort,
>> we can hide or mark those methods in the browsers, too.
>>
>> Again just my 0.01€.
>>
>>
>> Best Regards,
>>
>> Gerald
>>
>>
>>
>> On 11.06.2019 20:27, Phil B via Cuis-dev wrote:
>> > (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
>>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190611/cbdfbb90/attachment.htm>