Community
Participate
Working Groups
It would be nice to be able to declare a variable to have the capitalized content of an other or vice versa. For example the template public ${type} get${Name}() { return ${name}; } could automatically use the lowercased value of ${Name} for ${name}.
nice idea but the notation needs to be more explicit - lower prio - Claude FYI
The more general idea is to support functions of variables in templates. This requires to introduce functional constructs both in templates as well as in 'linked positions'. The notation could be something like public ${type} get&{capitalize${type}} { return ${type}; } The increased completity in grammar and the shift towards a turing complete programming language is holding me back from implementing it right away. An alternative could be to introduce templettes - small java classes which could be loaded at run-time. Any complex logic could then be implemented in the most familiar language - Java.
*** Bug 14601 has been marked as a duplicate of this bug. ***
Unassign due to staff changes.
*** Bug 35569 has been marked as a duplicate of this bug. ***
*** Bug 36203 has been marked as a duplicate of this bug. ***
I see that the last comment here was in 2004. Having a feature like this would be extremely useful for the project that I'm working on. I think it could build it on top of the current syntax. For example: // FooProperty: ${name} ${:import(com.somewhere.Foo)} private final Foo<${type>}> ${name}Property = new Foo("${name}"); public ${type} ${theGetter:getter(name)} { return ${name}Property.get(); } public void ${theSetter:setter(name)}(${type} value) { ${name}Property.set(value); } My short list of modifiers would include: ${id:getter(variable)} - Returns the getter name for the referenced template variable. For example, "getName" or "isName". This could follow the configuration settings for getters. ${id:setter(variable)} - Returns the setter name for the referenced template variable. ${id:capitalize(variable)} - Return the capitalized form of the referenced template variable (e.g., "foo" -> "Foo", "Foo" -> "Foo"). ${id:uncapitalize(variable)} - Return the non-capitalized form of the referenced template variable (e.g., "Foo" -> "foo", "foo" -> "foo"). Note: I'm not sure what "FOO" should map to... "fOO" or "foo", and I'm not sure it really matters. One can always refactor if it guesses wrong. Lots of others (uppercase, lowercase, etc.) are possible, but I know we could use these.
I want to add my voice to this issue. Taking my first stab at JDT code templates, attempting to make a "with" method template: public ${enclosing_type} with${Property}(${Type} ${property}) { set${Property}(${property}); return this; } This would be trivial to implement with the capitalize/setter variables as outlined by Jim Mayer.
*** Bug 365685 has been marked as a duplicate of this bug. ***
I think a "turing complete" function syntax is over-engineered, as most of the duplicates of this bug request fairly simple string operations on other variables values, most often changing the case. Actually I consider the available variables insufficient, as I myself bounced against the wrong case within the first half hour of writing my very first template, only to find out, that it won't work the way I'd like it to.
*** Bug 220953 has been marked as a duplicate of this bug. ***
(In reply to Holger Klene from comment #10) > I think a "turing complete" function syntax is over-engineered, as most of > the duplicates of this bug request fairly simple string operations on other > variables values, most often changing the case. Agree
The templates are so powerful yet still very limited by not being able to convert between common naming rules for converting between filename, types, variables, etc in order to generate even larger blocks of common code. I'd like to add my vote here. I suspect even the addition of simple conversion functions between upper and lower camel case, underscored capitalisation, prefix / suffix stripping, etc could go a long way to supporting the needs of most applications. These can of course already be added with extensions for limited context types, but it would be useful if they could be added with only template extensions (i.e. without the need for custom resolvers). And for all context types. What would be even more useful is if these conversions could be continuously re-evaluated as the user updates a user defined variable in an editor template.
(In reply to Martin Otzen from comment #12) > (In reply to Holger Klene from comment #10) > > I think a "turing complete" function syntax is over-engineered, as most of > > the duplicates of this bug request fairly simple string operations on other > > variables values, most often changing the case. > > > Agree Me too
Full Agreement on my part.
Agree on the basic concept here. But let's not re-invent the wheel once more. I recommend to use something already there, like the string operations in gnu make. It has all the requested stuff like changing case combining strings a.s.o. I agree the GNU string functions is maybe not the prettiest of syntaxes, and it was ment as a good candidate. But in any case better a ugly syntax that i already know than a beautiful thing I have to learn all over, and can only use here.
