[Mono-list] Resource System Proposal

[Rhys Weatherley]

There's been some good discussion on this.  I'll summarise
the viewpoints so far:

- Don't change the spec.
- Clear keywords with ECMA first.
- Keyword is nice, but use it for other things too.
- Tags are better than literal strings.
- Could use delegates or properties instead of "using".
- Use the "OpenSystem" namespace instead of "System"
   for classes that go beyond the ECMA specs, but are
   designed to be reusable across platforms.
- Use the runtime engine to do the work with "ldstr".

There seems to be a lot of resistance to the new keyword,
which is understandable.  This document isn't necessarily
saying that we should do this.  It is offering it up as an
alternative.  Nothing is set in stone yet.  For myself, some
days I like it, and other days I don't.  I'm not attached to it.
It would be nice to get some feedback from ECMA members
on what they think of it.  Would it be likely to be adopted?

The thing I want to get rid of most of all is the Microsoft
approach of "every assembly must do its own thing".  We
need a simple API that everyone can use the same way
in all of our libraries.  The keyword is just a way to make
this API as painless as possible.  Transition strategies
are possible.  e.g. defining a "_" method in "System.Object".

Using the keyword for other types of resources is likely
to get confusing.  However, there are plenty of places in
"System.I18N" where other methods can be placed to
do other things.  e.g. "GetBitmap" may be a useful thing
to have to get translatable bitmaps.

Tags vs strings: the same proposal works if tags are
used, with the caveat that a human must do the work
of extracting the strings into a separate resource file.
As some real-world experience, Portable.NET
currently uses tags, and it is getting to be a bit of
a pain to keep the source and the resource files up
to date in parallel.

I'm not sure I like the delegate idea.  It's a neat trick, but
requires an object in every class that uses resources.
Since almost every class in the C# library throws an
exception with a translated error message at some point,
the overhead could get exorbitant.

There are also threading issues involved with delegates:
how do I ensure that the delegates are created in a
thread-safe manner, given that every class must deal
with the locking issues independently now?  More
code means more chance for operator error.

I like the "OpenSystem" idea, but hate the runtime engine
idea.  There's no way for the runtime engine to know if
the string is legitimately translatable, or is just a literal
in some protocol.  The last thing you want is for the
engine to decide to translate "http://" into a foreign
language and screw up your Web code.

Well, that's my 2 cents worth.  I'll keep watching to see
if a new approach or some kind of consensus emerges
and then update the document accordingly.

Cheers,

Rhys.