In comp.lang.objective-c David Phillip Oster <[EMAIL PROTECTED]> wrote: > Yes. I Alan Kay's OOPSLA talk, > http://video.google.com/videoplay?docid=-2950949730059754521 , he says > that if you are giving out access to your parts (my string attached to a > puppet's finger example) you've got a broken API. To be truly object > oriented, in his view, you have an object that does things, and hides > the details of HOW it does them. You tell the puppet to pick up > something, and trust it to move its fingers itself. > > That sounds fine, until it is time for me to actually sit at a keuboard > and write a program.
I agree. Things like the Law of Demeter sound great but I have no idea how to actually do them consistently. [snip] > So, if XCode is generating getters that return a copy, to actually > modify a leaf of a tree, I'd have to get access to the leaf's owner and > write: [leafOwner setLeaf:[self mymodifiedLeaf:[leafOwner leaf]]]; IMO it's better, if you can, to hold immutable structures rather than holding mutable ones and handing out copies of it. But when you're implementing a mutable data structure then this idea makes things hard, as you say. I think the correct way to deal with it would be to take a page from functional languages and abandon the idea of using the setters at all. You'd write a recursive function/method that takes the original tree and returns a new tree with the modification made. But still, we're not in a purely functional language, so why should we be stuck doing things that way? Perhaps the answer is to apply this law only to controllers and such, rather than to actual data structures. It does seem to work much better there. If you ever find yourself doing [[someController contents] addObject...] then you're probably abusing the API and setting yourself up for problems. Better to do [someController addContentObject...]. But when you move from controller-controller talk to controller-model talk, it does seem to fall down. -- Michael Ash Rogue Amoeba Software _______________________________________________ Help-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnustep
