[Cuis-dev] Why can't you send to super on private (pvt*) methods?
Phil B
pbpublist at gmail.com
Tue Jun 11 13:39:24 PDT 2019
It all depends on what problem you're trying to solve. To me, the value of
private methods is strictly to signal 'hey, this method is related to an
internal implementation detail... it should not be widely used and is
subject to change/removal at any time' in the same way that ivars/cvars
often exist to maintain private state. I don't find it terribly helpful to
have gradients of privacy (aside from using the private prefix for cases
where #pvt* simply won't work due to how a given method must be called.)
So I'm really not advocating recreating the enforcer/nanny-state that
exists in many static languages, just a simple mechanism to say 'don't use
me from the outside'. I latched on to the #pvt* convention years ago
because I saw it already had minimal tooling support. I don't even care
that it's not enforced by the VM since one can easily bypass all levels of
encapsulation (i.e. #instVarAt: etc) as desired/needed.
On Tue, Jun 11, 2019 at 3:40 PM Gerald Klix via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190611/5c7bd334/attachment.htm>
More information about the Cuis-dev
mailing list