Parameter annotations
Robert Munteanu
Right now parameters are declared in the form
String in1username;
I think it would be clearer to declare them with annotations such as
@In(1) or @In(order=1)
Robert
--
Sent from my (old) computer
Stephen Haberman
> I think it would be clearer to declare them with annotations such as
Huh. I hadn't thought of that at all. I am normally not a huge fan of
annotations (APT aside, of course) but this sounds pretty cool.
- Stephen
brendan
Before
@GenEvent
public class FooChangedEventSpec {
Foo p1foo;
boolean p2originator;
}
After
@GenEvent
public class FooChangedEventSpec {
@Param(1) Foo foo;
@Param(2) boolean originator;
Robert Munteanu
@In(1) and @In(order=1)
Thoughts?
--
Stephen Haberman
> Yes, something like this sounds good to me. I have no preference
> though between
>
> @In(1) and @In(order=1)
>
> Thoughts?
I have a slight preference for `@In(1)` merely because its shorter.
Brendan, I saw you mention on the gwtp list that you had this
working--would you like to fork the project on github and submit a
patch/pull request back to gwt-mpv-apt?
Thanks!
- Stephen
brendan
For the changes I'm proposing to gwtp, I took the great concept you
came up with and wrote the code from scratch - as I couldn't figure
out how your code worked :) Because it's a totally different code
base, I'm not sure if forking your project makes sense. Also, I don't
know how to use git.
I still have a couple more features to add before I submit the code
review, but I'll post a link to the code review here so you take
anything you like.
You can see what I've done so far by following the links from
http://code.google.com/p/gwt-platform/issues/detail?id=144
The trick to having something a default value like @In(1), is just to
call the default value "value()". As shown below.
@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
public @interface In {
int value();
}
Brendan
Stephen Haberman
> I took the great concept you came up with and wrote the code from
> scratch - as I couldn't figure out how your code worked :)
Hehe, fair enough.
I read through your concerns on the gwtp issues/list--all valid,
though I'll note that both joist-util and apt-util are actually
released (e.g. [1]), the Ivy "latest.integration" rev is not
like Maven's SNAPSHOT--it means a real version, just that you're
not particular about which one it is. Also, what may initially
seem simpler (printlns/etc.) does not necessarily scale with
complexity. E.g. when you get to handling generics, etc.
> Because it's a totally different code base, I'm not sure if forking
> your project makes sense.
I agree. :-)
> I still have a couple more features to add before I submit the code
> review, but I'll post a link to the code review here so you take
> anything you like.
Sounds good to me.
Out of curiosity, was there a reason you used the old `com.sun` API vs.
the `javax.lang.model` API?
For what it's worth, I added the annotations and addressed any other
potential shortcomings (package name change, static `fire` method) with
gwt-platform usage. Whether you continue with your fork or not, I'd be
interested to know whether the latest gwt-mpv-apt release works with
gwt-platform. But if you're busy with other things, that is fine too.
- Stephen
brendan
Do you think it's important to use the javax.lang.model instead.
It seems more complicated, with less obvious names - like the field
declaration called VariableElement instead of FieldDeclaration.
I've just run into an interesting problem tonight.
I have a "create" action that takes an array of people, each person
having a firstName, a middle name and a lastName.
Once the action has been handled, I'll have some People object
(persisted in the database) linked to
the object I'm creating.
I could of had parallel arrays on my create action for each of the 3
names, but I thought was kind of ugly. Instead
I created another annotation, @GenDto, that creates a dto for
transfering data from the client to the server in actions.
Does the auto generation of constructor, accessors, equals and
hashCode.
@GenDispatch
class CreateXXX {
@In(1) String name;
@In(2) String address;
@In(3) PersonName[] names;
}
@GenDto
class PersonName {
@Order(1) String firstName;
@Order(2) String middleName;
@Order(3) String lastName;
}
What do you think? Alternate suggestions?
Stephen Haberman
> Do you think it's important to use the javax.lang.model instead.
Not sure. Here is what I do know:
* APT was originally released with JDK 1.5 as a separate command line
tool (called `apt`) that you could explicitly invoke before (I think)
`javac`. It used the `com.sun` APIs.
* For JDK 1.6, the separate `apt` tool was killed and instead the
functionality was built directly into `javac`--at this point, the APIs
were a JSR and so are the `javax.lang` stuff.
Sun is likely still supporting the `com.sun` APIs, as likely does
Eclipse given it has had both 1.5-APT and 1.6-APT support.
So if it works, great, it works. I just don't know going forward how
much longer the non-JSR APIs would work across tools/IDEs.
> It seems more complicated, with less obvious names - like the field
> declaration called VariableElement instead of FieldDeclaration.
Agreed.
> @GenDto
> class PersonName {
> @Order(1) String firstName;
> @Order(2) String middleName;
> @Order(3) String lastName;
> }
>
> What do you think? Alternate suggestions?
I think that is a good idea. I've had intentions to do something similar
but never went through with it. A `@GenDto` works well for pure DTOs,
but starts to tricky if you want to also add some custom methods, which
is what always stopped me before.
Also, my DTOs typically just have public fields, as I don't think the
getter/setter convention is worth following for such simple data
structures. Well, and I haven't needed equals/hashCode.
- Stephen