libvisual-devel

[Libvisual-devel] Random design questions:

[Dennis S. <sy...@yo...>]

Heya list,

I've got some things I'd like to discuss:

Currently in plugins we often do BlahPriv *priv = plugin->priv;

what do you people think about having something like:

BlahPriv *priv = VISUAL_PLUGIN_PRIVATE (plugin);

or, would it nicer to make a define in the
style of visual_plugin_get_private (plugin);, to be in
style with the rest of the accessor methods ?

Also, would there be defines, functions to make plugin creation easier ?

anyone suggestions ?

Cheers,
Dennis

Re: [Libvisual-devel] Random design questions:

[Duilio J. P. <dp...@fc...>]

> what do you people think about having something like:
> 
> BlahPriv *priv = VISUAL_PLUGIN_PRIVATE (plugin);
> 
> or, would it nicer to make a define in the
> style of visual_plugin_get_private (plugin);, to be in
> style with the rest of the accessor methods ?

I like more the last method.


Bye,
Duilio.

Re: [Libvisual-devel] Random design questions:

[Burkhard P. <pl...@ip...>]

Dennis Smit wrote:
> Heya list,
> 
> I've got some things I'd like to discuss:
> 
> Currently in plugins we often do BlahPriv *priv = plugin->priv;
> 
> what do you people think about having something like:
> 
> BlahPriv *priv = VISUAL_PLUGIN_PRIVATE (plugin);
> 
> or, would it nicer to make a define in the
> style of visual_plugin_get_private (plugin);, to be in
> style with the rest of the accessor methods ?
> 
In all cases, the programmer has to write one line,
so typing time is hardly saved. Using

BlahPriv *priv = plugin->priv;

has the advantage, that everyone knows what's going on,
even without reading documentation. I use this method
in my whole code.


-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102

Re: [Libvisual-devel] Random design questions:

[Dennis S. <sy...@yo...>]

On Wed, 2004-10-06 at 11:26 +0200, Burkhard Plaum wrote:
> In all cases, the programmer has to write one line,
> so typing time is hardly saved. Using
> 
> BlahPriv *priv = plugin->priv;
> 
> has the advantage, that everyone knows what's going on,
> even without reading documentation. I use this method
> in my whole code.

Well the point is that it's not abstract, if we were
forcing the user to access everything directly through
the fields of the structures, every small change in the structure
would mean that every plugin needs to be updated...

Dennis

Re: [Libvisual-devel] Random design questions:

[Burkhard P. <pl...@ip...>]

> Well the point is that it's not abstract, if we were
> forcing the user to access everything directly through
> the fields of the structures, every small change in the structure
> would mean that every plugin needs to be updated...

What needs to be updated?
If the priv member isn't renamed, the code must only be
recompiled. If the direct accessable members are put at the
beginning of the struct and arent't changed, even recompilation
isn't necessary.

If a stable ABI is desired, you'll need access functions
for everything (macros arent't enough).
In this case, I would recommend to make the struct completely
anonymous (put only a forward declaration in the .h file and
the struct definition into the .c file). In this case, gcc will
not allow to access any struct members directly from another
.c file.

-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102