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 -~----------~----~----~----~------~----~------~--~---