FW: [C++-sig] Injected constructors
Just a question what is wrong with static member function or global function make_xxx? The idiom of constructing object and then making additional initialization is already used in Boost.Python - borrowed function for constructing handle. Also in Python code it will be written explicit what programmer is going to do. Did I missed something? Roman. -----Original Message----- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: Wednesday, July 23, 2003 5:49 PM To: c++-sig@python.org Subject: [C++-sig] Injected constructors It's already possible to inject new methods into a Python class wrapper that are not in the underlying class: #include <vector> struct X { std::vector<int> v; }; int size(X& self) { return self.v.size(); } BOOST_PYTHON_MODULE(test) { class_<X>("X") .def("size", size) ; } >>> x = X() >>> x.size() 0 Currently, there's no easy way to do the same thing for constructors, without intruding on the underlying class or writing a wrapper class which repeats *all* of the base constructors and adds new ones. I am about to add just such a facility: std::auto_ptr<X> x_factory(PyObject* self, int n) { std::auto_ptr<X> x(new X); x->v.resize(n); return x; } BOOST_PYTHON_MODULE(test) { class_<X>("X") .def("size", size) .def("__init__", init_factory(x_factory)) ; } >>> x = X(30) >>> x.size() 30 init_factory creates a python callable object which calls its function argument and injects the resulting object into a holder in the self argument. I'm not in love with the "init_factory" name. Anyone have a better idea? -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
"Roman Yakovenko" <romany@actimize.com> writes:
Just a question what is wrong with static member function or global function make_xxx?
Good point. init_factory was going to be a global function, but I guess I like "make_init" much better than "init_factory". Thanks!
The idiom of constructing object and then making additional initialization is already used in Boost.Python - borrowed function for constructing handle.
Sure; that's .def(init_factory(f)) or, I guess: .def(make_init(f)) right?
Also in Python code it will be written explicit what programmer is going to do. Did I missed something?
I don't know. What point are you trying to make with this remark? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Mike Rovner" <mike@nospam.com> writes:
David Abrahams wrote:
"Roman Yakovenko" <romany@actimize.com> writes: .def(make_init(f))
I suggest .def(init<>(&f)) //for regular use and .def(make_init(&f, call_policy)) // for other; like make_function
Ack! The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
Mike Rovner -
Roman Yakovenko