What I was worried about were setPropertyHook() and
getPropertyHook()...
Maybe the java.text.Format comparison only applies to
the parsePropertyString() implementation of a given
PropertyHelper. So one PropertyHelper might use
something like it, but another--such as the default
one--would not. Because what good would it do, given
the structure of PropertyHelper, for the parsing
implementation to be constrained to a single approach?
What I think we have failed to see is that a
recursion-aware PropertyHelper differs from the
default PropertyHelper in two ways: it should
recognize the nesting of ${} structures in
parsePropertyString(), but it should also expand
nested properties in getProperty(), probably by
calling replaceProperties() on properties values prior
to returning.
-Matt
--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> > From: Matt Benson [mailto:[EMAIL PROTECTED]
> >
> > ....
> > I think you're basically right. And I remember
> having
> > wondered why java.text.Format was implemented that
> > way; now I know...
> >
> > > Such strategy would allow writing property
> > > evaluators that contain real
> > > complex expressions inside. Which we have
> discussed
> > > in the past.
> > >
> > > Anything else, I think it will be just like a
> hack
> > > that will break
> > > something else.
> > [SNIP]
> >
> > I wouldn't take quite so extreme a position as
> that,
> > but I agree that emulating j.t.Format is probably
> the
> > "most correct" approach. But our old buddy B.C.
> might
> > not allow it...
>
> Well, modifying the API of PropertyHelper may not be
> too risky.
>
> If what we are changing if the implementation of
> replaceProperties()
> keeping the same parameters. Then we should be 95%
> there.
>
> The actual change is to add a method to
> PropertyHelper where you
> use a kind of parseObject/format API from
> java.text.Format.
> The default implementation will just collect to the
> next '}'
> and pass to the current calls to get the value. But
> this may be overridden to provide an implementation
> of PropertyHelper
> that reads as much as it wants and decides on which
> '}' to stop.
>
> So an expression evaluator for properties could
> count '{}' and
> pick the segment it wants and then evaluate the
> whole thing at once.
>
> Not sure of the details, but I think we can make it
> BC friendly.
>
> Comments, ideas ....
>
> Jose Alberto
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
