[gmpi] Re: low level API - Abstract Factory summary

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 09 Feb 2005 18:00:19 -0500

>What I'm saying is, there are much more important things to do here. 
>COM is very simple, one class with 3 functions, with the convention of 
>using a certain ID format (GUIID).
>
>I understand it's difficult to accept a new concept that's just 'thrown' 
>at you.  And that it seems safer to re-implement it yourself so as to 
>completely understand it.  But we're talking about the technique adopted 
>by Mozilla (the cross-platform open source browser).  They had the same 
>discussion we're having.  They're competent, knowledgeable people.  They 
>chose COM, they didn't waste time and energy reinventing it.

I'm quite willing to go down the COM route, especially after your
excellent distallation of what its really all about.
 
What troubles me (and it might trouble other people here who come from
a *nix dominated background) is more subtle.

One of the historical aspects of the *ix's close relationship with C
is that the OS API is very simple, and looks like C. It has very few
types in it that are not C builtin's, and those that do exist are very
simple data aggregation structures. All structures are used as struct
foo, never foo_t;

By contrast, anyone who has been keeping even half an eye on the win32
API over the last 15 years (win3.1, for completeness) will be aware of
the growing colossus-like nature of the API, with dozens of
win32-defined types that are used all over the place rather than
simple C builtins, all kinds of interface details that have nothing to
do with the language, and so on.

Now add even a smattering of C++/OOP, and you end up with an API that
requires quite a deep analysis before you can begin using it. 

This is not unjustified, and in fact even the *ix'es are faced with
the need for this kind of system as attempts to define "desktop
environments" (which are essentially layers on top of POSIX in the
same that win32 is a layer on top of the NT kernel API) grow more and
more complex. 

But I know that for myself, having been exposed to the marvelous
simplicity of a POSIX-style API, its incredible longevity (parts of it
are more than 30 years old now and still unchallenged) and all the
incredible software that has been built with such things, I am very
wary of developing an API rich in new datatypes, new interface styles,
and so forth.

To me, the VST API, for all its lack of specifications, strikes just
about the right balance here. Very few new types, a very simple
definition in C, and a simple layer on top in C++. You can grok the
whole thing in a very short time, and there's no "depth" to it.

Contrast that with:

   HRESULT CreateFactory( CLSID clsidClass, IFactory** ppFactory );

HRESULT?
CLSID?
IFactory?
Hungarian naming?

There's nothing wrong with any of these conventions, and if you're a
win32 programmer, you probably won't even notice them. But to me, this
is already taking on the trappings of a baroque, complex API.

--p

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: