My vote would also be for Zend_Measure::MILLIMETER. In most cases that I've 
seen, all measurements are part of the same namespace.
There's no reason IMO to divided them up (yeah I know some or weights, lenghts, 
etc.. but it's really just a PITA to do the divison
and there's really no gain).

Andi 

> -----Original Message-----
> From: Gavin Vess [mailto:[EMAIL PROTECTED] 
> Sent: Monday, January 22, 2007 11:44 AM
> To: Thomas Weidner
> Cc: [email protected]; ZF I18n
> Subject: Re: [fw-general] Zend_Measure constants wrong?
> 
> Moving discussion to [EMAIL PROTECTED]
> 
> One of the goals we've publicly stated involves supporting 
> tools, and features like auto-completion.  Most tools provide 
> "smoother" support for the use of constants as arguments than 
> strings as arguments.  The original expectation was that 
> Zend_Measure classes would continue to support something like either:
> 
> 1) Userland must first require the correct measurement class:
> 
> $unit = new Zend_Measure('1.000', 
> Zend_Measure_Length::MILLIMETER, 'de');
> 
> 2) Zend_Measure can auto-include the correct measure class:
> 
> $unit = new Zend_Measure('1.000', 
> Zend_Measure::LENGTH_MILLIMETER, 'de');
> 
> 3) Same as #2, but shorter:
> 
> $unit = new Zend_Measure('1.000', Zend_Measure::MILLIMETER, 
> 'de'); // my favorite (less typing for those of us without 
> auto-completion)
> 
> Does anyone have a preference?
> I can see multiple ways to accomplish something like the 
> above, without making the constants contain lengthy 
> repetitive information. 
> 
>  > Already cored classes can not be changed by anyone without 
> a group/devteam decission.
> 
> No.  It depends on the scope, nature, and depth of the 
> change.  Some changes involve only implementation details, 
> and often Jira issues are sufficient.  Other changes involve 
> design and might benefit from community discussion (e.g. the 
> controller and rewrite router have benefited greatly from 
> such discussions on the mail lists).  Other changes are 
> simply standards compliance changes, and need little or no 
> discussion, while some changes substantially impact API and 
> need both discussion and revision to the proposal and documentation.
> 
> http://framework.zend.com/wiki/x/Rh8
> 
> Cheers,
> Gavin
> 
> Thomas Weidner wrote:
> > Hy,
> >
> >> Well it's not working like thiis. It will only accept 
> constants from 
> >> Zend_Measure it's self, none of the constants of it's measure 
> >> libraries work, at least not in Zend_Meaure. I think this 
> needs to be reworked.
> >
> > I throwed this in to the devteam... waiting for their response...
> > Already cored classes can not be changed by anyone without a 
> > group/devteam decission.
> >
> >> Btw
> >> would it be possible to add custom measure classes?
> >
> > Which unit / measurement type do you miss ?
> > Actually we saw no need to add custom classes, as all 
> worldwide known 
> > unit types are supported and should be avaiable to everyone 
> :-) If you 
> > write me the units you miss I can add them to be supported.
> >
> > And if you are in need, you can easily extend Zend_Measure yourself.
> >
> > Greetings
> > Thomas
> > (I18N Team Leader)
> 

Reply via email to