Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [handly-dev] Modeling ideas
Thanks!

/Vlad


On Wed, Oct 15, 2014 at 8:44 AM, Vladimir Piskarev <pisv@xxxxx> wrote:
Hi Vlad,
 
Glad to hear from you!
 
I think that implementing a parallel model from scratch is a good idea.
It should be easier that way, and the result would probably be of better
quality too. That's also because there are some subtle but significant
differences in Handly design compared with 'older' models such as JDT.
 
Regarding methods like getSourceFolders/getIncludeFolders
I would suggest implementing them as filters over all children,
introducing backing caches only when and if necessary (for example,
if the number of children may actually be very large). In my
experience, there is rarely if ever such a necessity. JDT seems
to confirm that. For example, SourceType's getFields(), getMethods(),
and getTypes() methods are implemented as filters over all children.
 
ISourceElement.Property is meant for storing extra properties of a
source element that are not part of its 'key' and hence, the handle.
An example would be formal parameter names of a function. Technically,
any 'value object' will do (Strings, primitives, arrays/lists of those...)
 
Latest Handly builds are available directly from Hudson:
https://hudson.eclipse.org/handly/
 
 
 
These URLs are stable. We have no 'nightly builds' per se. Instead, builds
happen on-demand when changes are detected, or by explicit request.
 
HTH,
Vladimir
 
 
Hi Vladimir,

I spent most of the day trying to figure out how to reimplement my model with Handly, and I think that the easiest way is to implement a parallel model from scratch. That's because the current one mixes the "handle" and "body" functionality and they are difficult to separate incrementally.

Anyway, I would like to ask for a bit of feedback, as you probably did think more about how to implement models than I did.

The model elements sit in a parent-child hierarchy tree. An element can have children of different types or with different purposes that are exposed separately through the IFooSomeElement interfaces. Do you think that these specific methods (for example a project's getSourceFolders and getIncludeFolders) should be implemented as filters over all children, or should they be backed by separate lists/arrays? The former makes it easy to handle adding/removing children, but may be a bit ineffective if the children need to be filtered many times.

Also, what kind of values is ISourceElement.Property meant for?

Finally, an unrelated question: are there update sites for nightly builds? The "older Eclipse targets" fix has not been released yet.

best 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

Back to the top