Well the class definition of ProtoObject is
ProtoObject subclass: #ProtoObject
slots: { }
classVariables: { }
category: 'Kernel-Objects'.
ProtoObject superclass: nil
So I guess by setting the superclass to nil, it was added as a child, since
UndefinedObject is still just an object :)
On Tue, Jul 26, 2016 at 4:09 PM, Eliot Miranda <[email protected]>
wrote:
> Hi Nicolai,
>
> On Jul 26, 2016, at 6:33 AM, Nicolai Hess <[email protected]> wrote:
>
>
>
> 2016-07-26 15:08 GMT+02:00 Denis Kudriashov <[email protected]>:
>
>> Hi.
>>
>> Look at UndefinedObject instance side methods. You will see class
>> hierarchy protocol. For example nil understands #subclasses message:
>>
>> nil subclasses "==> {ProtoObject}"
>>
>>
> ProtoObjects superclass is nil, so maybe it just should behave the same
> way for all other objects.
>
> ByteString superclass subclasses includes: ByteString. "true"
>
> ProtoObject superclass subclasses includes: ProtoObject. "true"
>
>
> Sorry to sound harsh but that's no sense. ProtoObject doesn't have a
> superclass. This is indicated by ProtoObject superclass answering nil,
> where nil is the object that represents being undefined.
>
> It is (as Denis points out) a bug, showing some confusion, to try and
> program around this one case by adding class protocol to the undefined
> object. A horrible hack.
>
> Denis, you're right; that behaviour should be deleted.
>
>
>
>>
>> It implemented like this:
>>
>> UndefinedObject >>subclassesDo: aBlock
>> "Evaluate aBlock with all subclasses of nil. Others are not direct
>> subclasses of Class."
>>
>> ^ Class subclassesDo: [:cl |
>> cl isMeta ifTrue: [aBlock value: cl soleInstance]].
>>
>>
>>
>> So my question is: why it needs to be like that? And does it really
>> needed?
>>
>> I removed all this methods and not saw any problem.
>>
>
>
