> At 04:22 -0500 2003-06-27, [EMAIL PROTECTED] wrote: > > >I just have a hard time believing that 50 years from now our > >grandchildren won't look back [...]
I am in complete agreement with the spirit of what Peter says, though realistically, 50 years from now, this is likely to be all neither here nor there... (?) I can't address all the technical details of the issue(s) at hand, however, from a point of view of computing systems generally speaking, I think the following is true: 1. Everyone is more or less agreed that the present combining class rules as they apply to BH contain mistakes. The clearly preferential way to deal with mistakes in any technological/computing software environment is to FIX them. Several people have expressed reasons why this can't be (practically) be done--which mainly seem to stem from political concerns. 2. Consequently ANY OTHER solution than 'FIX the obvious mistake(s)' is a kludge (contra Philippe's (?) recent comment). One *pays* for all kludges, one way or the other. If one is going to do this clearly undesirable thing, one had better face that, acknowledge it, and be prepared to live with it, and not try to talk one's way out of it being a kludge. 3. In that case, the question is, which kludge will cause less damage in the end? (Because kludges will ALWAYS cause some problem one hasn't forseen. It is their nature, since they involve adding twists into an otherwise plain approach and complicating the algorithms in ways that are mystifying even to the experts, after a while.) 4. Creating a whole new set of characters whose combining classes can be redefined from scratch 'correctly' would seem to be undesirable, for a host of reasons: one can't justify duplicating existing characters (specially, if I understand it correctly, in the ISO environment which doesn't have all these other superset systems?), and to some extent, one (perhaps?) runs the risk of duplicating the present mess yet again, if one makes another mistake.... 5. Inserting some kind of other character in the chain (perhaps even a different one depending on the case, whether double vowels or metheg or whatever--that is not the issue just now) is clearly a kludge too... but then the sub-issue becomes whether to overload new semantics on existing characters (e.g. ZWJ etc.) with the potential of adding exponentially more twists in the system. Would it not be preferable, in that case, to create a new character (with the appropriate attributes that I really can't comment on) whose semantic is specific to addressing the current problem? New (clean) rules would then have to be defined to cope with this. This keeps the mess to a minimum. Now, Q: I take it the combining classes are linked to the script, rather than say to a dialect--e.g. one can't define BH as a separate dialect from MH with its own set of rules? (I assume this is the case because otherwise someone would have proposed it already.) I REALLY think that option 1 should be beaten to death with a stick, then beaten to death again, before settling for one of the others. Hoping this didn't sound like a pointless diatribe but rather that taking a step back from the details might help? K
