OSDev.org

In regards to COM again, one of the problems I keep having is that the reference material I have found on it seems execptioanlly poor in explaining the conceptual framework of the model; they tend concentrate on the pragmatics of using it, without explaining why things are done in such-and-such a manner. As a result, I have always gotten the impression that it was a very ad-hoc system, without much purposeful design put into it (much like VB). Perhaps it would help if you could provide an overview of it to help clarify the ideas underlying it, Zloba. I'm sure it would be of interest to even those who dislike COM already.

However, I would recommend restraining your enthusiam about it, and sticking to basics rather than prostelytizing. You're more likely to get a fair hearing from us that way; blind pangyrics do not make effective engineering critiques. Also, you can expect some vigorous debate on it, as there will be others who will disagree with you (from design and practical points of view, not simply out of MS-bashing).

zloba wrote: i don't think it is the job of a general-purpose language to impose an object model, but to be consistent with its generality and give me the tools (based on OOP principles) and the choice how to use them.
(the tools being, as i see it, inheritance and virtual tables for polymophism, and complete control over them)

That would be nice and well if languages would be designed at the drawing board, and everyone would agree on what an OO object model should look like.

But languages grow into existence, and it is not uncommon for language designers to mold their language after what they think is good OO. No OO language in practical use is free from this notion.

C++ doesn't allow inner classes to access data members of their host. Java doesn't allow for multiple inheritance. The other OO languages I don't know, but all of them will fall short of implementing "perfect" OO, since no-one can tell what "perfect" means.

And even if your language implements "complete control", the moment you start handling e.g. COM, you have to limit yourself, because there are things a native language object can do that a COM object cannot.

(The alternative would be that COM objects allow for everything, and only a "perfect" OO language being able to handle that properly. That'd be even worse.)

So, you always get some kind of friction when fitting an OO language and some exterior object model, except when that model has been customized for that exact language - which will make all other languages worse for the deal.

Catch 22.

Schol-R-LEA wrote: Perhaps it would help if you could provide an overview of it to help clarify the ideas underlying it, Zloba. I'm sure it would be of interest to even those who dislike COM already.

Seeing how OsKit uses COM (-alike, I'm not really sure about the details) as interface between the individual components of its OS kernel framework, such an overview would even be highly on-topic...

(And most welcome anyway. Learninglearninglearning... )

Schol-R-LEA

Perhaps it would help if you could provide an overview of it to help clarify the ideas underlying it

happily. may take some time, though.

However, I would recommend restraining your enthusiam about it, and sticking to basics rather than prostelytizing. You're more likely to get a fair hearing from us that way; blind pangyrics do not make effective engineering critiques. Also, you can expect some vigorous debate on it, as there will be others who will disagree with you (from design and practical points of view, not simply out of MS-bashing).

i fully agree.

Solar

And even if your language implements "complete control", the moment you start handling e.g. COM, you have to limit yourself, because there are things a native language object can do that a COM object cannot.

observe the difference: i choose to limit myself, and in return get the benefits promised by the model. i can choose COM or another model, or just go nuts, or all of the above at the same time in different contexts.

also,

there are things a native language object can do that a COM object cannot

i dont quite agree with that. COM only concerns itself with how you use an object from outside, through an interface pointer. inside the implementation, locally, you can do anything you like, as long as you end up implementing your interfaces to the spec.

but anyways that's under the assumption that there is such perfect language, which there isn't so far.