[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Alloc/dealloc etiquette
From: |
Michael Ash |
Subject: |
Re: Alloc/dealloc etiquette |
Date: |
Sun, 18 Feb 2007 14:48:27 -0600 |
User-agent: |
tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE-p20 (i386)) |
In comp.lang.objective-c David Phillip Oster <oster@ieee.org> 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
- Alloc/dealloc etiquette, Michael Hopkins, 2007/02/17
- Re: Alloc/dealloc etiquette, Michael Ash, 2007/02/17
- Re: Alloc/dealloc etiquette, Sherm Pendley, 2007/02/17
- Re: Alloc/dealloc etiquette, David Phillip Oster, 2007/02/17
- Re: Alloc/dealloc etiquette, David Phillip Oster, 2007/02/17
- Re: Alloc/dealloc etiquette, Sherm Pendley, 2007/02/17
- Re: Alloc/dealloc etiquette, Michael Ash, 2007/02/18
- Re: Alloc/dealloc etiquette, David Phillip Oster, 2007/02/19
- Re: Alloc/dealloc etiquette,
Michael Ash <=
Re: Alloc/dealloc etiquette, Michael Hopkins, 2007/02/17
Re: Alloc/dealloc etiquette, Jens Ayton, 2007/02/19