RE: [cdt-dev] [DSF] SessionType

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----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