[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-debug-dev] List of Plan items
|
I am not proposing to replace the adapter mechanism completely. But we
have interfaces like ICDIBreakpointManagement, ICDISourceManagement,
ICDISharedLibraryManagement(i.e. ICDIModuleManagement),
ICDIExpressionManagement. I think client should be able to register the
implementations of these interfaces dynamically. Anyway, I hope I'll
find time to come up with more details.
BTW, in the gdb/mi implementation there is a class - CObject. It's the
base class for the CDI hierarchy. Making it a subclass of PlatformObject
solves most of the problems.
-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Alain Magloire
Sent: 16 October 2006 18:58
To: CDT Debug developers list
Subject: RE: [cdt-debug-dev] List of Plan items
> From: On Behalf Of Mikhail Khodjaiants
> Sent: Friday, October 13, 2006 4:22 AM
> To: CDT Debug developers list
> Subject: RE: [cdt-debug-dev] List of Plan items
>
> John,
>
> I agree that we need a mechanism like IAdaptable in CDI. I am
> currently trying to implement the new approach I proposed at the CDT
> summit and I have to use instanceof far too often. But as a long term
> solution I would prefer to use the service mechanism in most cases,
> similar to what DSF is using.
>
I'm not familiar with the service mechanism you are referring, but the
question is; will this "service mechanism" be overkill?
>From what I'm reading in this thread adding:
public Object getAdapter(Class adapter);
method to ICDIObject will satisfy most requirements. Did you have
something more thorough/complete in mind?
> From: On Behalf Of John Cortell
> Sent: 12 October 2006 21:15
> To: CDT Debug developers list; CDT Debug developers list
> Subject: Re: [cdt-debug-dev] List of Plan items
>
> Alain,
>
> Regarding item 1. One thing I find lacking in the design of CDI is
> that ICDIObject does not extend IAdaptable. That requires us to rely
> on instanceof for runtime interface binding, which works, but is not
> as robust. Thoughts? Maybe something you'd be up for introducing? I'm
> not sure if there would be any difficulties in doing this, but I
> figured this level of change is best left to the seasoned experts.
>
I do not see any difficulty except that it will break backward
compatibility but since this is targeting a major release, it should not
be a problem.
The other thing, is that we did not want to bring org.eclipse.*
namespace in to the interface so we could;
- Have our own IAdaptable containing utility methods
- Only bring the getAdapter() method to ICDIOjbect
- Implementing that "service mechanism" that Mikhail is proposing.
- Say is it is not worth the effort and add classes like
org.eclipse.core.runtime.IAdaptable or org.eclipse.core.runtime.IPath in
the CDI interface.
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
--
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
