Wikipedia:Articles for deletion/OLE Automation
From Wikipedia, the free encyclopedia
- The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.
The result was keep. Can't sleep, clown will eat me 07:20, 25 July 2006 (UTC)
[edit] OLE Automation
First of all, it isn't OLE Automation any more, it's now just Automation (and has nothing to do with OLE), and it's a too obscure to warrant a separate article. The content should be merged into COM and the article deleted. - Sikon 06:17, 20 July 2006 (UTC)
- Merge per Sikon. Term refers to a flavor of the day from the mid-late 1990's. Probably already documented at COM along with dozens of other such variants; I won't bother looking. Phr (talk) 11:53, 20 July 2006 (UTC)
- Unlike Phr, I did bother looking. Both Component Object Model and Object Linking and Embedding actually link to this article for discussion of the subject. Contrary to what Sikon writes above, research (and indeed the article) indicates that this is far from being an obscure topic, with many people writing programming guides and articles about OLE Automation. The article is a stub with clear scope for plenty of expansion. Deleting this, so that "OLE Automation" becomes a redlink, is just daft. Keep. Uncle G 16:34, 20 July 2006 (UTC)
- This should be a redirect at best, move it to Automation (COM) or something, but "OLE Automation" is a term discontinued by Microsoft itself, in favor of just Automation. - Sikon 16:52, 20 July 2006 (UTC)
- Untrue. Microsoft still calls it "OLE Automation" here, here, here, here, and here, to pick just 5 articles from the 54,800 matches for the phrase that Google Web says are on Microsoft's web site. Uncle G 17:23, 20 July 2006 (UTC)
- Who cares, it's just a COM object that has this specific very common interface that goes at least as far back as Windows 95. Put it all in the COM article and have the other terms redirect. Phr (talk) 17:31, 20 July 2006 (UTC)
- Also wrong. It's not an object at all. It is a protocol. And it is IDispatch that is the interface. Uncle G 17:59, 20 July 2006 (UTC)
- Yeah, whatever. Merge. (And to address your concern, "merge" means leave redirects, so there won't be redlinks). Phr (talk) 18:21, 20 July 2006 (UTC)
- Also, IDispatch is not just any old interface - it's the specific interface you need to implement if you want your COM object to be accessible from VBScript/JScript, and it's used for programmatic control of MS Office and probably assorted other things too. IIRC, OLE Automation is also distinct from OLE/COM in general in that OLE/COM has a many different interfaces for different objects, each with a fixed set of methods, and you need to provide the definitions for all the interfaces you need to use at compile-time, whereas OLE Automation only uses IDispatch, all of the methods of an object can be called via that, and the methods used don't need to be known at compile-time. - makomk 17:10, 21 July 2006 (UTC)
- Correct, the point is that while IDispatch made important new uses possible, in a pure technological sense, this is all the same stuff under the hood. I'd really like to see a historical explanation in the COM article about how COM programming evolved over different generations of Windows as these interfaces appeared, but in any case, Automation arose as part of that evolution. Remember that COM encompasses both Automation and non-Automation uses.
So I still haven't seen any sensible argument (as opposed to "prevent redlinks") presented in this AfD for keeping the articles separate, but as someone suggested, the talk page is maybe a better place for that discussion.
- Correct, the point is that while IDispatch made important new uses possible, in a pure technological sense, this is all the same stuff under the hood. I'd really like to see a historical explanation in the COM article about how COM programming evolved over different generations of Windows as these interfaces appeared, but in any case, Automation arose as part of that evolution. Remember that COM encompasses both Automation and non-Automation uses.
- Also, IDispatch is not just any old interface - it's the specific interface you need to implement if you want your COM object to be accessible from VBScript/JScript, and it's used for programmatic control of MS Office and probably assorted other things too. IIRC, OLE Automation is also distinct from OLE/COM in general in that OLE/COM has a many different interfaces for different objects, each with a fixed set of methods, and you need to provide the definitions for all the interfaces you need to use at compile-time, whereas OLE Automation only uses IDispatch, all of the methods of an object can be called via that, and the methods used don't need to be known at compile-time. - makomk 17:10, 21 July 2006 (UTC)
- Yeah, whatever. Merge. (And to address your concern, "merge" means leave redirects, so there won't be redlinks). Phr (talk) 18:21, 20 July 2006 (UTC)
- Also wrong. It's not an object at all. It is a protocol. And it is IDispatch that is the interface. Uncle G 17:59, 20 July 2006 (UTC)
- Who cares, it's just a COM object that has this specific very common interface that goes at least as far back as Windows 95. Put it all in the COM article and have the other terms redirect. Phr (talk) 17:31, 20 July 2006 (UTC)
- Untrue. Microsoft still calls it "OLE Automation" here, here, here, here, and here, to pick just 5 articles from the 54,800 matches for the phrase that Google Web says are on Microsoft's web site. Uncle G 17:23, 20 July 2006 (UTC)
- This should be a redirect at best, move it to Automation (COM) or something, but "OLE Automation" is a term discontinued by Microsoft itself, in favor of just Automation. - Sikon 16:52, 20 July 2006 (UTC)
- Keep Even if Microsoft is trying to change the terminology (they do that a lot and it's really annoying) this term is still routinely and commonly used. Fan-1967 18:04, 20 July 2006 (UTC)
- Eh? Why a separate article instead of a redirect? Am I missing something? I never could stand the way they kept changing terminology, and generally referred to all these things as ActiveX more or less on purpose when I was programming this stuff, even when that wasn't strictly accurate. I would have loved it if they'd put all the relevant docs in one place instead of making me constantly navigate the MSDN maze. Phr (talk) 18:21, 20 July 2006 (UTC)
- Keep per Uncle G, whose verifiable references and cogent arguments are somewhat more convincing than "I won't bother looking" and "Yeah, whatever". — Haeleth Talk 18:30, 20 July 2006 (UTC)
- I've looked now and feel the same way as before. Do you know anything about this subject? Do you know what IDispatch is, for example, and to what extent its presence makes an object different? I didn't look at the other articles before because I didn't feel that I needed to, having spent more time programming COM than I want to think about (shudder). I don't mean to be giving you a hard time, and I'm sorry to have been so flip, but I'm knowledgable enough about this subject to feel that I know what I'm talking about when I say I think we're better off with it all in one article and having the related terms redirect. It's Uncle G, on the other hand, who doesn't seem to realize that merging with redirects doesn't leave redlinks (and of course "merge" means fix the backlinks). And he hasn't made any cogent arguments of anything except that the old term is still in use, which I haven't contested. Phr (talk) 18:39, 20 July 2006 (UTC)
- Keep per Uncle G and my comments above. - makomk 17:10, 21 July 2006 (UTC)
- Keep if it would be better merged or moved, take it to the article's talk page. Kotepho 17:27, 21 July 2006 (UTC)
- The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.
