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

Phil B pbpublist at gmail.com
Wed Jun 12 19:07:39 PDT 2019


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/d112dd76/attachment.htm>


More information about the Cuis-dev mailing list