PROPOSAL: Named method parameters

[paul.martin at gmail.com]

Hi,

That all sounds sensible. It would be good to integrate with JSR 308, but  
your idea of using standard methods to highlight the design pattern sounds  
nice and would need an interface.

Regards,

Paul

On Apr 26, 2009 2:59am, Howard Lovatt <howard.lovatt at iee.org> wrote:
> 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. 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 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 (eg 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.