On Sun, 2005-09-11 at 10:16 +1000, Brett Porter wrote:
> [EMAIL PROTECTED] wrote:
>
> >+ /**
> >+ * @parameter property="foo"
> >+ */
> >+ private String fooValue;
> >
> >
> ...
>
> >+ public void setFoo( String fooValue )
> >+ {
> >+ this.fooValue = fooValue;
> >+ }
> >
> >
> Can you explain the reason for going with a property attribute and using
> methods that don't match the field name?
Strictly speaking properties don't have to correspond to fields, they
may involve a calculation say. I was just trying to account for that
case even though in the case of mojos the field name will most likely
match the the read/write method name.
> This means that they don't work
> under bean conventions (and IDE generation of getters/setters :)
That's just a convenience where the IDE uses the field name as the basis
for the read/write methods. But you may very well have a property where
the corresponding read/write methods use no fields, or use multiple
field values, or mutate a field value.
> I would have expected a simple:
>
> /** @parameter */
> private String foo;
>
> public void setFoo( String foo ) { this.foo = foo }
> public String getFoo() { return foo; }
Again, just trying to account for the case where this does not hold. I
wanted to be explicit about the name of the property when it didn't
match up exactly with field names. But if any tooling were to be made
you would want to provide the property name and you couldn't correctly
in cases where it varied from the field name.
Easy enough to change to as in the case above Plexus will simply attempt
to use the setter first.
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
