<br><br><div class="gmail_quote">On Fri, Aug 13, 2010 at 12:58 PM, Casey Ransberger <span dir="ltr"><<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF"><div>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.)</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>best</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#FFFFFF"><div><div><div></div><div class="h5">
<br><br>On Aug 13, 2010, at 12:14 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br><br></div></div></div><div><div></div><div class="h5"><div></div><blockquote type="cite">
<div><br><br><div class="gmail_quote">On Fri, Aug 13, 2010 at 1:01 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank"></a><a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 12.08.2010, at 21:41, Jecel Assumpcao Jr. wrote:<br>
<br>
> Randal L. Schwartz wrote on Date: Thu, 12 Aug 2010 12:46:52 -0700<br>
</div><div>>> Jecel> 1) the class was defined as a subclass of something that was not in the<br>
>> Jecel> image, so the system was silently making it a subclass of ProtoObject<br>
>> Jecel> instead (though the browser said it was a subclass of Object - very<br>
>> Jecel> odd). Didn't we have a warning for this situation?<br>
>><br>
>> I can't imagine any case where<br>
>><br>
>> Foo subclass: #Bar [...]<br>
>><br>
>> should *succeed* if Foo doesn't exist. Can you explain why this isn't fatal?<br>
><br>
</div><div>> Indeed, I would expect the compiler to refuse to accept this code since<br>
> it can't know what to do with "Foo". But I am guessing that somehow that<br>
> is being silently converted into a translation to nil instead.<br>
<br>
</div>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.<br></blockquote><div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>best</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
- Bert -<br>
</font><div><div></div><div><br>
> UndefinedObject does have a<br>
> #subclass:instanceVariableNames:classVariableNames:poolDictionaries:cate<br>
> gory: instance method to deal with legacy code that has the hack "nil<br>
> subclass: #Bar ..." to implement proxies and stuff - it just now<br>
> redirects it to the proper ProtoObject class.<br>
><br>
> -- Jecel<br>
><br>
><br>
<br>
<br>
<br>
</div></div></blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span></span><br></div></blockquote></div></div></div><br><br>
<br></blockquote></div><br>