I'm feeling suspicious of nil.
In a recent newsletter I pondered true and false, and suggested that thinking of them as normal, everyday objects could expand your ideas about OOP. Today I'll continue with this theme by considering nil.
What _is_ nil?
A straightforward, very concrete definition might be that it's an instance of NilClass and a specialized kind of Ruby singleton that responds to 70+ public/protected methods.
Let's have a look...
Scholarships for the Oct 29-31 Practical Object-Oriented Design Course (POODNC) in Durham, NC have been awarded! Winners are listed below, but before I introduce them I'd like to give an overview of the applicant pool and selection process.
I'll be awarding scholarships for future public classes and hope that transparency about how this works will motivate you to talk some deserving person into applying, or to apply for your own deserving self.
The scholarship includes a seat in the POODNC course
(courtesy of me), and airfare and lodging (courtesy of Hashrocket, to whom I am very grateful). As you can see, it's a full ride. The intent was to remove every financial barrier that would prevent the recipient from attending.
I've been teaching a fair amount, which means I've been revisiting my 'class problems' regularly. When I chose the problems, I thought that I understood them completely (hubris, I know) but now that I've worked them repeatedly I'm seeing new and surprising things.
These new things have to do with the _shape_ of code. Code can be written, or shaped, in many ways, and I've always believed that for any given problem many different code shapes gave equally 'good' solutions. (I think of programming as an art and am willing to give artists a fair amount of expressive leeway.)
But I'm having a change of heart.
