[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] [DSF] SessionType
|
> -----Original Message-----
> From: Vladimir Prus [mailto:vladimir@xxxxxxxxxxxxxxxx]
> Sent: Friday, July 09, 2010 2:25 AM
> To: Marc Khouzam
> Cc: 'cdt-dev@xxxxxxxxxxx'
> Subject: Re: [cdt-dev] [DSF] SessionType
>
> On Friday 09 July 2010 00:24:58 Marc Khouzam wrote:
>
> > > Are there so many such methods in GDBControl_7_0 that it
> > > makes sense to refuse
> > > further additions, or you thin that -exec-run/-exec-continue
> > > difference is
> > > not common enough?
> >
> > I'd accept everything if it wasn't for API compatibility :-)
>
> Ok, fair enough.
>
> > Adding a new API is usually ok, but the problem is when we want to
> > add it to an existing interface: anyone using that interface
> > will break.
>
> I'm not too knowledgable about binary compatibility in Java, so
> could you clarify one thing.
I'm still learning as well :-)
> Suppose we add new method to
> GDBControl_7_0 to decide whether to use -exec-run or -exec-continue,
> and it has the logic that is used now. Why will that break derived
> classes? I think that if the method is protected, then it's interface
> *only* for derived classes.
Yes. I've added a patch like that to the bug. I believe it will fit
your needs, without breaking the API.
The problem is that your original suggestion added an method to an interface.
interface myInterfae {
void foo();
}
class myClass implements myInterface {
void foo() { }
}
If I add method bar() to myInterface, myClass will suddenly not compile anymore
because it _must_ implement bar().
Marc