Erik Johansson wrote on Mon, Dec 13, 2010 at 22:27:04 +0100: > On Fri, Dec 10, 2010 at 14:29, Daniel Shahaf <d...@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 >
