Code review comment for lp://staging/~smspillaz/compiz-libcompizconfig/refactor-context

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

On Fri, 4 May 2012, Alan Griffiths wrote:

> I'm still struggling to identify the design goals here.
>
> Indirecting calls via a CCSContextInterface member pointer gives the capability to change the implementation of individual functions on an instance by instance basis. Is this needed? Or just a seam for testing? If the latter, then there's no need for objects to carry around a pointer.
>

Sure, it is a seam for testing. However, its useful in that we can test by
having a real CCSPlugin, CCSContext and a mocked CCSSetting or vice-versa.
We may also want to test interactiosn between individual setting objects
themselves vis-a-vis keybinding conflicts.

> I also don't see what the additional indirection through CCSInterfaceTable* is for. The only use is ccsEmptyContextNew which assigns to object_interfaces, but where is it used? And what for?
>

At the moment, this is so that you can override the kind of objet that
might be constructed by a CCSContexted or CCSPlugin internally. This will
be replaced when the code is further refactored to truly do dependency
injection.

>
> --
> https://code.launchpad.net/~smspillaz/compiz-libcompizconfig/refactor-context/+merge/104469
> You are the owner of lp:~smspillaz/compiz-libcompizconfig/refactor-context.
>

« Back to merge proposal