I was just reading on DCI today. Have been thinking about how it would look for what I'm doing.

I'm not sure that Roles/Traits get away from the Noun problem, in that all the traits (in what I read earlier) seem to be named with nouns (like Waitor). So roles seem to be used to figure out which methods to inject into objects (in a context). Verbs (functions/methods) still only exist to be clumped onto objects. Whereas I want to think of verbs as being the, um, things that the system revolves around.

I like the direction this is heading and the reasoning behind it.

The nod to Steve Yegge's, 'Kingdom of the Nouns' narrative made me smile but also, importantly, ties up a couple of loose ends from that post; like practical advice for mixing Object and Functional languages for great good.

I've been fiddling with similar concepts in my own Ruby code for a while but without any real direction or rationale beyond, "it just feels better".

Looking forward to seeing how this pans out for you.

Thanks for sharing. :-)

Thanks for sharing. I'm onboard for preferring composition to inheritance by way of modules. I've heard enough OO practitioners recommend that that I'm starting to believe its actually a design principle of modern OO.

I have to say though that when I heard you say that all of your classes inherit from Hash I said out loud "I hope you trust your collaborators and like nilErrors". I honestly think this is a big mistake. If I am using a class with embodies a well defined concept (because if it wasn't, then it could very well be a hash), I want to know for certain what attributes can be relied upon. I'd like to be able to see those as methods to document that. It should not be my job as the user of the class to "ask" it for properties and then either do loads of nil checking or just hope I got the hash key correct.

For this I direct you to a talk by Avdi Grimm called Confident Code avdi.org/talks/confident-code-railsconf-2011/ Writing code that must query, poke and prod domain objects for properties at run-time which most of the time can be guaranteed at "compile time" so to speak leads to timid code. Code that must spend all its time dealing with edge cases rather than expressing the business logic. There's also another article recently mentioned on ruby5 that outlines the woes of writing classes that wrap a hash but leave access to write/mutate keys available to collaborators, but I lost track of it.

My FP experience is with Haskell. I find that typeclasses and a very present type system means you can concisely write functions that deal with data types that are guaranteed to have the interface you require of them.

Just my 2 cents. I'd be interested to see how this pans out on projects with > 1 developer. I'd be kind of ticked off if I was given a library where I was expected to integrate by way of hash access.