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