The point is to never assume the structure of another object, but to
let it decide that. So you never get A.B.C you always use a method on
A to do the work. You get a lot more methods on A but the structure
underneath can change without a ripple effect. For example if you had
2 associations that got merged into one you can still support the same
method interface and then filter the one association to appear to be
2. Or you can merge 2 into what appears to be one, etc. Using
plugins that do this too simply removes some of the value. If they
always map the underlying structure you have not gained much. But, if
you can specify the intended interface and then map that to the
underlying structure you have gained much more. That of course
requires a more sophisticated (complex) plug-in and some added work to
explicitly define the interface. The whole convention over
configuration means that the underlying structure tends to be exposed
more than good software engineering practice would advise, but it
works because most of the time the cost to fix a change is actually
lower in Ruby than the cost of preventing the change.
Michael
On Oct 1, 2008, at 7:54 AM, Mark Wilden wrote:
On Wed, Oct 1, 2008 at 6:11 AM, David Chelimsky
<[EMAIL PROTECTED]> wrote:
It's been a while since I've taken a look at it, but Luke Redpath has
a plugin called Demeter's Revenge
(http://plugins.code.lukeredpath.co.uk/browser/demeters_revenge/trunk)
that actually manages this all for you by adding methods like
team.add_player that wrap chains like team.players.add. It's a year
old and I don't know if it works w/ the latest rails updates or not.
See, this is what I don't get about Demeter. By adding delegators,
you might trick someone into thinking that you're not playing with
other objects' parts, but really you still are. Does Demeter just
mean mechanically adding a level of indirection?
For example, in the case under discussion, even with Demetering,
you're _still_ going to get back a proxy object, and end up with the
same problem, aren't you?
///ark
P.S. Of course, controlling access to data (especially changing it)
can often be a Good Thing. But that's just a general principle and
applies to your own data as well as to your data's data's data.
Nothing Demetery there.
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
