[Mono-list] Resource System Proposal

[Guy Murphy]

[SNIP]

> The original .NET API's for internationalisation will be
> fully supported, and any programmer who wants to expend
> the effort of doing it the long way can do so.  But I believe
> that internally within our own libraries, we should be
> doing something better.

So, embrace and extend?

So many time when we here people dodging a spec we here "the old spec will
still be supported, what we're offering is just optional".... it reads no
better when you say it friend.

> I suggest that anyone who thinks that the .NET system
> is OK go off and write 250+ C# classes, complete with
> resources, using Microsoft's API's.  For added pain,
> do it yourself.  One person.  No one else helping you.

You're right, I'm not doing it and for that reason I can't mandate how it
should be done. As a hopeful user of the final product I can however give
you my opinions on what I will and wont use, and if I find people are using
a convention under Mono that doesn't compile under .NET I'll feel let down
especially over reducing a verbose term to a new keyword.

> I've done this with pnetlib: it is fully translation-ready,
> and 99.9999% written by me.  And it was a monumental
> pain to pull out all those resources and then write
> 'Environment.GetResourceString("tag")' for the 1000'th
> time.  I'd sell my soul for the "_" keyword about now. :-)

I vote we introduce "PRINT" to replace Console.Write(...) then.

> And that's *after* wrapping up the .NET API's in a way
> similar to Microsoft's method.  Try this on for size:
>
> (new ResourceManager
>     (Assembly.GetExecutingAssembly().Name,
>      Assembly.GetExecutingAssembly()))
>         .GetString("tag")
>
> That's what it would look like with no wrapping at all.
> The .NET API's are not convenient to use.  They are
> building blocks that need to be wrapped to be useful.
> I'd like to see them wrapped one way, and not 100's
> of different ways.

Hmm, as I mentioned before, the library is essentially a Microsoft library.
If you go at it with the intent of turning it into a Unix library then
you're going to wind up with something different... normally that's not a
big deal, it is however when the deal is supposed to be winding up with
something the same as.

It's a value judgement as to whether or not you like the verbose nature of
the library... I happen to like it, as it is explicit and clear, not obscure
and terse.... it is written that way for a reason. There is a product value
in the design of the library, it's not simply "MS suck at this", it's that
way on purpose. You might want to consider that purpose before you simply
decide it sucks and move off at a tangent.