Jon Stevens wrote:
>
> on 2/26/01 1:53 PM, "John McNally" <[EMAIL PROTECTED]> wrote:
>
> > Is this only considered acceptable for String constants?
>
> Yes IMHO. Also, in this case, it is patching code that is used within
> Turbine only...therefore, it should be done right.
>
> > FooPeer.COLUMN -> FooPeer.COLUMN.toString()
>
> Yucky. More typing.
When have you ever used these constants in a way that required that they
be Strings? I see no reason why anyone would ever have to use the above
method outside torque generated code. I think saving multiple string
parsing operations per request with no additional difficulty in coding
is a win all the way around.
Advantages
1. table and column strings become canonical-like resulting in less
gc. In our current system, we generate two or more Strings every time
we add a value to a Criteria.
2. In our current system we generate these two strings by parsing the
same string over and over, this can be eliminated.
3. In cases where we are calling s1.equals(s2), due to creating a new
String each time, we could be doing s1.equals(s1) which should be much
faster as the == check should short circuit having to check the entire
Strings.
4. All this is possible without breaking any current apps.
Disadvantages
Using a public attribute to refer to a contant object that consists of a
couple Strings, instead of a public attribute to refer to a constant
object that consists of one String.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
