| Re: [handly-dev] modeling above source file |
Hi Vlad,Thanks for your comments!Yes, I think layers on top of the core framework could be developed to further simplify matters for certain *classes* of languages. It might be a fruitful direction for future work and I would welcome research in that area. For example, we might have a look at DLTK and build a similar structure atop Handly; I see how it might be useful for some, probably even for many. However, my current thinking is that it should be done in a separate layer outside Handly Core, maybe even outside the Handly project.You see, I'm very cautious to premature generalization. In my view, trying to avoid faulty generalization while imposing as minimum restrictions as possible on the shape of the model is an important goal for Handly.
Some of the other important goals are:* Address infrastructural concerns of the model, such as handle/body design with an LRU cache, change notifications, working copy etc.* Enable construction of generic layers on top of the Handly Core, such as common outline framework, search/indexing engine etc.Simplification per se is not necessarily a goal for Handly Core. To *radically* simplify creation of the code model, 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 and to provide a uniform handle-based API that can be leveraged by other tools.Speaking of FooModel/FooProject for example, it's about 350 lines of boilerplate code in total that is not so hard to write and understand. I think trying to generalize this within Handly Core might not really worth it and could create more problems than it would solve.So I would say the omission above the source file level we're talking about is quite intentional, being the result of a (tough) design decision between "sins of omission" and "sins of comission" in the core framework. But it could be addressed in a separate layer that would impose some structure for a certain class of languages. At the very least, it would be an interesting experiment.Best regards,
VladimirHi!I am working at the model structure above the source file level and I have a few questions/suggestions/ideas.* I was thinking that most of the code in the FooModel and FooProject classes is generic, wouldn't it be nice if it would be part of the Handly framework? (The tutorial code can be a good place to start) The awkward part would be that these generic parts can only know about IHandles, not IFooElements, but maybe it's possible to use generics? The other question mark is where to put hooks that need to be implemented for each language.* Even the next level (corresponding to concepts like "source directory" and "library") feels like it could be quite generic. I'm not so sure yet, as I'm still exploring. Here it's more likely that the concepts are language-related, but there are common traits. Do you think it would be useful to try to look at those too?What do you think?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