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/