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

[Hernan Wilkinson]

Hi Philip and the rest :-)
I just wanted to say that I do not use pvt* methods, I prefer to use
cultural standards/rules for those things, that is why for me categories
with "private" in its name is just enough, and as you say Philip, I would
not do these things just because other languages have them, and I believe
Juan thinks the same :-)
I think that what it is right now, with the current behavior, it is ok, no
other change is needed.

Cheers!
Hernan.

PS: I think we should all forget about the object/message crap and return
to functions and data structures!!! Yeah!!! 😜😜😜


On Tue, Jun 11, 2019 at 4:31 PM Philip Bernhart via Cuis-dev <
cuis-dev at lists.cuis.st> 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
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190611/7df10690/attachment.htm>