Re: [Swarm-Support] Followup: found work-aroundfor missing~/swarmarchiver.scm too

[Bill Northcott]

On 21/08/2006, at 12:11 PM, Marcus G. Daniels wrote:
> > The existing way, before Marcus' recent change, of having some  
> > compile time option for the library behaviour seems to be  
> > appropriate, but even that should be documented.
> It's just a matter of putting a:
>
> id nil_method (id obj, SEL sel) { return nil; }
>
> ..into a Swarm app.. if for some reason you wanted to remain  
> ignorant of messages to nil.

Why not do that the other way around and redefine nil_method for  
debugging purposes?  That has the merit of being consistent with the  
documentation.  Even better might be to do something like Apple's  
NSZombie object set up by a runtime environment variable.   We could  
have nil_method depend on a runtime envar.
> I've helped to debug many Swarm models, and usually when people  
> send a message to nil, it's because they forgot to fully implement  
> buildObjects.  Thus when messages to nil are tolerated, some part  
> of their model is just off, and they may not realize it until  
> they've run a bunch of experiments only to find their time has been  
> wasted.

I can see the valid problem that  you are trying to address, but I  
still don't think that justifies introducing behaviour that is  
plainly wrong according to widely disseminated Objective-C  
documentation.  As you point out, you can override nil_method for  
debugging purposes.
> Having an abort for this behavior may defy expectations of some  
> Objective C programmers, but at least it will be clear it is  
> defiance.   These folks, being savvy Objective C programmers, will  
> know the nil_method override trick.

They really won't know that because most Objective-C programmers are  
learning their craft on MacOS X where nil_method does not exist.  The  
handling of messages to nil happens within the assembler code portion  
of the runtime.

OTOH I have been writing quite a bit of Objective-C recently, and it  
has become very clear to me that there is a very strong convention  
that methods which return objects, return nil to indicate failure.   
As a result Objective-C programmers obsessively test for nil if there  
is any possibility that an object may not be available.  That seems  
to me a good habit that Swarm Objective-C programmers should also  
cultivate.

> Swarm also does Java, and so here the underlying Objective C code  
> is just a means to an end.   Java users will expect null pointer  
> exceptions.

Is this not the whole point?  There exists a Java interface for  
people who want/need the software to keep them on a tight leash and  
sweep up behind.  The downside is reduced functionality.  That is a  
basic trade-off in any computer language.

Cheers
Bill