[Cuis-dev] nil subclasses (Re: clever or silly idea?)

[Andres Valloud]

Yeah, pretty much --- the debugging tools, and whatever messages are 
required by the virtual machine (a minimum of doesNotUnderstand:).  This 
was also meant to be the default subclass of nil to subclass proxies 
from, but alas over time ProtoObject kept growing and now whether that's 
a reasonable root for an otherwise subclass of nil is at least debatable.

Also there's the related informal notion that "ProtoObject's protocol 
has to be small", which tends to hide the underlying motivation: 
"Object's protocol is huge".  Well, just creating a new class and then 
putting in even more methods is not really helping with the perceived 
bloat, if that was really the problem in the first place :).

Bloat is just bad, it invites bit rot and should be tracked down and 
eliminated aggressively (to optimize for the fact that 90% of 
programming is reading, which also shows that autocomplete and 
autocowreck are optimizing the wrong problem).

IIRC the ProtoObject thing came up back in the day when Object 
implemented more than 1000 messages.  In current Cuis there are ~230, 
which is much less, and perhaps with a small effort could be even smaller.

In that spirit, what is ProtoObject>>pointsTo: used for?  Is there 
anybody these days that implements isInMemory to return false?  At first 
glance there's quite a bit of low hanging fruit to be had.

On 6/13/24 12:11 PM, Martin McClure via Cuis-dev wrote:
> I think that one motivation for ProtoObject was to make minimal objects 
> that did not break low-level debugging tools -- ProtoObject would 
> understand enough messages that inspectors would not break.
> 
> This is no longer necessary. The mirror primitives allow one to write an 
> inspector that sends no messages to the inspected object until it's sure 
> they will be understood. The Cuis inspector looks like it's using the 
> mirror primitives, which is good.
> 
> IMHO, ProtoObject should be removed.
> 
> If debugging tools are carefully written, it's not needed. If debugging 
> tools are /not/ carefully written, ProtoObject is not sufficient. 
> Example: Pharo. There, ProtoObject has far too many methods (over 50) 
> and yet there are not enough methods to make the tools work. In writing 
> a forwarding proxy object a couple of years ago, our team found that 
> subclasses of ProtoObject would severely break the inspectors, and we 
> ended up having to subclass Object.
> 
> Regards,
> -Martin
> 
> On 6/12/24 10:07, Hernán Wilkinson via Cuis-dev wrote:
>> I do not remember that exactly, it was done in Squeak 3.x …
>> For sure there are mails about it in the squeak mailing list archive
>>
>> *Hernán Wilkinson
>> Agile 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
>>
>>
>> On Wed, 12 Jun 2024 at 12:46 Andres Valloud via Cuis-dev 
>> <cuis-dev at lists.cuis.st> wrote:
>>
>>     Why is that a goal?  Who decided?  On what basis?
>>
>>     On 6/12/24 07:06, Hernán Wilkinson via Cuis-dev wrote:
>>     > one of the goals of ProtoObject is not to sublass nil
>>     -- 
>>     Cuis-dev mailing list
>>     Cuis-dev at lists.cuis.st
>>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>>
> 
>