Erik Johansson wrote on Mon, Dec 13, 2010 at 22:27:04 +0100:
> On Fri, Dec 10, 2010 at 14:29, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > Could you untangle this mess around driving the editor? (I might be
> > able to look into this later, but not right now)
>
> See attempt in other thread.
>
Saw the thread, marked it for attention, will get to it hopefully soon.
> >> >> +} svn_repos_node_prop_t;
> >> >
> >> > I'm afraid you can't extend this struct due to binary compatibility
> >> > considerations (an application built against 1.6 but running against 1.7
> >> > will create too short a struct).
> >>
> >> This was actually one of my concerns as well. I will try to come up
> >> with another way of doing it.
>
> I've been thinking some more about this:
> - svn_repos_node_t is never used as an in parameter, so there
> shouldn't be any need for applications to create one.
> - If an application creates a svn_repos_node_t, the only use for it
> would be internal to the application in which case it will use its
> version of the struct even if we change it.
> - If we add the new field to the end of the struct there should be no
> problems for applications built with an old version of the struct;
> they will simply not be able to access the new field.
>
So, there would be TWO svn_repos_node_t structs in an
appliaction:
* Those provided by the callbacks
(1.7 style, but application doesn't read the new fields, and we never
read them after the callback had had an opportunity to touch them)
* Those constructed by the application
(svn libraries should never see them so we Don't Care)
> What do you think?
>
Technically, it's probably going to work. (at least as long as we don't
add a function that takes an svn_repos_node_t parameter, etc)
But it's a grey area, and having special cases both complicates
everyone's lives and weakens our API compatibility guarantees.
Call me conservative, but I don't like this option; I would rather not
get into this corner when we could just revv the struct, add
a constructor and duplicator for the new struct, and solve the problem
once and for all. (We have precedent for struct types being defined ---
not just declared --- in the public headers, along with a comment "Don't
allocate it by yourself; use foo_create() to create it.")
> // Erik
>
Received on 2010-12-14 09:08:18 CET