PROPOSAL: Named method parameters

[Howard Lovatt]

Hi Paul,
I am working on including annotations, but there are a few problem with
annotations in this context at the moment. Namely if I annotate an
interface, then a class that implements that interface does not get the
annotation even if the annotation is annotated as
Inherited<http://java.sun.com/javase/6/docs/api/java/lang/annotation/Inherited.html>.
I think there was discussion of this problem as part of JSR 308, but I am
unsure how far a solution progressed. A second problem, less serious if the
first was fixed, is that you can't add a method to an annotation, so for
example with Immutable Value
Conversions<http://pec.dev.java.net/nonav/compile/javadoc/pec/compile/immutable/ImmutableValueConversions.html>
I
want standardly named conversion methods but with annotations you can't do
this. Thirdly it is generally frowned upon to use Annotations to
change behavior, with the advice to use a marker interface (e.g.
Serialization).

As a result I currently plan to use a mixture of annotations and interfaces.

 -- Howard.

2009/4/25 Paul Martin <paul.martin at gmail.com>

> Hi,
>
> Thanks for your suggestions.
>
> PEC does seem interesting, and seems to be covering a different space
> to that covered by analysis tools such as Findbugs (that I am familiar
> with).  I'll take a closer look.  Will you extend it to include
> support for the @Immutable (and similar) annotations that are
> hopefully coming with Java7?
>
> Simple structures are a reasonable alternative to named parameters,
> particularly based on your assumption that "you would only use this if
> there were a lot of arguments", which would not be the common case.
> Other than the (slightly) more complex syntax, the only real
> disadvantage that I can see is:
> - It is hard to ensure that all of the fields are explicitly set (to
> avoid errors where we forget to set a value, or refactor to add a
> field and then forget to update a caller)
>
> However, this does seem to be solvable using static analysis tools
> such as Findbugs (or PEC?), particularly if there is an annotation
> such as @SubclassMustSet on the class or each required field, which
> could indicate that such checks are required.  Tools such as Spring
> should be able to use simple structures directly (and maybe additional
> support could simplify their use).  Maybe I'll give that a go.
>
> I still think that adding support for named parameters to Java would
> be worthwhile (both because the intention is perhaps clearer, and they
> may be even more valuable in other JVM languages), and don't think
> that it necessarily has to be too contentious to implement them.
>
> Regards,
>
> Paul
>
>
> On Wed, Apr 22, 2009 at 1:52 AM,  <howard.lovatt at gmail.com> wrote:
> > I use the builder pattern successfully via my enhanced compiler ( pet
> > project :) ):
> >
> > https://pec.dev.java.net/nonav/compile/index.html
> >
> > and in particular:
> >
> >
> https://pec.dev.java.net/nonav/compile/javadoc/pec/compile/immutable/ImmutableValueConversions.html
> >
> > The enhanced compiler enforces the pattern, ie if you get it wrong the
> > compiler gives you an error message.
> >
> > You can also use a simple structure like class, eg:
> >
> > class Point {
> >
> > static class Args {
> > int x = 0;
> > int y = 0;
> > }
> >
> > final int x;
> >
> > final iny y;
> >
> > Point( Args args ) {
> > x = args.x;
> > y = args.y;
> > }
> >
> > ...
> >
> > }
> >
> > Which is used like:
> >
> > Point p = new Point( new Point.Args() {{ x = 1; }} );
> >
> > As the original post said you would only use this if there were a lot of
> > arguments, therefore the overhead of typing "new Point.Args() {{ }}" is
> > negligible.
> >
> > -- Howard.
> >
> >
>



-- 
 -- Howard.