Dne 20.4.2015 v 15:14 Martin Basti napsal(a):
On 17/04/15 16:15, Jan Cholasta wrote:
Dne 16.4.2015 v 16:46 Jan Cholasta napsal(a):
Hi,

the attached patch adds the basics of the new installer framework.

As a next step, I plan to convert the install scripts to use the
framework with their old code (the old code will be gradually ported to
the framework later).

(Note I didn't manage to write docstrings today, expect update
tomorrow.)

Added some docstrings.

Also updated the patch to reflect little brainstorming David and I had
this morning.


Honza



Hello, see comments bellow:

1) We started using new shorter License header in files:
#
# Copyright (C) 2015  FreeIPA Contributors see COPYING for license
#

OK.


2) IMO this will not work, NoneType has no 'obj' attribute
+        else:
+            if isinstance(value, from_):
+                value = None
+                stack.append(value.obj)
+                continue

Right.


3) Multiple inheritance. I do not like it much.
+class CompositeInstaller(Installer, CompositeConfigurator):

I guess you are antagonistic to multiple inheritance because of how other languages (like C++) do it. In Python it can be pretty elegant and is basis for e.g. the mixin design pattern.


Installer and CompositeConfigurator inherites from Configurator class,
and all of them implements _generator method.

Both of them call super()._generator(), so it's no problem (same for other methods).


If I understand correctly
(https://www.python.org/download/releases/2.3/mro/) the
Installer._generator method will be used in this case.
However in case when CompositeConfigurator has more levels (respectively
it is more specialized) of inheritance, it could take precedence and its
_generator method may be used instead.

The order of precedence is defined by the order of base classes in the class definition.


I'm afraid this may suddenly stop working.
Maybe I'm wrong, please fix me.

As long as you call the super class, it will work fine.


And Multiple inheritance is not easily readable, this is even a diamond
inheritance model.

Cooperative inheritance is used by design and IMHO is easily readable if you know how to read it. Every class defines a single bit of behavior. Without cooperative inheritance, it would have to be hardcoded and/or hacked around, which I wanted to avoid.

This blog post explains it nicely: <https://rhettinger.wordpress.com/2011/05/26/super-considered-super/>.


--
Martin Basti


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to