[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [handly-dev] A milestone build of Handly 0.5
|
Hi Vlad,
Thank you very much for the prompt feedback!
Let me try to elaborate on it a bit.
* Is any of the three ways to implement a model recommended over the others?
Actually, no. A beauty of this new approach (if I may say so) is that there is no good technical reason to recommend one way over the others. Actually, there is not much between them. In each case, the model implementor has complete control over the model API.
First, I'd like to emphasize that the provided "extension interfaces" are just mere convenience for "mixing-in" some methods into the model API at the sole discretion of the model implementor. Handly neither requires nor queries these extension interfaces in something like casts, instanceof operators etc. So, if you think that a set of methods defined in an extension interface would be nice to have in your model API, you can extend that interface. If, on the other hand, you don't like some of the predefined methods (say, you'd much prefer to expose methods that return lists rather than arrays), you are completely free to not extend the extension interface that defines those unwanted methods. This decision is made for each of the extension interfaces separately. For example, you could extend, if you like, ISourceFileExtension and ISourceElementExtension, but not IElementExtension.
I can, perhaps, think of only one caveat with the extension interfaces: the current version number of Handly, which means the API is not completely finalized yet. In theory, the extension interfaces may still evolve, although I don't anticipate that it will really happen in practice. *But* if you want to be very sure that your model API will not be affected by pre-1.0 evolution of Handly, you might prefer to use the second strategy or even the third one.
Speaking of the latter two strategies, it really depends on whether you can tolerate any mentioning of Handly in your model API :-) The most conservative approach would be to start with the third strategy. Its only disadvantage is that occasionally clients of your model API might have a need for a cast to IElement etc. when interacting with some generic Handly-based API (like the Elements and ElementDeltas classes). However, you can always change your mind later on and adopt the second strategy while retaining full backward compatibility for your model API.
* What are the use cases where each is better suited?
Perhaps the first strategy can make getting started with a new model API a bit easier, especially if you don't care of the finer details of the API very much. However, even the first strategy gives you complete control over the model API, since you are the one who picks and chooses desirable extensions.
On the other hand, the third stategy might be a good choice for something like JDT (theoretically speaking), where a dependency on Handly in the model API (even on the marker interfaces) might not be welcome.
The second strategy is perhaps a reasonable default if you're really serious about the model API or need to implement a pre-existing API. Please note that this strategy is not necessarily mutually exclusive with the first strategy.
* Do I understand correctly that for #2, it means the hierarchy is like below?
Not quite: MyElement extends Element which implements IElementImpl. You don't have a need to extend or implement IElementExtension in this case.
* Maybe it would be useful to have a small example for each of the ways...
Absolutely! My current thinking is to leave the basic example as is (i.e. using the first strategy), and move the Java model example to the second or third strategy, while at the same time making it implement a "forked" JDT API (with somewhat reduced functionality to keep it manageable as an example).
However, this goal seems a bit too ambitious for me to undertake in the 0.5 time frame. There is also no time left for significant community contributions to 0.5 (given the necessary Eclipse IP process). So, this looks like a pefect work item for 0.6, and I would certainly welcome contributions and would very much appreciate any help regarding this work, or may be providing a separate smaller example that would demonstrate one of the other strategies (there really is not much between the second and third strategy from the model API point of view). Thanks a lot for suggesting it, Vlad! It would be a really nice contribution. Should we discuss it in more detail?
Thanks,
Vladimir
Hi Vladimir!
I think this looks very nice. I will try to check it out "in action" to get a better feeling. Until then, a couple of questions (I can give partial answers myself, but I'm thinking that a fresh user might not be able to, so these should be part of the introductory reading):
Is any of the three ways to implement a model recommended over the others?
What are the use cases where each is better suited?
Maybe it would be useful to have a small example for each of the ways (optimally, I'd say "let's take the Java example and do it the other two ways", but it feels like a bit too much duplication). I can try to provide that as a way for me to get acquainted with the new API.
Do I understand correctly that for #2, it means the hierarchy is like below (I hope it gets formatted nicely)?
+--------------------+ +-----------------------+
| | | |
| IMyElement +----------> IElement |
| | | |
+--------------------+ +-----------------------+
^
|
|
|
+--------------------+ +----------------------+
| | | |
| MyElement +-----------> IElementImpl |
| +-----+ | |
+--------------------+ | +----------------------+
|
|
| +----------------------+
| | |
+-----> IElementExtension |
| |
+----------------------+
best regards,
Vlad