[squeak-dev] Recent MC doesn't support loading classes with nil superclass?

Tested both in Pharo-Core & Squeak trunk image.

The class i defined is:

ProtoObject subclass: #BBBNameOfSubclass
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'NILSuperClass'.
BBBNameOfSubclass superclass: nil

In attachment you can fin the fileout of it.
And MC package, saved with it.

If you try load the package, MC will display warning that you should
resolve dependencies 'nil' before loading the class ;)

Background:
I wanted to migrate to newer image and saved my package, im working
on, which i didn't touched for 3-4 months,
and found that it can't be loaded :(

--
Best regards,
Igor Stasenko AKA sig.

I have no answer to the MC question but out of curiosity, why do you
need a nil subclass? Wouldn't a ProtoObject subclass do?

Cheers,
   - Andreas

Igor Stasenko wrote:

Not if you want portability... :)

I was just struggling with this issue yesterday while porting Magritte
to VAST, actually... I'm thinking of adding ProtoObject-like class to
the compatibility layer that would need to have appropriate primitive
methods added by each platform. And I think it will need to subclass
nil...

Julian

On Fri, Sep 25, 2009 at 9:08 AM, Andreas Raab <[hidden email]> wrote:

2009/9/25 Andreas Raab <[hidden email]>:
> I have no answer to the MC question but out of curiosity, why do you need a
> nil subclass? Wouldn't a ProtoObject subclass do?
>

Well, because i need to prototype own class hierarchy to bootstrap the
object memory,
not related with current one to make sure there is no dependencies, so
i could have
a sources in a package, which could sit in squeak image & be
developed/tested/simulated inside it until i will have own
object memory working & running.
Of course, i could place source into file(s), but then you can answer
yourself, why i don't wanna do it :)

> Cheers,
>  - Andreas
>

--
Best regards,
Igor Stasenko AKA sig.

2009/9/25 Julian Fitzell <[hidden email]>:
> Not if you want portability... :)
>
> I was just struggling with this issue yesterday while porting Magritte
> to VAST, actually... I'm thinking of adding ProtoObject-like class to
> the compatibility layer that would need to have appropriate primitive
> methods added by each platform. And I think it will need to subclass
> nil...
>

Another thing about it, that MC package browser (if you click browse
the package without loading it) prints the class definition
incorrectly:

nil subclass: #BBBNameOfSubclass
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'NILSuperClass'


the problem is, that you can't evaluate it, because you'll get DNU.

While system browser prints class definition using 2 statements for a
class which having nil as superclass:

ProtoObject subclass: #BBBNameOfSubclass
       instanceVariableNames: ''
       classVariableNames: ''
       poolDictionaries: ''
       category: 'NILSuperClass'.
BBBNameOfSubclass superclass: nil

Another little concern of mine, is that #superclass: implementation is
very dangerous one:

----------
superclass: aClass
        "Change the receiver's superclass to be aClass."
        "Note: Do not use 'aClass isKindOf: Behavior' here
                in case we recompile from Behavior itself."
        (aClass == nil or: [aClass isBehavior])
                ifTrue: [superclass := aClass.
                                Object flushCache]
                ifFalse: [self error: 'superclass must be a class-describing object']
----------

Suppose i got class A with 2 ivars, then i subclass it with class B
and add some other ivars, and then send

B superclass: nil.

At this point, it really should recompile everything. But as you can
see, there is no such check, and i fear to predict what could happen
if you start using instances of such class.

> Julian
>



--
Best regards,
Igor Stasenko AKA sig.