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

[Phil B]

I only asked about the private category because I thought that's where Juan
was going with one of his previous replies.  Because of how categories are
generally used in practice (as an ad hoc, whatever you want means of
tagging/grouping things... virtually no consistency that I've noticed from
developer to developer), I'm not proposing treating them in any special
way.  I was only asking if Juan was (which as he indicated, he wasn't)

As far as #pvt* goes, it's already treated specially. (try compiling a
method that sends to a pvt* method in another class or to super)  So this
thread originally started trying to get an answer to the question about why
it's implementation seemed (to me, at least) to be inconsistent.  From
there we've kind of gotten off on a tangent about something that has been
bugging Juan which is somewhat related re: immutable/one-shot setters and I
think he saw this issue as an opportunity to address that.

I don't personally see the value in having Smalltalk behave more like other
languages (in fact, as Hernan points out, what I was asking is why doesn't
our version of private behave in a way that isn't consistent with other
languages definition of private)  However, I do see value in Smalltalk of
allowing for limiting the visibility of methods (even if it's only done at
a tool level and not enforced by the VM) as a way to signal to myself and
other developers 'you should not be using this.'  So all I was really
asking for was that the implementation of #pvt* methods be both more
regular in it's enforcement and consistent with the concept of privacy as
it relates to ivars/cvars.  I get that most Smalltalkers bristle at the
very concept of private methods... in that case, feel free not to use them.

Somewhat tongue-in-cheek nitpick: how dare you call what other languages
implement classic OOP... Smalltalk *is* classic OOP ;-)

On Tue, Jun 11, 2019 at 3:31 PM Philip Bernhart <philip.bernhart at posteo.de>
wrote:

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