"Nick Sabalausky" <a at a.a> wrote in message
news:jhu7kj$1mae$1 at digitalmars.com...
> "Nick Sabalausky" <a at a.a> wrote in message
> news:jhu61p$1jpm$1 at digitalmars.com...>> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
>> news:jhtss8$12mq$3 at digitalmars.com...>>> On 2/20/12 10:16 AM, Nick Sabalausky wrote:
>>>> "Andrei Alexandrescu"<SeeWebsiteForEmail at erdani.org> wrote in message
>>>> news:jhtq31$u8q$1 at digitalmars.com...>>>>>>>>>> Again, I think this thread clarified we need the "Variant[string]
>>>>> info;"
>>>>> member however we define the hierarchy.
>>>>>>>>>>>>> I disagree. I don't see a need for that.
>>>>>> How would we address custom formatting of e.g. error messages?
>>>>>>> Maybe I've misunderstood your intent for this "Variant[string] info;" My
>> understanding is that, for example, you want to replace this:
>>>> ----------------------------------------------------
>> class Exception {}
>> class FooException
>> {
>> string fooName;
>> int fooID;
>> bool didBarOccur;
>>>> this(string fooName, int fooID, bool didBarOccur)
>> {
>> this.fooName = fooName;
>> this.fooID= fooID;
>> this.didBarOccur= didBarOccur;
>> }
>> }
>> ----------------------------------------------------
>>>> With this:
>>>> ----------------------------------------------------
>> class Exception
>> {
>> Variant[string] info;
>> }
>> class FooException
>> {
>> string fooName;
>> int fooID;
>> bool didBarOccur;
>>>> this(string fooName, int fooID, bool didBarOccur)
>> {
>> this.fooName = fooName;
>> this.fooID= fooID;
>> this.didBarOccur= didBarOccur;
>>>> info["fooName"] = fooName;
>> info["fooID"] = fooID;
>> info["didBarOccur"] = didBarOccur;
>> }
>> }
>> ----------------------------------------------------
>>>> If so, then I don't see any usefulness of "Variant[string] info" other
>> than to start treating exceptions like JS's abomination of an "object"
>> (Or at least AS2's objects anyway - not 100% certain how much of AS2 is
>> taken from JS). If not, then could you clarify what you meant?
>>>> In either case, I am interested to hear in more detail how you see
>> "Variant[string] info" being used to address i18n. I haven't really dealt
>> with a lot of i18n myself.
>>>> Ok, I just saw your explanation here:
>http://forum.dlang.org/post/jhu1hk$1cb8$1@digitalmars.com>> And, IIUC, I assume that inside "stringTemplate()", you'd then access some
> table that roughly amounts to (yea, I know we don't have 2D AAs):
>> string[string, Locale] i18nTable;
> i18nTable["FileNotFoundExcepton", English] = "File ${filename} not found";
>> Then stringTemplate() would look that up, find the string "File
> ${filename} not found" and essentially do:
>> return "File "~e.info("filename")~" not found";
>> Although obviously not hardcoded like that.
>> Is that right?
>> In that case, I like the general idea, *but* why not just use reflection
> to access the members instead of essentially creating a JS-style "class"
> with AAs? That way we don't have to either A. throw away the benefits that
> class members have over AAs or B. violate DRY by duplicating field members
> in an AA.
>
Using reflection instead of "Variant[string] info" has another benefit: It
allows the i18n table to *automatically* support any type, not just
Exceptions. By contrast, with "Variant[string] info", a member has to be
explicity (or via inheritance) added to every type that the i18n table wants
to handle. So you're actally *creating* unnecessary cupling with i18n by
using "Variant[string] info". If you replace "Variant[string] info" with
reflection, then you've *completely* factored out i18n.
Admittedly, if the i18n engine populates its tables at runtime, then the
reflection would have to be runtime reflection, and I don't know offhand if
we currently have that particular form of runtime reflection yet or not. But
if not, then this is a good use-case for why it should get implemented
sooner or later.