Home » General (non-technical) » Project Proposals » New project Proposal: Handly
|
| Re: New project Proposal: Handly [message #1236969 is a reply to message #1236964] |
Tue, 28 January 2014 14:05   |
 Vladimir Piskarev
Messages: 68
Registered: January 2014 |
Member |
|
|
Welcome, and thanks for your interest in the proposed Handly project! Feel free to use this topic to ask questions and share your thoughts about the proposal. If you would like to be listed as an interested party for the project, just let us know.
In the meantime, here is a short FAQ that you might find interesting:
Q. I'm curious to know a little more about your plans: which languages you want to support in the beginning. Do you focus on DSLs built with Xtext (only) or will your approach support other programming languages like, say, Perl, JavaScript, and Python too?
A. The Handly core framework is a low-level foundation that is designed to be as programming-language agnostic as possible -- "for anything and yet nothing in particular" in a very real sense. We supply only an abstract API and a partial implementation, which must be extended by the developer for a specific language or language family. It should be noted that, at least at present, Handly concerns itself only with textual languages.
We can provide special support for some language implementation technologies (such as Xtext) that have widespread use and special appeal to the Eclipse community. However, as the proposal states: "it's our explicit goal to keep the core framework completely neutral of any specific language implementation technology and encapsulate such dependencies strictly within corresponding integration layers". Currently, we provide integration with the Xtext editor for reconciling of working copies connected to it. Any Xtext-based language (not just a DSL) can enjoy this support, provided that the developer has created a handle-based model for it on top of Handly. For other languages (not Xtext-based), if working copy reconciling is needed, the developer has to integrate the language-specific editor with Handly via provided API. So, it's certainly more work in this case, but it is possible.
While in principle it could be possible to "rebase" the Java Model or the CDT model or other similar extant models on Handly, it seems unlikely in practice -- besides involving much work, it would break existing API to those models. We'd rather say that this project could provide a useful underpinning for development of new handle-based models for miscellaneous languages and might nicely complement the Xtext effort in attempting to lower the barriers of entry for construction of a full-featured Eclipse-based IDE.
Q. So, it seems like you're going to radically simplify creation of a handle-based model for any programming language? That'd be great!
A. Not quite. For a radical simplification to be possible, many assumptions about the language and the model must be made. Handly avoids making such assumptions, leaning to flexibility instead; it aims to become a low-level foundation for construction of handle-based models for various languages and to provide a uniform handle-based API. While the project does supply a framework that structures the problem area and encapsulates much of the accidental complexity, development of a full-featured handle-based model for a language still remains an essentially complex task. That said, layers on top of the core framework could be developed to further simplify matters for certain classes of languages (e.g. for languages sharing the Java project structure, such as Xtend). It might be a fruitful direction for future work.
Q. If there is anything planned, it would be nice to see a little more details on this...
A. As for specific plans, the project will certainly need much work in such areas as documentation, automated tests and exemplary implementations as we aim at "platform quality". But the main area of work is to come up with a really nice design of the core framework based on community feedback. As the proposal states: "although the code is pretty stable and has been used internally with promising results, we regard it only as a starting point". We look forward to community participation in the continuous design process.
Q. I'm a little concerned that the proposal only has two initial committers...
A. Well, this is a small project, at least initially, with a rather narrow scope. More important, we really hope for community support. While we'd like to provide leadership and vision, we think diversity is really important for this project to succeed. It's an explicit goal stated in the proposal; we don't aim to retain total control. We do welcome additional committers and contributions from the community!
[Updated on: Tue, 28 January 2014 15:43] Report message to a moderator |
|
| | |
| Re: New project Proposal: Handly [message #1258952 is a reply to message #1236969] |
Thu, 27 February 2014 23:10 |
Carsten Pfeiffer
Messages: 34
Registered: July 2009 |
Member |
|
|
Hi Vladimir,
when developing for the Object Teams tooling I've spent quite some time with
the JDT JavaModel, so I know the complexities as well as its benefits.
At the moment, I'm more interensted in getting a handle-based API for non-
programming language models. We have some kind of UML models, with elements
for e.g.
- packages,
- class diagrams with classes (and all their members),
- but also
- use case diagrams with actors, use cases, system boundaries, etc.
- activity diagrams,
- sequence diagrams,
and all kinds of other structured models.
I'm wondering if Handly's scope is "just" programming languages or even all
kinds of structured models.
Thanks and best wishes
Carsten
|
|
|
| Re: New project Proposal: Handly [message #1259277 is a reply to message #1258952] |
Fri, 28 February 2014 07:50 |
Vladimir Piskarev
Messages: 68
Registered: January 2014 |
Member |
|
|
Hi Carsten,
Thank you for the really interesting question!
I would say that Handly's scope is handle-based models in general, but in its current form it's more focused on languages (be they domain-specific or not) for which the primary representation is textual.
I'll try to explain what it means in practical terms. The most fundamental layer of Handly is about the handle abstraction itself, and this layer has no dependencies whatsoever on any representation specifics -- it's intended to provide a universal API and the accompanying partial implementation for whatever handle-based model you have in mind. However, this very universality makes it quite low-level thing, a 'kernel'.
A layer on top of the 'kernel' deals with source files whose contents can be manipulated via an underlying text buffer (the source file is a specialization of the basic handle abstraction). This is where dependency on text as the primary representation is introduced, and this is where the real 'meat' of the Handly currently lies (buffer management, snapshots, working copy, reconciling, integration with text editors, etc.).
An even higher layer integrates this thing with the Xtext editor, so if the language in question happens to be Xtext-based, life is a lot easier.
Hope this helps to understand the big picture.
So, if you'd like to use Handly for the kind of structured models you described, you could just use the 'kernel' part, or even better, try to contribute an entirely new layer to Handly. I would be much interested in such development and probably could help. Besides, developers with your background and experience are exactly what this project needs. Why not come join our effort? :-)
Thanks,
Vladimir
|
|
|
| Re: New project Proposal: Handly [message #1259653 is a reply to message #1259277] |
Fri, 28 February 2014 16:45 |
Carsten Pfeiffer
Messages: 34
Registered: July 2009 |
Member |
|
|
Vladimir Piskarev wrote:
Hi Vladimir,
thanks for the quick response!
> A layer on top of the 'kernel' deals with source files whose contents can
> be manipulated via an underlying text buffer (the source file is a
> specialization of the basic handle abstraction). This is where dependency
> on text as the primary representation is introduced, and this is where the
> real 'meat' of the Handly currently lies (buffer management, snapshots,
> working copy, reconciling, integration with text editors, etc.).
This is actually our scenarion as well. Most diagrams are stored in XML
files in the workspace, so we do need buffer management, working copies, and
all that.
> Hope this helps to understand the big picture.
Yes, it does, thanks.
> So, if you'd like to use Handly for the kind of structured models you
> described, you could just use the 'kernel' part, or even better, try to
> contribute an entirely new layer to Handly. I would be much interested in
> such development and probably could help. Besides, developers with your
> background and experience are exactly what this project needs. Why not
> come join our effort? :-)
We actually have an existing architecture that deals with these issues,
although not quite handle-based. So our situation is a little bit like the
JDT one -- it is not too likely to rebuild all that on top of Handly.
I'm stil interested in it and will monitor and maybe contribute to it if I
see it fit somewhere else.
Thanks again and have a good weekend
Carsten
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 14:30:32 GMT 2024
Powered by FUDForum. Page generated in 0.03117 seconds |
] 
Search
Help
Register
Login
Home
