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

[Phil B]

The attached should allow for both use cases...

On Wed, Jun 12, 2019 at 10:07 PM Phil B <pbpublist at gmail.com> wrote:

> Heh... well ya broke my code!  I have a class side send to self
> pvtInitialize* which now results in 'Private instance initialization
> messages may only be sent to ''self new'' or "self basicNew" (by class
> instance creation methods)'  (i.e. self pvt* is valid instance *or* class
> side)
>
> On Wed, Jun 12, 2019 at 9:14 PM Juan Vuletich <juan at jvuletich.org> wrote:
>
>> The last bunch of updates done today enable sending `super pvtMessage`. I
>> also added a new, related way for initializers. Now, an instance creation
>> method can do 'self new pvtInitializeStuff' or 'self basicNew
>> pvtInitializeStuff', but no one else can call #pvtInitializeStuff. As a
>> first example, I finally was able to make Point almost immutable. Please
>> check it.
>>
>> Cheers,
>>
>> --
>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
>> @JuanVuletich
>>
>>
>> On 6/11/2019 2:43 PM, Phil B wrote:
>>
>> Ah, then count me as a firm 'yes' vote!  I've been in favor of that
>> forever as I agree making things explicitly pvt* removes any possible
>> misinterpretation.  The only problem is that many (most?) the senders of
>> those set* methods tend to come from class-side so pvt* visibility would
>> have to extend there as well for this to work. (What I tend to do currently
>> for those cases in my code currently is use a private* prefix.)
>>
>> On Tue, Jun 11, 2019 at 1:28 PM Juan Vuletich <juan at jvuletich.org> wrote:
>>
>>> On 6/10/2019 8:15 PM, Phil B wrote:
>>>
>>> Why do you think the #privateSetX:setY: looks silly?  I think it's a
>>>> decent placeholder that I read as saying 'we really want this to be
>>>> immutable and are indicating this as private to reflect that fact until we
>>>> can actually make it immutable via the VM'
>>>>
>>>
>>> Because the comment begs you not to call it. If we just add the pvt
>>> prefix, then it is way more robust. You need to add a new method to set the
>>> ivars, and clearly you are on your own then.
>>>
>>>
>>> Private categories are good for getting methods out of the way in the
>>> main browser but I'm not wild about them beyond that.  The main issue I
>>> have with private categories is that they are so easy to overlook in the
>>> browsers.  For example, if you're in the message finder and you do a search
>>> on 'set', the fact that it shows up as private* makes it very clear that
>>> it's not a method you should be using generally.  If the private prefix
>>> were removed, you'd have to be sure to select an implementor in the right
>>> pane (and hope that they are consistently categorized) and then be sure to
>>> look for the category buried in the method annotation below (which might be
>>> 'private' or 'private - someSubCategory' etc)... ugh!  Or if you see a raw
>>> selector (i.e. #setX:setY:) in code now you have to do the above as opposed
>>> to just looking at the selector name.
>>>
>>> That said, if it really bugs you or others, I will live without the
>>> prefix.  But I do find it helpful.
>>>
>>> Thanks,
>>> Phil
>>>
>>>
>>> I'm suggesting the opposite! To start adding the pvt prefix to methods
>>> we intend to be private (i.e. those already in a 'private*' category).
>>>
>>> Cheers,
>>>
>>> --
>>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
>>> @JuanVuletich
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190612/545290bf/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3805-FixPvtTest-PhilBellalouna-2019Jun12-22h29m-pb.1.cs.st
Type: application/octet-stream
Size: 1054 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190612/545290bf/attachment-0001.obj>