Hi. Look at UndefinedObject instance side methods. You will see class hierarchy protocol. For example nil understands #subclasses message: nil subclasses "==> {ProtoObject}" 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.
2016-07-26 15:08 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
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"
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.
Hi Nicolai,
On Jul 26, 2016, at 6:33 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-07-26 15:08 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
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.
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 <eliot.miranda@gmail.com> wrote:
Hi Nicolai,
On Jul 26, 2016, at 6:33 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-07-26 15:08 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
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.
2016-07-26 16:09 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
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.
I think so too :)
2016-07-26 15:33 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
Look at UndefinedObject instance side methods. You will see class
hierarchy protocol. For example nil understands #subclasses message:
nil subclasses "==> {ProtoObject}"
It is true only for ProtoObject. If you will create another class with nil superclass, you will not see it here
On Jul 26, 2016, at 8:56 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-07-26 15:33 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
Look at UndefinedObject instance side methods. You will see class hierarchy protocol. For example nil understands #subclasses message:
nil subclasses "==> {ProtoObject}"
It is true only for ProtoObject. If you will create another class with nil superclass, you will not see it here
Bullseye.
Done 18820 <https://pharo.fogbugz.com/f/cases/18820/Remove-class-hierarchy-protocol-from...> 2016-07-26 18:22 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Jul 26, 2016, at 8:56 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-07-26 15:33 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
Look at UndefinedObject instance side methods. You will see class
hierarchy protocol. For example nil understands #subclasses message:
nil subclasses "==> {ProtoObject}"
It is true only for ProtoObject. If you will create another class with nil superclass, you will not see it here
Bullseye.
participants (4)
-
Denis Kudriashov -
Eliot Miranda -
Nicolai Hess -
Peter Uhnák