This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7205
User: @marc-mabe
Created On: 2015-02-11T19:43:42Z
Updated At: 2015-02-25T18:26:10Z
Body
This is a prototype!!!!

This would be duplicated in all Options classes requiring some ordering of options.

@Ocramius @weierophinney In my opinion the issue #6381 should be marked as won't fixed as the options will be applied in the order they are defined. This behavior should be documented but not changed into a adapter defined ordering like this prototype. Additionally this prototype shows it's more error prone than the current behavior and would be needed to be document3ed for each adapter what the defined order would resulting in other WTF moments.

Comment

User: @weierophinney
Created On: 2015-02-19T21:16:47Z
Updated At: 2015-02-19T21:16:47Z
Body
My feeling is that this shouldn't be abstracted at all. If options need to be set in a particular order, then each options class should implement this functionality accordingly, instead of relying on the parent. This is particularly salient considering you've re-implemented most of the logic of Zend\Stdlib\AbstractOptions::setFromArray() already; why delegate to the parent at all?

Instead, go through the options in the order in which they should be applied and set them on the instance directly.