On Sun, Sep 25, 2005 at 23:54:56 -0700, Ashley Winters wrote: > Localization occurs here. Formatting occurs here. > Timezone/newline-convention/join-character-specification/whatever > happens here
This is going too far, IMHO.
What if your app is running in some time zone, generating reports
for an office 2 time zones away? What if you are exporting the
reports into a serialized formats, but the user needs to input the
time zone info in their -2 time zone?
What if your interface is demonstrating localization... Do you do
for <<language other_language>> -> $ENV{LANG} {
display("$the_object");
}
If this becomes to DWIMMY and implicit, presentation will get
unstable.
The interfaces to these concepts are too complex, and because we
can't refactor reality or culture (swatch tried it, but no one
understands .beat... Esperanto is not the de facto language, in fact
the last time I checked my internationalization system settings give
me much more than 1 choice, wrt date formatting, input mode, spell
checking, and UI display). I think that there is no way to get away
with simplifying this.
These things should be easy:
Say what you generally want for a certain section of a program
(could be the whole program)
Get that behavior implicitly in a certain section (all
interpolations are localized in this block)
Make exceptions (don't localize, except for this string)
Have fine grained control that does not break encapsulation or
interfere with other code (localization is yadda yadda, but date
formatting is ISO).
The environment variable interface that we use on UNIX nowadays is
not enough for the age of web applications, collaboration software,
and stuff like that.
The cross cutting concerns of display are so deep and spaghettied
that we simply cannot and should not support these in the language
implicitly. It's too dangerous, and will cause too many headaches.
Much like debugging is more complicated than just printing, I think
that localization is done with a role that helps the view code
display localized versions of objects instead of providing localized
strings for the view code.
What I definately won't mind is a module that exports a lexical
&*prefix:<~> (and thus otherwise augments interpolation) so that any
stringification in a certain block of code is localized.
Then I would have one such block per program (not module or
anything) that makes an attempt at doing this.
> Serialization: my Thingy $obj.=thaw($object.freeze)
Part of the Serializable role, i guess, which can be implemented
with any serialization module that works well for $obj.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me groks YAML like the grasshopper: neeyah!!!!!!
pgptJDAv5nBQx.pgp
Description: PGP signature
