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 <[email protected]> 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 <[email protected]> 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<[email protected]> 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 <[email protected]>
>>>> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
