[OT] Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)

[Dave Newton <ne...@yahoo.com>]

Robert Graf-Waczenski wrote:
> And, to tell the truth, our choice to use "getmProperty()" as
> accessor method naming pattern was a bad one originally but we lived 
> with it since the beginning and are now being bitten in the behind :-)

That about sums it up, I think.

I'm assuming the naming convention "mProperty" is designed to increase 
internal readability by showing that the property is an instance 
variable. Using the "m" convention in the getters/setters then 
propagates implementation details to the outside world, which defeats 
the purpose of getters and setters.

Folks that use an underscore convention ("_property") would name the 
getter "getProperty", not "get_Property" or "get_property".

Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)

[Robert Graf-Waczenski <rg...@lsoft.com>]

Dave Newton schrieb:
> Robert Graf-Waczenski wrote:
>> And, to tell the truth, our choice to use "getmProperty()" as
>> accessor method naming pattern was a bad one originally but we lived 
>> with it since the beginning and are now being bitten in the behind :-)
>
> That about sums it up, I think.
>
> I'm assuming the naming convention "mProperty" is designed to increase 
> internal readability by showing that the property is an instance 
> variable. Using the "m" convention in the getters/setters then 
> propagates implementation details to the outside world, which defeats 
> the purpose of getters and setters.
>

There's a bit more to the "m" than meets the eye. This is a legacy 
application designed for the Struts1 MVC form/model pattern with library 
code that transfers bean object properties to model object properties 
and vice versa. Now, since our form classes have far more methods that 
are only needed for the controller part of the application, we designed 
our bean<->model transfer code around the presence of the "m" in the 
getter/setter method name (to avoid accessing controller-only getters 
and model utility methods). So even though your point about 
implementation detail propagation still stands, it is exactly this 
implementation detail that our application needs internally. Nowadays, 
of course, you would do the same thing much more elegantly with 
annotations, but back then, there were no annotations :-(

Robert


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)

[Robert Graf-Waczenski <rg...@lsoft.com>]

I agree to your observation, Dave. Point well made. I would like to get 
a comment from you about my claim about backwards incompatibility, though.

Robert

Dave Newton schrieb:
> Robert Graf-Waczenski wrote:
>> And, to tell the truth, our choice to use "getmProperty()" as
>> accessor method naming pattern was a bad one originally but we lived 
>> with it since the beginning and are now being bitten in the behind :-)
>
> That about sums it up, I think.
>
> I'm assuming the naming convention "mProperty" is designed to increase 
> internal readability by showing that the property is an instance 
> variable. Using the "m" convention in the getters/setters then 
> propagates implementation details to the outside world, which defeats 
> the purpose of getters and setters.
>
> Folks that use an underscore convention ("_property") would name the 
> getter "getProperty", not "get_Property" or "get_property".
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org