[haiku-commits] Re: haiku: hrev47971 - in src: tests/kits/locale servers/mail kits/tracker add-ons/mail_daemon/inbound_filters/notifier kits/locale
- From: Paweł Dziepak <pdziepak@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 7 Oct 2014 14:51:34 +0200
2014-10-07 14:28 GMT+02:00 pulkomandy <pulkomandy@xxxxxxxxxxxxx>:
> On Tue, Oct 07, 2014 at 01:43:32PM +0200, Axel Dörfler wrote:
> > >There is still room for improvement in the BMessageFormat API, however:
> > >- Only one int32 argument can be used. This rules out some complex uses
> > > like formatting depending on both the gender and number, formatting
> > > floating point numbers, etc.
> >
> > I must admit that I missed that. I think the only way to make this work
> is
> > by exposing a similar class than Formattable. Unfortunately, this will
> > create quite some overhead translating between those classes which is
> really
> > suboptimal. Maybe have a BFormattable class that stores its data binary
> > compatible to ICUs can work.
>
> I would prefer to avoid this. ICU provides no stable ABI, so the class
> layout may change accross versions. We have taken care to not expose any
> of the ICU ABI in the Locale Kit to avoid binary compatibility issues.
>
> Formattable is a relatively simple class (essentially an union of
> various primitive types) and it doesn't look like it would be too
> costly to costruct instances on demand. Also note that Formattable
> stores data for only one argument, and you actually need an array of
> them if the message has multiple arguments.
>
> > You could then have a version of Format() that takes a single argument
> > "const BFormattable&" so that the compiler can create this on-the-fly.
> > You could also have a version that takes ... and creates an Formattable
> > array from that.
>
> These are on the TODO list already.
>
> > Finally, you could introduce a BNamedFormattable class that contains the
> > name of the arguments as well -- this class would always have to be
> > transformed for ICU's usage, though (I don't really like how ICU handles
> > named arguments, in any way).
> > Another alternative would be to alternate between name and argument:
> > Format(buffer, "name0", arg0, "name1", arg1, ...);
> >
> > Your BMessageFormat has a few API issues beyond that:
> > - Format() should be static
>
> It relies on the language (fLanguage field of BFormat) to parse the
> plural rules properly (they are language dependant). A static version
> would either take an explicit BLanguage as a parameter, or use the
> default one, by calling the static version of MessageFormat::format.
>
> But having a way to format messages in another language may still be
> useful.
>
> > - You should add a non-static version and a constructor that can preparse
> > the pattern. This will speed up the use case of applying the same pattern
> > over and over again.
>
> Indeed.
>
> > - "const" for by-value arguments is meaningless.
>
> It's not very useful, but still not completely meaningless:
>
> ~> cat foo.c
> int main(const int argc)
> {
> argc++;
> return 0;
> }
> ~> gcc-x86 foo.c
> foo.c: In function 'main':
> foo.c:3:2: error: increment of read-only parameter 'argc'
> argc++;
> ^
>
I don't see much point in doing something like this.
This information can be used by the compiler to inline the function
> without needing to make a copy of the parameters, for example.
>
Compiler won't copy the parameters if it decides that it is not needed
regardless of whether parameter is const or not. Making code look strange
doesn't help optimization in this case.
>
> > >One possible solution is to store all the arguments in a BMessage, so
> > >they can be referred by name. We can then convert the message into an
> > >icu Formattable array (or make a wrapper FormattableMessage) to access
> > >the message contents. It would work approximately like this:
> >
> > That might be a nice extra option, but it's too slow and complicated to
> > represent the default usage.
>
> I think the var-arg (with unnamed args) version would be good enough for
> most cases, and the BMessage based one would complete it for places
> where named arguments are needed. Wouldn't BNamedFormattable end up
> being rather similar to BMessage anyway, as it needs to store the name,
> type and value of elements?
>
> --
> Adrien.
>
>
Other related posts:
