The Artima Developer Community
Sponsored Link

Java Buzz Forum
braindump("Java Properties are a faff")

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Jeremy Rayner

Posts: 111
Nickname: j6wbs
Registered: Sep, 2003

jez codes stuff
braindump("Java Properties are a faff") Posted: Oct 15, 2003 8:54 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Jeremy Rayner.
Original Post: braindump("Java Properties are a faff")
Feed Title: javanicus
Feed URL: http://www.javanicus.com/blog2/subjects/java-rss.xml
Feed Description: Jeremy Rayner on java and other stuff.
Latest Java Buzz Posts
Latest Java Buzz Posts by Jeremy Rayner
Latest Posts From javanicus

Advertisement
b>Problem: Standard JavaBean properties
this is currently a bit of a faff!! (I told you I was lazy)

private String foo;
 
public String getFoo() {
return foo;
}
 
public void setFoo(String foo) {
this.foo = foo;
}

Most of the time I want to code this in one line (Java Language change!) so the above would become the succinct:

String -rw foo;

How: implement as a pre-processor...
Why Not:
is this in xdoclet/groovy/ant regexp task/generic pre processor already?
No point creating non-standard language features
Maintainence burden increased as yet another oddity introduced to your codebase
'cos I'd be biled for being silly :)

What modifiers do I propose?

 nonegetsetget+set
private--r-w-rw
protected##r#w#rw
package**r*w*rw
public++r+w+rw

Why not try to create solution in Valid Java
try for valid java?

String foo-rw; --> private String foo
String foo*rw; --> public String foo // this is probably not valid
 
foo-rw += foo-rw; --> setFoo(getFoo() + getFoo()); // hard transformation...

invalid java?

String -rw foo;
String +rw foo;
 
foo += foo; --> setFoo(getFoo() + getFoo()); // hard ...
 
setFoo(getFoo() +getFoo()); // no transformation, but won't compile/editors barf...
Either way we still have issue with usage of getters/setters, so assume that the usage of getters/setters is outside scope of preprocessor, the choice is between which looks nice and which will not be highlighted as a problem in editors.

Additional issues

  • Collection properties
  • boolean properties
  • Could also indicate that property is parameter to constructor

Suggested Implementation

  • Implement a preprocessor that takes a single java file from a URI as input and a destination URI as output.
  • Wrap ant task around preprocessor that basically does :-

    <target name="compile" depends="init" >
    <!-- This is the new ant task being called -->
    <jpp include="${src.dir}/**/*.java"
    outputdirectory="${pre.processed.src.dir}"/>
     
    <javac srcdir="${pre.processed.src.dir}"
    destdir="${build.classes.dir}"
    classpathref="project.classpath"/>
    </target>

But really, why bother?
so that this sort of thing...

package com.foo.bar;
public class FooBar {
private String foo;
protected boolean bar;
 
public String getFoo() {
return foo;
}
 
public void setFoo(String foo) {
this.foo = foo;
}
 
public boolean isBar() {
return bar;
}
}
becomes the lazy but readable...
package com.foo.bar;
public class FooBar {
String -rw foo;
boolean #r bar;
}
foo property has private access, has a getter and setter
bar property has protected access, only has getter

Questions to the reader of this braindump...

What do you people think?
Has this been done already?

Read: braindump("Java Properties are a faff")

Topic: New J2ME News Stie Previous Topic   Next Topic Topic: Not Good Enough

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use