Closed GoogleCodeExporter closed 8 years ago
I'm not too sure about using parameter names for configuration. It's nice and
concise, but the data isn't available
reflectively (you need to use paranamer) and there's no JDK precedent of its
use.
Paul, you've got some experience with this. Any advice? Does use of parameter
names lead to happy
programmers?
Original comment by limpbizkit
on 24 Jun 2009 at 7:22
Much as I love parameter name leverage and how much of a no-brainer it is for
binding to web methods,
Gavin is not proposing parameter name leverage here. Field names are
retrievable via vanilla reflection, and
there's some redundancy between the actual field name versus the annotation's
mandatory value. I'm inclined
to agree that it should be optional for fields (while mandatory for param names
to ctors/methods), not that
we can code it to differentiate declaratively.
Paranamer can leverage debug tables, or post-compilation added (QDox/Asm) meta
info on classes. Its not
ideal obviously. Paranamer is OT for this JSR however much I'd like Sun to
allow parameter name leverage in
Java per se, it'll get vetoed when ever it is suggested I suspect.
Original comment by PaulHamm...@gmail.com
on 24 Jun 2009 at 10:55
Right, I'm not proposing that we support the defaulted version on
method/constructor
parameters *in this release*. If this problem is someday fixed in the JDK, we
can
also support it there. But for now what I'm talking about is field injection
and the
use of @Named to *declare* a bean name in 299.
Original comment by gavin.k...@gmail.com
on 24 Jun 2009 at 4:47
Strictly speaking, you can provide default values for annotation attributes,
but you
can't make them optional (i.e. you can't differentiate between not setting the
value
and explicitly setting the value to the default value). If we were to define a
default value, I don't think we should try to specify how injectors should
interpret
that value (we're short on time, and I can imagine interpreting it in different
ways
in different contexts). We would also want to pick a default value that doesn't
conflict with a value a user would likely use (maybe "").
That said, I prefer not to do this. I don't want to encourage use of string
identifiers. I don't like the inconsistency of being able to look up field but
not
parameter names. I also think users would be better of using purpose-built
annotations for this sort of thing. If a user is reading code with @Named in it
and
they click through to read the docs on @Named, the docs won't help them much
compared
to docs on a more specific annotation type that could explain how the default
name is
calculated and used in an expression language, for example. Of course, we could
always specify a default value later without breaking compatibility.
Original comment by crazybob...@gmail.com
on 24 Jun 2009 at 9:34
All the other specs (starting with JPA, and common annotations) are using "" as
the
default value, which is perfectly appropriate in this case, since it's not a
value
that the user would ever want to use.
We should do this, since it is what all the other specs are already doing, and I
don't want to have to deal with the complaints of users who don't like the
verbosity
of "@Inject @Named("foo") Foo foo". Trust me, they will complain.
Original comment by gavin.k...@gmail.com
on 24 Jun 2009 at 9:40
If we don't want to make this change, we should remove @Named from 330. I
continue to
think that this is the best solution.
Original comment by gavin.k...@gmail.com
on 24 Jun 2009 at 9:43
"I also think users would be better of using purpose-built annotations for this
sort
of thing. If a user is reading code with @Named in it and they click through to
read
the docs on @Named, the docs won't help them much compared to docs on a more
specific
annotation type that could explain how the default name is calculated and used
in an
expression language, for example."
Actually, given this comment, we should definitely go ahead and remove @Named
from
the spec. If @Named is not going to be a completely general-purpose solution,
and we
still envisage that other frameworks and applications will be defining their own
special versions of @Named, then @Named definitely doesn't belong in the spec.
I had been assuming that @Named was truly general-purpose and could subsume the
role
of the existing @Named annotation in 299 (which is used to specify or default
the
Unified EL name). Since that's not what is envisaged here, we should definitely
just
remove it.
As it is, it looks like 330 and 299 would each need to define their own @Named
annotation, one (in 330) as a qualifier, for use by people who don't like
typesafety,
and the other (in 299) for expressing that a bean (or all beans with a certain
stereotype) is accessible via Unified EL. That's horrible, can you imagine the
user
complaints about there being two different ways to give a name two a bean?!
What a mess!
Let's just ditch it.
Original comment by gavin.k...@gmail.com
on 24 Jun 2009 at 9:53
I think we certainly need to avoid having 2 distinct annotations
with "approximately" the same (apparent) semantics.
Also, since 299 has already used @Named, if we wanted to include a similar (but
different) annotation into 330, it cannot be named @Named.
I agree with Gavin that where defaulting can be introduced and redundancy
avoided
it should be, so I support the notion of
@Inject @Named Foo foo;
So can we agree on a single "naming" annotation that can be specificed (or not)
to
accomodate its usage as defined in 299 and its imagined uses in 330?
Original comment by Larry.Ca...@gmail.com
on 25 Jun 2009 at 3:39
I don't think we can ditch this annotation as that would inevitably lead to two
different but similar annotations -- exactly what people absolutely don't want
to
see.
Can we not just define it as:
@Qualifier
@Documented
@Retention(RUNTIME)
@interface Named {
String value() default "";
}
and say that when annotating a field, method, or type the default value will be
assumed to be the name of the respective field, method or type? In all other
cases
the value must be specified.
Original comment by michael....@gmail.com
on 25 Jun 2009 at 4:02
OK. We'll make "" the default.
Original comment by crazybob...@gmail.com
on 25 Jun 2009 at 7:00
Great, thanks :-)
Original comment by gavin.k...@gmail.com
on 25 Jun 2009 at 7:01
"" is the default value as of r6. The spec won't say anything about how an
injector
should interpret the default value. For the foreseeable future, Guice will treat
@Named like any other qualifier. This could change once parameter names become
more
readily available.
If these annotations ever make it into SE, maybe we could specify that parameter
names are always retained (and accessible at run time) when @Named is present.
Chances are this would appease the embedded folks who just want to minimize
class
file sizes.
Original comment by crazybob...@gmail.com
on 26 Jun 2009 at 11:14
I'm fine with "" as the default.
Original comment by johnsonr...@gmail.com
on 26 Jun 2009 at 11:19
Original issue reported on code.google.com by
gavin.k...@gmail.com
on 24 Jun 2009 at 1:32