I'll think about it (although it complicates configuring those objects by a very big factor which I'm not sure I like it).

Regarding the context objects:

* as of today context is equal to object for extraction phase but is equal to array in hydration phase. This is confusing when using it because of the generic $context name. While in some other zf2 component where context can really be anything, in hydrator the context is either an object or an array. So those objects just make it clear.
* in zf2 as I said during hydration the context is equal to the array data. But in lot of use cases I actually not only needed the array data BUT also the object itself that is being hydrated. Of course you could set an indexed array as context but this is even more confusing. Once again the contexts objects make it clear and allow to encapsulate all the context.

Envoyé de mon iPhone

> Le 18 mai 2014 à 00:12, devosc <notifications@github.com> a écrit :
> 
> In src/Hydrator/AbstractHydrator.php:
> 
> > +     * Constructor
> > +     */
> > +    public function __construct()
> > +    {
> > +        $this->compositeFilter = new CompositeFilter();
> > +        $this->namingStrategy  = new UnderscoreNamingStrategy();
> > +    }
> > +
> > +    /**
> > +     * Set a new strategy for a given property
> > +     *
> > +     * @param  string            $name
> > +     * @param  StrategyInterface $strategy
> > +     * @return void
> > +     */
> > +    public function setStrategy($name, StrategyInterface $strategy)
> It might be worth thinking about a HydratorConfig object, the interface of these config objects can indicate how the intended Hydrator is to be used or what it will be doing. And at the same time would remove any need for get/set methods (but they can be left there for BC). This way the constructor can simply set the configuration object or the parts it wants (e.g. $strategies).
> 
> In the constructor I'd rather see $this->strategies = $strategies than a for loop.
> 
> Ideally (imo), all the strategy related methods, should go into a Strategy Config object, and the hydrator could provide a convenience method so that they can be configured via $hydrator->strategies()->addStrategy() etc.
> 
> The HydratorConfigInterface might look like
> 
> interface ConfigInterface
> {
>   public function filters();
>   public function strategies();
> }
> I'm currently not seeing much point to the Extract and Hydrate Contexts, why not just pass the object itself?
> 
> The namingStrategy bugs me a little, but I don't know what to suggest atm.
> 
> I also wondered if the cache could also be a config?
> 
> —
> Reply to this email directly or view it on GitHub.