Community
Participate
Working Groups
Build Identifier: 2.0.1.v201108020636 Unlike the (aptly-named!) Xpand language, Xtend2's rich strings haven't got a «EXPAND func FOREACH collectionExpr» construct, so one is forced to say something like «FOR thing : things»«func(thing)»«ENDFOR» which is rather more verbose but much less clear. Reproducible: Always Steps to Reproduce: (nothing to reproduce)
this is another way to write it: «things.map(t|t.func).join("\n")» and at some point (depends on bug 341048) this should be working: «things*.func.join("\n")»
Hi Moritz, I know there are workarounds, and even many that are less verbose than «EXPAND .. FOREACH ..». That's not the point: I'd like a syntactical construct that makes it very clear what is going on, especially since an «EXPAND .. FOREACH ..» tends to generate a lot of text and so is relatively important (compared to things which happen in expression - obviously, richt strings have obscured this distinction to some extent). This would justify a first-class construct with a distinctive syntax, IMHO.
I've been missing a construct like "«EXPAND .. FOREACH ..»", too. However, I personally find Xpand's syntax too verbose. So don't worry, my comment was more about exploring ideas on not intended to be the preface of a "WONT FIX". What if «iterable» would per default be treated as «iterable.join("\n")» instead of «iterable.toString»?
Hmm, I tend to shy away from that kind of "auto-magic" as it's another thing (/peculiarity) to remember. I really like a syntax that's very close to the actual semantics of the construct and «EXPAND .. FOREACH ..» does precisely that. The way I organize(d) my templates was usually into some DEFINEs that have a lot of EXPANDs which farm off to DEFINEs whose nature is much more "local". So, the verbosity really doesn't hurt there (IMHO) as the sheer character count of the construct doesn't overburden the rest of the code at that point.
Since there is no such thing as an EXPAND in Xtend but only function calls, I don't like the idea to (re)introduce the EXPAND keyword. Personally I don't think that <<collectionExpr*.func>> is not noisy enough to guide the reader's eye. A template may look like this def writeClass(Thing it) ''' <<visibility>> class <<name>> <<extendsClause>> { <<fields*.definition>> <<constructors*.definition>> <<methods*.definition>> } ''' which I like better than writeClass(Thing it) ''' <<visibility>> class <<name>> <<extendsClause>> { <<EXPAND definition FOREACH fields>> <<EXPAND definition FOREACH constructors>> <<EXPAND definition FOREACH methods>> } ''' since it is much more orthogonal.
(In reply to comment #5) > def writeClass(Thing it) ''' > <<visibility>> class <<name>> <<extendsClause>> { > <<fields*.definition>> > <<constructors*.definition>> > <<methods*.definition>> > } > ''' I'm afraid I oversimplified the example ;-) def writeClass(Thing it) ''' <<visibility>> class <<name>> <<extendsClause>> { <<fields*.definition.delimitedPrint>> <<constructors*.definition.delimitedPrint>> <<methods*.definition.delimitedPrint>> } ''' You'd have to define an extension for lists that does the join stuff
OK, so «EXPAND .. FOREACH» would be syntactical sugar. But aren't the FOR and IF-constructs syntactical sugar as well? After all, you can replace them with uses of for() and if() as well, possibly after some restructuring of content into separate def's. What, then, are the criteria for allowing syntactical sugar in Xtend2?
(In reply to comment #7) > OK, so «EXPAND .. FOREACH» would be syntactical sugar. But aren't the FOR and > IF-constructs syntactical sugar as well? After all, you can replace them with > uses of for() and if() as well, possibly after some restructuring of content > into separate def's. What, then, are the criteria for allowing syntactical > sugar in Xtend2? IF and FOR contain expressions as children that are rich strings. The output-relevant part of the EXPAND sugar (which isn't really sugar since it is more verbose than the full syntax) is a plain feature call. In other words, the EXPAND keyword prepends the actual feature call which has to be present in any case. Btw, you could write <</*EXPAND*/ otherFunction()>> ;-)
Hah, noise not supported by the tool is syntactical sewage, not sugar ;) I guess in the end it's as much a matter of personal taste/style/preferences as something rational. In any case, the workarounds are quite obvious, so feel free to set this to "WON'T FIX".
See comment #5
