Florian Lagg wrote:
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.
We can have read only arguments with classes. class foo { private $bar_ro; private $bar_rw;
public function getBar_ro() { return $bar_ro; } public function getBar_rw() { return $bar_rw; } public function setBar_rw($value) { //check some things here if($value < 0) throw new Exception('setBar_rw bust be equal or more than 0') return true; }} There is no setter so a plugin which gets this class parameter could not set $bar_ro - but read it. The variable $bar_rw could be written also - but there are some checks if the values are correct. We can also control & check given data so we could write it back if the core code without any problems.
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.
Don't over-complicate and over-architect things like this one - creating one parameter object per hook does not make any sense as it is just a lot of work for almost no benefit. Using and especially creating plugins should be super simple, otherwise people won't start creating plugins. And using objects for parameters is definitely not easy.
There is a convention - an parameter array for receiving data ("named parameters") and returning data as an array. Done. Never touch the input array. This rule is relatively easy to check during QA and it is easy to use and developers are used to that.
Every class you create has to be understood and makes stuff more complicated. KISS.