Choose a paradigm and stick to it, dammit!

[jducoeur]

Another sin to lay at Microsoft's feet: I'm currently working on doing some seriously down-and-dirty programming inside of IE. (Yes, I know, but there's a lot of magic we want to do that simply can't be done at the Javascript level.) In many ways, it's a delightfully complete system -- when working in C++, you can make IE sit up and do almost any sorts of tricks.

But: rarely in my life have I seen anything so inconsistent. If I have to pass a string into a method, it's sometimes a BSTR, and sometimes a VARIANT. If I need to pass a number, it's sometimes long, sometimes a VARIANT, and sometimes a VARIANT that wraps a BSTR that represents the number. Someone clearly wrote a standard for these APIs at some point, because they're consistent in *some* ways, but there is no obvious rhyme or reason to the parameters at all.

(And we won't even get into the fact that every object implements something like eight different interfaces, so I'm QI'ing all over the place...)

Comments

[(Anonymous)]

I'd call that a probable side-effect of code bloating. Get 8,000,000 people working on something, including interns, and no one is talking to one another, and people are hacking previous work to do something else, etc.

Its too bad that you have to rely on IE to do what you need to do :/

- Eric

QI?

[metageek.livejournal.com]

What's QIing?

Re: QI?

[jducoeur]

The basic concept of COM is that it tries to add to C++ the key features that the language is lacking. High among those is a really good concept of interfaces. While you can do interfaces in C++, there's no straightforward way to cast from interface A to interface B, since interfaces are literal memory pointers. Such casting is essential to maintaining decent code opacity, especially in a system as complex as Windows.

So one of the base methods in COM, that every object is required to implement, is "QueryInterface". This takes a GUID that acts as the globally-unique "name" of that interface, and returns this object's version of that interface, or NULL if the object doesn't implement it. All interfaces implement this, so you can cast from this interface to any other interface that this object implements.

I've been doing a lot of that because of how IE has evolved. Not only does each major object implement IHTMLElement and IDOMNode, it also implements its own basic node, like IHTMLTable. And since Microsoft is religious about never modifying an interface once it is published, each release adds new variants of many of these interfaces that have new methods -- IHTMLTable2, IHTMLTable3, and so on. Plus, they keep adding new methods to the universal element type, so we get IHTMLElement2, IHTMLElement3, and so on. Hence, I wind up with any given object implementing often ten interfaces, with no terribly obvious rhyme or reason as to which method is on which interface, since it largely has to do with *when* that method was added...