Re: [RFC] Common object property boards

On Mon, Aug 8, 2011 at 12:22 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Robert Haas's message of lun ago 08 12:05:05 -0400 2011:
>> We could do that, but what the heck is the point?   What benefit are
>> we trying to get by not returning a pointer to the structure?  I feel
>> like we're making this ludicrously complicated with no real
>> justification of why all of this complexity is adding any value.
>
> I don't see that it's complicated in any way.  Seems pretty simple to me.

It's quite complicated. Every time someone adds a new member to the
struct, they need to adjust the code all over the place. The call
sequence of the accessor function will constantly be changing. We
generally try to structure our code base so that patches don't need to
touch more call sites than necessary, and we regularly get very
nervous about patches that touch too many call sites and ask them to
be changed so that they don't. Here, you're proposing a design that
is practically guaranteed to have that problem every time someone
makes a change in that area.

> The justification is simple too: don't export struct definitions without
> need.

That's a reasonable guiding principle, but I believe that the
underlying reason to do that is information hiding. In other words,
if the details of what's in the struct don't matter to other modules,
then they shouldn't peek into it. That way, when you want to change
something, you don't have to worry about whether anyone else cares
about the encapsulated data, because you already know they don't. In
this case, however, the struct - by design - isn't going to contain
any private data. If callers are going to potentially need access to
every member of the struct, then you may as well export it and be done
with it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company