RE: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types E numeratedAttribute.java

[Stephane Bailliez <sb...@imediation.com>]

> -----Original Message-----
> From: Magesh Umasankar [mailto:umagesh@apache.org]

> From: <sb...@apache.org>
> 
> >        /**
> >   +     * the index of the selected value in the array.
> >   +     */
> >   +    protected int index;
> 
> IMHO, wouldn't it be tighter if you mark this private 
> and provide a "protected final int getIndex()" method?
> This way it is ensured that EnumeratedAttribute has
> control over the value of the index variable.

Probably.
If we decide to go this way then we have to state explicitely in the coding
guidelines.

I'm not a huge fan of protected attributes because I feel like they are
getting out of nowhere when using it in a method and it is more explicit to
me to user getters. The counterpart is that it force us to create accessors
everywhere and this is quickly becoming code bloat when not needed. I feel
like accessors instead of protected are more necessary when there is a
potential of having a large number of subclasses or a very deep hierarchy.

All in all this is a little bit like overdesigning, you have some optional
tasks that have getter/setter for all private attributes and the code is
more than twice the size of what it could be.

-- 
 Stéphane Bailliez 
 Software Engineer, Paris - France 
 iMediation - http://www.imediation.com 
 Disclaimer: All the opinions expressed above are mine and not those from my
company. 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types E numeratedAttribute.java

[Peter Donald <pe...@apache.org>]

On Mon, 7 Jan 2002 20:12, Stephane Bailliez wrote:
> > -----Original Message-----
> > From: Magesh Umasankar [mailto:umagesh@apache.org]
> >
> > From: <sb...@apache.org>
> >
> > >        /**
> > >   +     * the index of the selected value in the array.
> > >   +     */
> > >   +    protected int index;
> >
> > IMHO, wouldn't it be tighter if you mark this private
> > and provide a "protected final int getIndex()" method?
> > This way it is ensured that EnumeratedAttribute has
> > control over the value of the index variable.
>
> Probably.
> If we decide to go this way then we have to state explicitely in the coding
> guidelines.

Not probably - definetly. We should make methods/variables as private and 
final as possible to make evolution easier. You can never remove access once 
something is released but you can always open up things later if need be.

> I'm not a huge fan of protected attributes because I feel like they are
> getting out of nowhere when using it in a method and it is more explicit to
> me to user getters. The counterpart is that it force us to create accessors
> everywhere and this is quickly becoming code bloat when not needed. I feel
> like accessors instead of protected are more necessary when there is a
> potential of having a large number of subclasses or a very deep hierarchy.

Large number of subclasses or deep hierarchies are considered harmful by 
some people ;)

> All in all this is a little bit like overdesigning, you have some optional
> tasks that have getter/setter for all private attributes and the code is
> more than twice the size of what it could be.

Much easier to evolve those tasks though and much easier to maintain. In most 
cases you can disregard the getters because very few of them actually get 
used anywhere and the setters are part of the Ant patterns so I am not sure 
how you would propose to avoid them ?

-- 
Cheers,

Pete

---------------------------------------------
 We shall not cease from exploration, and the 
  end of all our exploring will be to arrive 
 where we started and know the place for the 
        first time -- T.S. Eliot
---------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>