Re: [handly-dev] Doing work in Handle or in Body

[Vlad Dumitrescu <vladdu55@xxxxxxxxx>]

Thanks a lot Ondrej and Vladimir! 

Having the project configuration's life cycle separated from the project's is a good idea. Actually, I might even move it "on the other side" (by which I mean that I plan to have the "real" model implementation outside Java, in Erlang, as it is much easier to handle Erlang in Erlang)

The reason I am worried about efficiency is that some users have huge projects with huge files and for a couple of years back I tried to put together an implementation based on Xtext. It went well, but the big issue was that it couldn't handle the huge projects, it took minutes at startup to set up index and things like that. I'd rather not hit that kind of wall again :-)

best regards,

Vlad

On Thu, Mar 26, 2015 at 10:28 AM, Vladimir Piskarev <pisv@xxxxx> wrote:

Hi Ondrej,

 

Thank you very much for the excellent explanation!!! I could not have explained it better, but posted my reply just before getting to see yours. I hope it is clear that my answer does nothing but concurs with your observations though :-)

 

Thanks again!

Vladimir

 

 

Hi Vlad, hi Vladimir and others!

I'm also very interested in this and looking forward to see Vladimir's response. In the meantime, let me share my 2? about it.

From my point of view there are two separate questions to answer:

1) Do we have to load classpath configuration to create a handle? The answer is obviously yes as there's no 1:1 mapping between the basic resource model and Java elements.

2) Do we have to build the project structure to create a handle? Now, it depends on the way a model is implemented, but generally I don't think it is required. What more - I don't think the current Java model example does it - what it does is it loads the classpath configuration, but AFAIK structure building is not triggered until you call getChildren(), getNonJavaResources() or until you call these methods on any of project's child - none of which seems to happen when you create a handle for a package fragment. On the other hand the Java example partially avoids this problem simply by not caching the classpath configuration at all (it's still work in progress and caching is not yet implemented). I can't speak for Vladimir, by according to my our previous discussion with him, his plan to handle classpath caching is to do the same JDT does - store it separately outside the project model body in a object with a bit different life cycle (see PerProjectInfo in JDT). This provides a way to cache project configuration without having to build the project body and possibly keep operating with handles lightweight. For the record, it's the way I'm going to go too. 

Maybe a similar approach would work also for your model.

Vladimir, please correct me if I'm wrong or misinterpreting something.

Regards,

Ondrej

On 25. 3. 2015 14:29:17, Vlad Dumitrescu <vladdu55@xxxxxxxxx> wrote:

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

On Tue, Dec 23, 2014 at 9:34 AM, Vladimir Piskarev <pisv@xxxxx> wrote:

Hi Vlad,

 

I think the distinction between handle and body is mostly about data,
not computation. As far as I can tell, JDT usually puts computation
in handles, and treats bodies as data holders. However, there is no
hard rules here, and I would suggest following common OOP sense
when deciding this question. Anyway, clients initiate computation
through handles, regardless of where it is actually implemented

(as a rule).

 

If you could come up with some code snippets or pointers to
source code in your git repository, I might be able to provide

more guidance (if needed).

 

Best regards,
Vladimir
 

 

Hi!

On Fri, Dec 19, 2014 at 3:59 PM, Vladimir Piskarev <pisv@xxxxx> wrote:

There is no rule that non-handle-only methods must delegate their work to a body (if I understand you correctly). I think what's really important here is the distinction between "handle only" and "other" methods for model elements; contract rather than implementation details.

Well, not a rule, but the whole point of the framework is to separate the lightweight functionality from the heavier one. There is a cache for bodies, so implementing heavy things in the handle might lose some efficiency.

Using "throws CoreException" as a discriminator is a good idea. Thanks!

regards,

Vlad

_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev

_______________________________________________ handly-dev mailing list handly-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/handly-dev

_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev