Comments on: Assertive Code

By: Ennuyer.net » Blog Archive » Rails Reading - November 24, 2009

Ennuyer.net » Blog Archive » Rails Reading - November 24, 2009 — Tue, 24 Nov 2009 22:44:44 +0000

[...] Assertive Code | Virtuous Code [...]

By: Practical Programming: Holding the Flow of Code in Mind

Practical Programming: Holding the Flow of Code in Mind — Sun, 22 Nov 2009 17:39:13 +0000

[...] Assertive Code (avdi.org) [...]

By: avdi

avdi — Wed, 18 Nov 2009 16:57:30 +0000

I'd also say that your example more brittle and in a more subtle way than mine. Supposing I'm the maintainer of the superclass, and you maintain the subclass. One day, having no knowledge of your code, I decided that in the next release my superclass is going to use the :caffeinated option internally. The next time you update you have to figure out why your option isn't taking effect any more and I get a grumpy complaint from you that I've appropriated "your" option.

Much better to be courteous to superclasses and clean out subclass-specific stuff from the arguments before invoking them.

By: avdi

avdi — Wed, 18 Nov 2009 16:42:46 +0000

I subclass and add new options all the time. It's just a matter of pulling out the added options before calling super. If for some reason you must have the superclass initialized before processing the added options, pull the option out into a local before calling super and then process it after.

Your subclasses shouldn't be permitting values to get to the superclass constructor which they don't expect it to be able to handle.

By: Ryan Davis

Ryan Davis — Wed, 18 Nov 2009 16:09:26 +0000

Trust, but verify? No. Can't people learn that Reagan was a moron? Just trust. That is the way of dynamic programming.

Fail fast often takes care of itself, but if not, help it along. Just don't help it along like your examples show.

Your #initialize example is static and brittle. If you subclass, you can't extend like so:

def initialize
super

# handle new option that depends on old options being processed.
@uncaffeinated = options.delete(:caffeinated) { not_feeling_creative }
end

By: avdi

avdi — Wed, 18 Nov 2009 16:02:43 +0000

Update: phiggy is correct. Looks like I was confusing instance_of?() with is_a?(). I've updated the article accordingly.

By: avdi

avdi — Wed, 18 Nov 2009 15:59:13 +0000

That's a very good point – it gives you more confidence as a developer when you know that a value e.g. can't be nil beyond a certain point.

By: avdi

avdi — Wed, 18 Nov 2009 15:58:05 +0000

Thanks, fixed.

By: avdi

avdi — Wed, 18 Nov 2009 15:57:46 +0000

Good catch! Looks like I've been confusing instance_of?() and is_a?()

By: avdi

avdi — Wed, 18 Nov 2009 15:53:41 +0000

kind_of?() asks if the receiver inherits the given class or module somewhere in its ancestor chain. is_a?() only returns true if the receiver is of exactly that type – not a subcless. I almost never use is_a() for this reason – my code shouldn't break just because someone subclassed String.