Re: [cdt-dev] [DSF] SessionType

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Friday 09 July 2010 16:55:10 Marc Khouzam wrote:

> 
> > -----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().

Ah, right -- I've realized when comparing your patch and mine. It also turns out
that mine omitted a change in GDBControl_7_0 to actually use the new method :-(


Thanks,

-- 
Vladimir Prus
CodeSourcery
vladimir@xxxxxxxxxxxxxxxx
(650) 331-3385 x722