[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [handly-dev] Doing work in Handle or in Body
|
Hi Vlad,
Thanks for the question. I think this may be a topic of general interest to Handly adopters, so excuse me for a longish rant :-)
The Java model example is still a work in progress and the particular implementation approach I have taken is "make it run, make it fast". You may have noticed that there is no model cache at the moment (actually, I've just implemented it yesterday), and there is still a TODO in JavaProject#getRawClasspath() about the need to cache the result. This, of course, means that the current implementation is *very* inefficient. However, I'm pretty sure it can be made, in principle, as efficient as the JDT Java model, which seems to be efficient enough :-)
The model cache is the key to efficiency. With it in place, resolving a body becomes "one time computation". Add to this "lazy-loading" (the concept of "openable"): by default, "opening" an element (i.e. resolving its body) does not recursively "open" its children (though it does need to "open" its parents if they are not already open). Also, a smart cache with an LRU policy allows to set a cap on memory consumption. So, overall, model implementors can have a very fine-grained control of efficiency and speed/memory trade-off.
That's why I suggest "make it run, make it fast" approach for Handly-based models in general, and in particular not worrying too much about "handle-only or not" with regard to effiency (but, of course, behavioural differences are very important, as "handle-only" operations rely only on (immutable) state in the handles, not on (changing) state in the workspace).
Now, not every model operation can be strictly "handle-only" and JavaModelCore#create(IFolder) is an example of this (as you described, it needs the project's classpath information in order to decide whether it should create a handle for a folder or not). That's not something unique, as even IContainer#findMember(IPath) infers the resulting resource's type from the resource existing at the path in the workspace, i.e. it's not "handle-only" in the strict sense.
Regarding whether the project's configuration belongs to the body -- I don't think it should, in general. This has been discussed in some detail on the forum:
Generally speaking, there is no need to access the project body to read the classpath, it might be cached separately in something like JDT's PerProjectInfo. But even if you choose to store configuration information in the project's body (whatever the reason), I don't think it will be particularly detrimental to performance, thanks to the model cache and the concept of "openable".
N.B. When I get to implement the TODO in JavaProject#getRawClasspath(), I'm going to stride the PerProjectInfo route :-)
HTH,
Vladimir
Hi Vladimir,
I am still a bit uncertain about how to separate handles and bodies, so I'm reviving this older discussion.
The thing that bothers me is that for models that are more complicated than a toy, projects get their configuration from a file or preferences. This configuration belongs to the body, as it's not lightweight and is not a value object since it can be changed. The problem is that, using your simple Java model as example, in order to decide if we should create a handle for a folder or not (if it's on the classpath or not), we need to access the project body to read the classpath. This in turn might trigger building the project's structure and operating with handles is no longer lightweight.
In your Java example you hide this in the API by catching the CoreException, but the side effects can still be significant. In practice it means that there are very few operations that will be "handle only", so I'd like to hear your thoughts about it.
best regards,
Vlad
