<html><body 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.)<br><br>On Aug 13, 2010, at 12:14 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br><br></div><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"><a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a></a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><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 class="im">>> 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 class="im">> 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 class="h5"><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></body></html>