Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [handly-dev] A better naming convention for model *Impl* interface methods?

We'll use bug 521851 to track further work on this item.

Best regards,
Vladimir


Given the wide-ranging effect of the proposal and the summer season, I'm extending the vote for another week, until September 1st.


If I hear no objections, I'm going to implement the "underscore suffix" proposal. Please raise your concerns/state your preference if you have any. A supportive +1 would also be very welcome.


Thanks!
Vladimir



  Well, if I'm not completely blind, the underscore suffix for *Impl* method names looks preferable to other previously mentioned alternatives when applied in the context of a large-scale real-world model such as the JDT Java model. You can see for yourself:

https://github.com/pisv/jdt.core-handly (master) -- the existing convention based on the h prefix

https://github.com/pisv/jdt.core-handly/tree/naming -- the proposed convention based on the _ prefix

https://github.com/pisv/jdt.core-handly/tree/naming2 -- the proposed convention based on the _ suffix

So my +1 goes to the underscore suffix proposal now, but I'm looking forward to hearing from others.

Thanks,
Vladimir



A variation of the original proposal has arrived -- using the underscore as a method name suffix rather than prefix.

To my eyes at least, it looks even more readable and in fact, blends so well with the "user part" of model implementation code that it can be a bit challenging to distinguish between "framework methods" and "user methods" in things like content assist, outline popup, etc. But this is the only potential issue with this approach as far as I can see. A noticeable benefit, besides improved readability, would be that it makes possible for the framework to follow the usual conventions in naming getters and setters, so that JVM-based languages such as Xtext can provide additional support for them.

Please take a look at a version in playground that is based on this alternative proposal:

https://github.com/pisv/handly-playground/tree/naming2

Meanwhile, I'll try to adopt it in the Handly-based fork of JDT Core to get a better feel of how it would work in the context of a large-scale real-world model.

Thanks,
Vladimir

Back to the top