Re: `stringlist params' in GNOME::ObjectFactory::create_object

[Maciej Stachowiak <mjs eazel com>]

Miguel de Icaza <miguel helixcode com> writes:

> > Actually, it would still be nice to have some solution for passing
> > arguments to objects at initialization time. For example, if we ever
> > wanted something like pOuterUnknown in Microsoft COM [hint: we really
> > need it to be truly language-neutral], we would need this
> > functionality. Right now the only way to pass arguments at object
> > creation time is to define a custom factory interface, and that just
> > plain sucks.
> 
> What does pOuterUnknown do?
>

It's a powerful mechanism for reuse, basically it lets you take an
existing COM object that implements some interfaces you like, and add
your own additional interfaces to it (and still have everything work
properly with QI). I will explain in more detail when I get into work
and can look at the copy of Essential COM that I stole from Ramiro.
 
> > Monikers don't really have any relation to this at all, as far as I
> > can tell.
> 
> Wait till you see the updated Moniker doc I have (started updating it
> this afternoon, after everyone was confused by what it said), it will
> cover this in more detail and why it is related.
> 

Your document is heavy on examples, but low on explaining how they
work. The way I read it, it looks like a moniker like

file:logo.png!Zoom=2.0,dither=max,notransparency

Would first activate an EOG viewer object, and then feed it the
logo.png data, and the various attributes. At least, I do not see any
way it can bypass the fact that activation itself passes no arguments,
and you cannot make calls of any kind on an object before activating
it.

But in some rare cases, you need to pass arguments _at_ activation
time, just like GtkObjects sometimes have mandatory construct
arguments, or you cannot create the object at all. The pOuterUnknown
thing happens to be one of those (admittedly rare) cases.

Anyway, monikers seem interesting in general, even though they do not
solve every problem in the world. I certainly don't expect any one
abstraction to solve every problem, though.

I have a bunch of questions based on your docs, but it would probably
be better to be able to ask you or Michael interactively.

 - Maciej