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

[Phil B]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190611/9db2efc2/attachment.htm>