The issue goes a little deeper than your simple use case though. The Java enterprise world, due to the lack of expression trees, has to work with many thousands lines of embedded DSL (JPQL/HQL/SQL etc.). This poses several problems:
- How do you format/indent it? - How do you copy-paste between database tool and IDE? - How do you get help with the syntax? By my experience, that is very much a real problem : " select new com.somecompany.somexp.backend.model.ManagerInfoRecord("+ " c, b.itemNo, x )" + " from SomeEntity x" + " Join x.account a" + " Join a.baseData b" + " Join b.customer c "+ " where x.state <> com.somecompany.somexp.backend.entities.SomeEntity $ReadingState.InValid " + " and ( " + " (" + " x.someState = com.somecompany.somexp.backend.entities.SomeEntity $someState.Valid " + " and b.someData <> 'Y' " + " )" + " or x.someOtherState = com.somecompany.somexp.backend.entities.SomeEntity $someOtherState.Valid " + " )" + " and b.relatedEntity =:relatedEntity " + " and x.someForeignRelation <> com.somecompany.somexp.backend.entities.SomeEntity$EntityStateEnum.E " ), And that's just one small annotation query (obfuscated to protect the innocent). Fun eh? :) /Casper On 2 Sep., 20:33, Jess Holle <je...@ptc.com> wrote: > Hmm... > > I've never really had an issue with simply doing > > "My string is really really really really really really really really > really " + > "really really really really really really really really really really > really really " + > "really really really long." > > The extra "'s and +'s are a non-problem in my book (IDE's help you with > them as well...) -- at least compared to the many /real /problems that I > encounter :-) > > -- > Jess Holle > > Reinier Zwitserloot wrote: > > No, A @DSL annotation isn't nearly enough to take care of arbitrary > > DSLing, or arbitrary literals. > > > For example, let's try to use this for multi-line: > > > @DSL(lang="longString") { > > """ I am a really really > > really long string. I'm also going to contain a bracket: } because > > I'm annoying like that.""" > > } > > > tell me how the compiler could possibly sort this out? The only way is > > for the compiler to hand off the entire process of TOKENIZING this > > stream to the DSL provider for 'longString', which is an entirely > > different architecture - right now all java parsers do the fairly > > usual thing of tokenizing the whole deal, then tree-izing the whole > > thing, and only then starting the process of resolving 'DSL' into > > "java.lang.DSL" or whatever you had in mind. > > > You'd have to create very specific rules about how the compiler can > > find the end of the DSL string. I've thought about this and have not > > been able to come up with a particularly sensible rule. The only one I > > can think of is to stick to C-esque rules: strings are things in > > double or single quotes, and use backslash internally for escapes, and > > braces are supposed to be matched. However, these restrictions already > > remove most other languages: You can't put python in there (multi-line > > strings will screw up java's parser), you can't put regular > > expressions in there (no rule enforcing matched quotes or braces). You > > can't put XML in there (no rule enforcing matched braces or quotes). > > No go. > > > On Sep 2, 4:40 am, Casper Bang <casper.b...@gmail.com> wrote: > > >> Don't know what happens underneath, but they appear to be parsed by > >> the production rule Block -> {Statement*} and have the Tree node > >> associated with a com.sun.tools.javac.code.Scope hashtable that's > >> special in that they can be nested. That would make sense I guess, > >> going the other way, a member-wide variable is also contained in a > >> Scope with nested Scopes (methods). That's why I think it would be > >> possible to allow an annotation type on a block. > > >> There are more things than just ARM you could want to do. > >> Transactions, logging, timing etc. As Stephen Colebourne has hinted at > >> in the past, one could even use it for DSL's: > > >> @DSL(lang="jpql", variant="hibernate"){ > >> SELECT FROM foobar; > > >> } > > >> That would take care of the need of multi-line strings for most cases. > > >> /Casper > > >> On 2 Sep., 03:12, Marcelo Fukushima <takesh...@gmail.com> wrote: > > >>> for local variables, javac actually does almost nothin:it only frees > >>> that local variable slot for a future local variable > > >>> theres a nice puzzle about that in the java specialists > >>> newsletter:http://www.javaspecialists.eu/archive/Issue173.html > > >>> of course youre not suppose to know its about local variables and > >>> javac before seeing the puzzle... > > >>> On Tue, Sep 1, 2009 at 9:44 PM, Mark Derricutt<m...@talios.com> wrote: > > >>>> I've always been intrigued by these blocks we have in java, what does > >>>> javac > >>>> actually generate for them? I'd always hoped that the closures proposals > >>>> might just start small and make these blocks a first class citizen. > >>>> From: > >>>> public void test() { > >>>> int foo = 1; > >>>> { > >>>> int bar = foo + 2; > >>>> } > >>>> //MARK > >>>> } > >>>> to: > >>>> public void test() { > >>>> int foo = 1; > >>>> Method foobar = { > >>>> int bar = foo + 2; > >>>> } > >>>> foobar.invoke(null); > >>>> //MARK > >>>> } > >>>> *sigh* I want my closures and mixins. > >>>> -- > >>>> Pull me down under... > > >>>> Sent from Auckland, Auk, New Zealand > > >>>> On Wed, Sep 2, 2009 at 5:47 AM, Reinier Zwitserloot <reini...@gmail.com> > >>>> wrote: > > >>>>> You can put { (statements) } anywhere in java code where a statement > >>>>> is legal. Like any other occurrence of {} to delimit code, any > >>>>> variable declarations inside the {} are not visible outside the > >>>>> brackets. So, this: > > >>> --http://mapsdev.blogspot.com/ > >>> Marcelo Takeshi Fukushima --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---