Subject: RE: why properties are strings instead of enums
From: WJCarpenter (bill-abisource@carpenter.ORG)
Date: Tue Jan 23 2001 - 20:07:31 CST
paul> By contrast, if we introduced a translation layer to enums (or
paul> whatever), I'm not sure that the gains would be all that
paul> worthwhile. It introduces a level of API complexity which just
paul> feels wrong. Consider the code you've seen to handle subsequent
paul> versions of the following:
I certainly agree that a change like this shouldn't be made at this
point except based on measured performance stuff, but (no offense) I
really disagree that such a change would "feel wrong" to most
programmers.
paul> - binary vs. text file formats
paul> - binary vs. text network protocols
Yeah, sure, but that just points out that text is great for
interfaces. It's OK for seldom-executed code. It's lousy for code
that's executed jillions of times. Just as we all understand people
deal better with text, I think we all understand that machines don't
deal as well with text.
Maybe I misunderstood what people were talking about, but I assumed
folks meant that when a "foo=bar" was read from some structured part
of an ABW file, the "bar" part would get looked up at import time and
translated to an enum (or an interned atom or some other manifestation
of a unique number). The reverse happens on export. Encapsulate the
lookup each way in a single function call, and what's the complexity?
Not much, I say.
BTW, there is one minor irritation that actually goes away and reduces
complexity if you translate to numbers: "Gee, I can't recall. Is this
kind of string case sensitive or not?" That just has to be remembered
in the mapping functions.
-- bill@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
This archive was generated by hypermail 2b25 : Tue Jan 23 2001 - 20:05:35 CST