I think it’s a neat idea, but your last paragraph seems like the killer problem. If the linked-to sites are OK with it, it seems fine (IMO). But figuring out if it’s OK or not sounds like a hard problem.
Yay! I think we have a PR for supporting JSON types natively in Rails. I’m really excited about PostgreSQL 9.2!
Another Pro Tip™, you can use define_method inside the Class.new block to create another closure. This gives the method access to variables defined outside the Class.new:
bar = :hello
z = Class.new {
define_method(:omg) { bar }
}
z.new.omg # => :hello
I find it to be another handy trick for defining simple mocks.
I always thought it was odd that a Ruby object can call another object’s protected methods if they are of the same class, mostly because I couldn’t think of a circumstance where this would be a desirable behavior. The example in the article of using this behavior while implementing equality operators is something I hadn’t thought of.
That’s pretty much the only use case I can think of. Even then, I implement equality operators so infrequently that I’ll forget!
It’s useful for any kind of comparison (<, >, <=>, ==, ===). I only use protected for methods that are used in comparison (most commonly, accessors).
Fucking Wordpress, man.
Also, your suggestion about a block to Struct.new made it into this version, thanks for that. :)
Nice. You can also give Struct.new a block and define instance methods:
irb(main):002:0> Struct.new('Foo', :bar) do
irb(main):003:1* def baz; :omg; end
irb(main):004:1> end
=> Struct::Foo
irb(main):005:0> Struct::Foo.new.baz
=> :omg
irb(main):006:0>
Why is it not “DCI” when one simply uses composition to access the data objects?
Agree. I don’t “get” DCI. It seems like overkill crazytown.
Especially because you can use them to achieve the entire effect without these crazy negatives.