<div dir="ltr">Hi Philip and the rest :-) <div>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 :-)</div><div>I think that what it is right now, with the current behavior, it is ok, no other change is needed. </div><div><br></div><div>Cheers!</div><div>Hernan.</div><div><br></div><div>PS: I think we should all forget about the object/message crap and return to functions and data structures!!! Yeah!!! 😜😜😜</div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2019 at 4:31 PM Philip Bernhart via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
just a naive question: Why would make it sense to treat the private<br>
category special? Or treat methods prefixed with pvt* special?<br>
<br>
The argument as I have seen so far is, that so Smalltalk behaves<br>
more like other languages.<br>
<br>
If that is the supposed reasoning for this addition or change,<br>
then another question arises for me: If we implement this behaviour<br>
then we need to implement other behaviours too (e.g protected).<br>
<br>
Which goes against what our benevolent dictator (Juan) is intending<br>
to do with Cuis: Making the core small.<br>
<br>
Wouldn't that be better in a package like 'ClassicOOP'?<br>
<br>
In my small experience with Smalltalk implementations make such<br>
changes the system less understandable.<br>
<br>
<br>
My 2 cents,<br>
Philip<br>
<br>
<br>
Phil B via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> writes:<br>
<br>
> (sorry for all the posts on this subject)<br>
><br>
> Just to clarify, I'm in favor of using pvt*/private* where it makes sense.<br>
> I'm not in favor of extending pvt* visibility class-side as it would create<br>
> a new inconsistency between variables and methods similar to the one that<br>
> this whole thread started to try to resolve. (i.e. we'd be solving one<br>
> problem and creating another)<br>
><br>
> This kind of brings it back to the method comment that Juan wants to get<br>
> rid of: while I think that a more explicit method name for those setters<br>
> would be a good thing rather than relying on the comment alone, I also<br>
> think that keeping a method comment explaining *why* we made those methods<br>
> in particular private (i.e. we really don't want the methods to even exist<br>
> as we want immutable instances) is a good thing.  Just look at how we're<br>
> trying to reverse-engineer why pvt* works the way it does... some better<br>
> documentation left behind by someone 20 years ago would have avoided this.<br>
><br>
><br>
> On Tue, Jun 11, 2019 at 1:56 PM Phil B <<a href="mailto:pbpublist@gmail.com" target="_blank">pbpublist@gmail.com</a>> wrote:<br>
><br>
>> Juan/Hernan,<br>
>><br>
>> On Tue, Jun 11, 2019 at 1:37 PM Juan Vuletich <<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>> wrote:<br>
>><br>
>>> On 6/11/2019 8:56 AM, Hernan Wilkinson wrote:<br>
>>><br>
>>> A few comments:<br>
>>> 1) super pvt* it is not allowed because "private" parts of a class are<br>
>>> only visible to its instances, at least that it is how c++/java and the<br>
>>> like treat private stuff (methods, vars, etc). So in Java you can not do<br>
>>> super.prvt*().<br>
>>> The behavior you are proposing Phil would be like "protected" in those<br>
>>> languages. In fact, we could say that inst. vars. in Smalltalk are<br>
>>> protected in the c++/java parlance.<br>
>>> So, my guess is that the current restriction on super pvt* came from that<br>
>>> understanding "private".<br>
>>> Having said that, I see no problem to change that restriction and treat<br>
>>> pvt* messages as they were protected although it will be confusing to<br>
>>> explain when compared to other languages. I think it would be better in<br>
>>> that case to have prt* (protected) instead of pvt* but that would generate<br>
>>> a migration problem...<br>
>>><br>
>>><br>
>>> Mhh. Difficult decision. We could keep the 'pvt' prefix, but in methods<br>
>>> that handle them, we could add comments stating that it is like what<br>
>>> c++/java calls "protected". The error could be "Protected messages may only<br>
>>> be sent to self" (protected instead of private).<br>
>>><br>
>><br>
>> I've done both Java and C++ development and it never even occurred to me<br>
>> that they might have been the inspiration for pvt*.   That makes a lot of<br>
>> sense though as I think this convention was added late-90's.<br>
>><br>
>> The reason it probably never occurred to me at least is because I've<br>
>> always been bothered by the definition of 'private' as it applies to<br>
>> ivars/cvars vs pvt* for methods.  So I guess the question is, which is more<br>
>> confusing to users: that pvt* wouldn't work the way they're used to in<br>
>> other languages or that pvt* is internally inconsistent with the ivar/cvar<br>
>> concept of privacy.<br>
>><br>
> -- <br>
> Cuis-dev mailing list<br>
> <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal"><span style="font-weight:bold">Hernán Wilkinson</span><br>Agile Software Development, Teaching & Coaching</span></font></span></span></span></strong></span></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">Phone: +54-011</span></font></span></span></span></strong></span><font face="tahoma, sans-serif" size="2">-4893-2057</font></div><div><strong style="font-family:tahoma,sans-serif;font-size:xx-small"><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Twitter: @HernanWilkinson</span></font></span></span></strong></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">site: <a href="http://www.10pines.com/" style="color:rgb(17,65,112)" target="_blank">http://www.10Pines.com</a></span></font></span></span></span></strong></span></div><div><font face="tahoma, sans-serif"><span style="border-collapse:collapse">Address: Alem 896</span></font>, Floor 6, Buenos Aires, Argentina</div></div></div></div></div></div></div></div></div></div></div></div>