It’s built for speed, so, yeah it’s pretty low level. Adding fields to the classes will require a change in the version number and force reindexing. You could add a generic field for “properties” to all or some subset of PDOM node classes. So it’s like (a) but done generically as in (b). From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alena Laskavaia Sent: Wednesday, December 08, 2010 11:26 AM To: CDT General developers list. Subject: Re: [cdt-dev] pdom extensions? I looked at db implementation - it is very low level - records offset at stuff. I cannot see how we attach arbitrary data to it... Looks like it is hard coded to be fixes size. Am I missing something? On Wed, Dec 8, 2010 at 10:34 AM, Mike Kucera <mkucera@xxxxxxxxxx> wrote: I like option b. The ability to attach arbitrary key/value pairs to PDOM nodes might have a variety of uses.
Alena Laskavaia ---12/07/2010 08:48:47 PM---I think I need to create a framework not only for checker for also for
I think I need to create a framework not only for checker for also for extended semantic information that can be used by other checker. For example I can keep the information that function may return null (or never returns null). This info need to be kept per function (per global variable, type, class, etc).
The question is where do I keep this information. a) extend PDOM with specific semantic attributes? b) use some sort of generic extensions that can be attached to PDOM nodes? c) create totally different db?
Ideas? _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev
|