[Gtk-sharp-list] API Freeze Policy Adjustment

Todd Berman tberman@off.net
Fri, 02 Jul 2004 03:46:30 -0400


Murray Cumming wrote:
> On Thu, 2004-07-01 at 18:04 -0400, Todd Berman wrote:
> 
>>Murray Cumming wrote:
>>
>>>On Thu, 2004-07-01 at 17:06 -0400, Todd Berman wrote:
>>>
>>>
>>>>Mike is saying that API that is bound and *WILL NOT WORK* can be fixed 
>>>>so that it will work. This wont break anything for anyone.
>>>
>>>
>>>I have no objection to that, as I have made clear. But he is also saying
>>>that he will make large API additions. That is not OK, as I have
>>>explained. I encourage you to read the whole thread.
>>
>>Where did Mike say he plans on large API additions? I must have missed 
>>that part of the thread.
> 
> 
> His blog entry suggests a lot more than that, and that's why I'm
> mentioning it:
> "
> We are also going take advantage of the nice Assembly versioning and GAC
> functionality of mono to allow the addition of missing API related to
> the 2.2 Platform and convenience overloads for methods. This gives us a
> fair amount of flexibility to continue to improve the 2.2 bindings for a
> while, without breaking existing code developed against Gtk# 1.0."
> 
> It is a waste of time to argue so energetically if you have not read the
> thread so you don't even know what is being dicussed.
>  

Sigh, this is my last response to this thread, which I have read 
completely, and I know exactly what is being discussed. However it 
doesnt seem to matter to you as its becoming increasingly obvious that 
you are the kind of person who, when faced with disagreement says the 
same thing in a slightly different way.

Dude, I hear you, and I disagree, but that doesnt mean I dont understand 
what you are saying. I just disagree.

Mike said in what you quoted "Missing additional API" which seems to me 
to mean "API that is bound and broken, or API that we need a tiny bit of 
glue for (like a C macro that we need to bind)".

He also says he is allowing for the addition of convenience overloads 
for methods. It kind of reminds me of adding a new constructor for a 
wrapped GtkAction because your current API wont allow subclassing.

Neither of those two involve 'Large API Changes'. And it certainly seems 
like the goal is to remain source compat with everything thats out there 
right now.

In fact, in previous posts, Mike has said that if there is API that 
takes a ref and should actually take an out, that will not be changed in 
this release series, as the existing binding will still work. That, to 
me, is a small API change, which has already been ruled out as something 
that is going to happen.


So, to recap, once again, no one has said anything about large API 
changes, you are drawing conclusions that don't exist, and it seems to 
be in everyone's best interest if this is just dropped, as its not going 
anywhere. You are as uninformed about Gtk# as we are about Gtkmm, or 
this platform bindings release, lets just leave it at that for now, 
because until we move to track the latest stuff, it is, as I said 
before, a horribly moot point.

--Todd