On Fri, Aug 13, 2010 at 12:58 PM, Casey Ransberger <casey.obrien.r at gmail.com
> wrote:

> I think I've hit this before. Repro is, filein in the wrong order, wind up
> with things erroneously inheriting from ProtoObject? It's totally evil, and
> I thought it was expected behavior (haven't seen it work any other way that
> I can recall.)
>

One work-around is to use the ChangeList to select al class definitions and
simply evaluate them N times.  I think N times is guaranteed to resolve N
class definitions.  e.g. consider A <- B <- C <- D, A a superclass of B, D
inheriting from C, B & A etc, occurring in the file as D, C, B, A.  The
first evaluation leaves A correct and B, C & D inheriting from ProtoObject.
 The second evaluation picks up C as inheriting from D, and so on.

So e.g. with my tweaks to the ChangeList in trunk you can file-in, open the
ChangeList, remove unchanged definitions, reevaluate, remove unchanged
definitions, rinse and repeat until  no defs are left.

best
Eliot


>
> On Aug 13, 2010, at 12:14 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>
>
> On Fri, Aug 13, 2010 at 1:01 AM, Bert Freudenberg < <bert at freudenbergs.de>
> bert at freudenbergs.de> wrote:
>
>>
>> On 12.08.2010, at 21:41, Jecel Assumpcao Jr. wrote:
>>
>> > Randal L. Schwartz wrote on Date: Thu, 12 Aug 2010 12:46:52 -0700
>> >> Jecel> 1) the class was defined as a subclass of something that was not
>> in the
>> >> Jecel> image, so the system was silently making it a subclass of
>> ProtoObject
>> >> Jecel> instead (though the browser said it was a subclass of Object -
>> very
>> >> Jecel> odd). Didn't we have a warning for this situation?
>> >>
>> >> I can't imagine any case where
>> >>
>> >>  Foo subclass: #Bar [...]
>> >>
>> >> should *succeed* if Foo doesn't exist.  Can you explain why this isn't
>> fatal?
>> >
>> > Indeed, I would expect the compiler to refuse to accept this code since
>> > it can't know what to do with "Foo". But I am guessing that somehow that
>> > is being silently converted into a translation to nil instead.
>>
>> Not "somehow". There is no special compiler magic for this. It's an
>> unknown global, so simply becomes an entry in Undeclared with a value of
>> nil.
>>
>
> I'm assuming that the problem is that when the global is defined there is
> no magic that arranges to recompile the subclass and it remains a subclass
> of nil^H^H^HProtoObject, right?
>
> I was going to reply earlier in the thread that one jsutification
> is circular package dependencies.  e.g. package Foo defines classes A & C,
> package Bar defines class B.  Class hierarchy is A subclass: #B, B subclass:
> #C.  Can't load Foo or Bar without a hack.  But unless the system records
> ProtoObject subclasses that have been parented there-form for the purposes
> of deferring resolution of Undeclared references and reevaluates their
> correct definitions when previously undeclared classes are declared this
> isn't much use.  In my Parcel loader the system does do this, but it hides
> classes subclassed from "absent" classes until those classes become present.
>  The Squeak approach is simpler (and has much less fall-out on tools etc),
> but it would be nice if orphaned classes could be redefined as parent
> classes arrive.
>
> best
> Eliot
>
>
>>
>> - Bert -
>>
>> > UndefinedObject does have a
>> > #subclass:instanceVariableNames:classVariableNames:poolDictionaries:cate
>> > gory: instance method to deal with legacy code that has the hack "nil
>> > subclass: #Bar ..." to implement proxies and stuff - it just now
>> > redirects it to the proper ProtoObject class.
>> >
>> > -- Jecel
>> >
>> >
>>
>>
>>
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100813/f7e337da/attachment.htm