"Nick Sabalausky" <[email protected]> wrote in message news:[email protected]... > "Nick Sabalausky" <[email protected]> wrote in message > news:[email protected]... >> "Andrei Alexandrescu" <[email protected]> wrote in message >> news:[email protected]... >>> On 2/20/12 10:16 AM, Nick Sabalausky wrote: >>>> "Andrei Alexandrescu"<[email protected]> wrote in message >>>> news:[email protected]... >>>>> >>>>> 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/[email protected] > > 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.
