On Mon, Feb 20, 2012 at 06:38:08PM -0600, Andrei Alexandrescu wrote: [...] > >We shouldn't be using Variant[string] for this, because there's > >another problem associated with it: suppose MyException sometimes > >gets "extra_info1" and "extra_info2" tacked onto it, on its way up > >the call stack, and sometimes not. Now what should the catcher do? > > Use a central loop to render the information.
Then it's useless for i18n, unless you can magically translate a sequence of unknown values into a different language in a consistent way. It sounds like all this is good for is to print a list of "name=value" pairs. Which is useful, I'll admit, for development/debugging purposes. I don't see how such a thing is useful in i18n. [...] > >This is what I mean by not being able to depend on whether some data > >is there. Ultimately, to do anything useful with the info in the > >object, you need to know what's there. > > No. You do realize you are positioning yourself straight against every > OO principle there is? The entire OO world is predicated on the > assumption you _can_ do useful stuff with an object WITHOUT knowing > what's there. And the way OO does this is by having the *derived classes* do useful stuff behind a polymorphic interface. What the Variant[string] does is, as you have said previously, to replace the need for many derived classes save a few, thereby throwing away the polymorphism and presenting what amounts to an array of void* to the catch block. For you to now accuse me of going against OO principles is a really strange argument, I must say. I was in fact *advocating* the use of OO by putting the useful information in the derived classes, where they belong. > >Preferably, the object's type will tell you exactly what's there, > >then you do a simple map from type to list of available attributes > >(e.g., map exception type to format string with known, static list of > >attributes). But if the type doesn't guarantee what data will be > >present, then your code becomes vastly more complex, you have to deal > >with potentially all possible combinations of what's there and what > >isn't. > > I think you are misunderstanding the mechanisms involved. There is no > combinatorial code, just simple iteration and such. Dealing with > distinct exceptions with distinct code IS combinatorial, repetitive, > and non-scalable. Then pray tell how "simple iteration" will achieve the translation of the data in Variant[string] into a localized string, when there is no guarantee any field will be in the hash at all. Format strings obviously won't work, since you can't have a format string unless you already know what arguments are present. Or are you just going to individually print out "name=value" pairs? In which case, we've been talking at cross purposes. There is no i18n here at all. T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
