+1 on option 1 (contributor's vote...)
CloD ----- Original Message ----- From: "Marin� A. J�nsson" <[EMAIL PROTECTED]> To: "'Velocity Developers List'" <[EMAIL PROTECTED]> Sent: mercredi 15 octobre 2003 17:25 Subject: RE: [vote] remove static declarations from DateTool methods +1 on option no. 1 :) Marin� > -----Original Message----- > From: Nathan Bubna [mailto:[EMAIL PROTECTED] > Sent: 15. okt�ber 2003 06:01 > To: [EMAIL PROTECTED] > Subject: [vote] remove static declarations from DateTool methods > > > Ok, i've taken a little time this evening to look into Paul > Barry's enhancement request for DateTool (bugzilla #23622). > I feared that when i looked into ways to do this i would run > into issues with the static methods that needed solving > first, and sure enough, i was right... > > To me, DateTool is not meant to be a static utility class. > it ought to be an easily extendable tool for handling dates > in web applications that often need to adapt the locale and > timezone on a per-user or per-request basis. this would be > most elegantly handled by extending the class to > automatically garner from the session/request the locale and > timezone info needed. having to passing the locale and > timezone to the tool from the template with every > format() call--as would necessarily be the case with a static > utility--is definitely not elegant. > > so, with that said, it's time to admit that i did not think > so clearly on the matter when first designing and submitting > the tool, and i let a number of the methods be declared as > static. now i very much want to de-staticize those methods. > i see two options: > > 1. we just take the static declarations out. > > 2. we deprecate those methods, add non-static versions that > now have to have different names and/or signatures, and > eventually remove the static ones. > > let it be known that i despise option number two. if we go > with #2, that means lots of annoying template updating. if > we go with #1, all the templates still work, and only those > few (if any at all) that used those static methods in java > classes will have to do anything. > > frankly, i'd be surprised if anyone is using the static > methods statically in java classes (obviously they can't be > used statically in templates). i know standard practice for > something like this in a java API is deprecate and replace, > but these tools are really more of a velocity template API > than they are a java API. the easier route is IMNSHO, to > just take the static declarations out. > > i'd love to just do this unilaterally, but i think this one > is worthy of a vote. it's lazy consensus, so speak soon (by > next week at the latest) or forever hold your peace. > > p.s. i have some similar fears about this issue coming up > again with MathTool and RenderTool. so far i don't see the > static methods there as a problem, but that could change. thoughts? > > Nathan Bubna > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
