Ducktyping is nice, but realistically how often do you add a new kind
of data, that's completely interchangeable with the old kind, but
stored in a different table? OO and polymorphism are very nice in
theory, but where the rubber meets the road sometimes you just want
to make sure you're only saving the data you're supposed to.

I use 'duck typing' extensively even with AR objects. It allows me to
extend the whole system in ways that are more elegant (IMO) than the
traditional ones associated with static typing. Some times I just need
an object that behaves like an AR object for certain types of testing
or maybe I'm creating an 'impostor' object that will masquerade as an
AR object for a certain purpose. I guess in my own experience, the
rubber hits the road in places that OO and polymorphism is not just
theory, but actually comes in quite handy.

If one part of my system creates a strong contraint (like enforcing
that some objects are of a certain class), I limit what the rest of
the system can do in the future. So if I needed to make sure that a
bunch of records all map to the same table, like in your example, I'd
actually check that they all come from the same table (via
o.class.table_name), rather than enforce that they all are of the same
class.

And regarding 'to make sure you're only saving the data you're
supposed to', I tend to validate my data directly rather than depend
on the programming language's object model to do it for me.

More 2 cents that nobody asked for :)

Dan
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby

Reply via email to