Florian Lagg wrote:
>> With arrays we can have "read-only" arguments, with objects we don't.
>
> The arrays aren't really read-only because the plugin can write on them.
> This could be a stumbling block for plugin development because the
> developer doesn't see the variable is read-only.
Of course they are writable for the plugin but it's just a local copy and
not the original data. The plugin has to RETURN the altered data. That's
simple data-in and data-out. Altering arguments that are passed by
reference makes it hard to understand where data is changed when
reading/debugging the code.
I agree that it might not be clear to the plugin if the modified data it
returns will really be used by the app but I don't like to build a complex
data structure before calling a hook. As an application developer I'd like
to compose hook arguments inline like
$plugin->trigger_hook('a-hook', array('foo' => $bar, ...));
because I think this is the common case. Let's move the specification which
modified data will finally be used to the documentation of the plugin-hooks.
>
> We just have to define data classes we can use in our plugins. Maybe we
> find a way to isolate plugins to these functions (and not to access
> roundcube objects directly e.g. using the main roundcube singleton (cannot
> remember the name right now)? Don't know.
I don't know neither.
>
> Ok, than any hook should send them array(foo), where foo is a data class.
I suggest to always use a name => value map. Since PHP does not support
named parameters this is the best way to achieve maximum extendability.
>
> With the above code (classes rather than arrays) we can delegate
> some data checking logic to the plugin-architecture.
Sorry, I don't understand what you mean. Example?
Maybe we should continue this conversation in German :-)
>
> I think this is the clearest definition we had so far. What do you think?
>
We're getting close, yes.
~Thomas
_______________________________________________
List info: http://lists.roundcube.net/dev/
