|
Boost : |
From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-14 19:16:03
----- Original Message -----
From: "Mark Evans" <mark.evans_at_[hidden]>
> P.S. On that same theme, my name proposals are
>
> C-Thru
> SeamlessC
> BorderCrossing
I presume these are proposals for replacing "py_cpp", not
"ExtensionClass"... ;->
But seriously, what else would one call my extension classes, other than
"ExtensionClass"? I do have an outer layer now, called "ClassWrapper", but
that's just for the easy interface (see example1.cpp in the latest
distribution). There are still ExtensionClass objects under the covers. It
is possible that all names will be changed to all_lower_case in
correspondence with the rest of boost's conventions. Would extension_class
be any better?
Thanks for your feedback,
Dave
> Kind regards,
>
> Mark Evans
> mailto:mark.evans_at_[hidden]
>
> ----- Original Message -----
> Saturday, October 14, 2000
> 6:26:04 PM
>
> ME> David,
>
> ME> Thank you for this generous comparison chart. May I suggest that
> ME> your documentation and code strive to avoid the terms
> ME> "ExtensionClass." What threw me off was seeing source code files
> ME> like extclass.c and references to ExtensionClass on the web site.
>
> ME> Kind regards,
>
> ME> Mark Evans
> ME> mailto:mark.evans_at_[hidden]
>
> ME> ----- Original Message -----
> ME> Saturday, October 14, 2000
> ME> 6:23:15 PM
>
> DA>> It's different. How entirely different? I'm not sure ;-) Looking at
> DA>> http://www.digicool.com/releases/ExtensionClass, these are the
obvious
> DA>> similarities:
>
> DA>> * Both rely on the same "Don Beaudry Hack" that also inspired MESS.
> DA>> * Both support subclassing in Python, including multiple inheritance
>
> DA>> and the differences:
>
> DA>> * py_cpp lifts the burden on the user to parse and convert function
argument
> DA>> types. Zope provides no such facility.
> DA>> * py_cpp lifts the burden on the user to maintain Python
reference-counts.
> DA>> * py_cpp supports function overloading; Zope does not.
> DA>> * py_cpp supplies a simple mechanism for exposing read-only and
read/write
> DA>> access to data members of the wrapped C++ type as Python attributes.
> DA>> * Writing a Zope ExtensionClass is significantly more complex than
exposing
> DA>> a C++ class to python using py_cpp (mostly a summary of the previous
4
> DA>> items). See
> DA>> http://www.digicool.com/releases/ExtensionClass/MultiMapping.html for
a Zope
> DA>> example.
> DA>> * Zope's ExtensionClasses are specifically motivated by "the need for
a
> DA>> C-based persistence mechanism". py_cpp's are not.
> DA>> * Thus, Zope's ExtensionClasses support pickling. Currently py_cpp
> DA>> ExtensionClasses do not.
> DA>> * The following Zope restriction does not apply to py_cpp: "At most
one base
> DA>> extension direct or indirect super class may define C data members.
If an
> DA>> extension subclass inherits from multiple base extension classes,
then all
> DA>> but one must be mix-in classes that provide extension methods but no
data"
> DA>> * Zope's Extension SubClasses admit multiple-inheritance from both
Zope
> DA>> ExtensionClasses /and/ Python classes. This capability is currently
not
> DA>> available in py_cpp.
> DA>> * Zope supplies the standard special Python class attributes __doc__,
> DA>> __name__, __bases__, __dict__, and __module__ on it's
ExtensionClasses;
> DA>> py_cpp does not (coming soon ;->)
> DA>> * Zope supplies some creative but esoteric idioms such as Acquisition
> DA>> (http://www.digicool.com/releases/ExtensionClass/Acquisition.html)
> DA>> * Zope's ComputedAttribute support is designed to be used from
Python. The
> DA>> analogous feature of py_cp is designed to be used from C++ (I make no
claims
> DA>> that the py_cpp mechanism is more useful than the Zope mechanism in
this
> DA>> case)
>
> DA>> Also, the Zope docs say:
> DA>> "The first superclass listed in the class statement defining an
extension
> DA>> subclass must be either a base extension class or an extension
subclass.
> DA>> This restriction will be removed in Python-1.5." I believe that this
promise
> DA>> was made prematurely. I have looked at the Python 1.5.2 source code
and I
> DA>> don't believe it is possible to deliver on it.
>
> DA>> Thanks for the opportunity to write this. I'm currently overhauling
the
> DA>> py_cpp documentation; this will make a valuable addition.
>
> DA>> -Dave
> DA>> ----- Original Message -----
> DA>> From: "Mark Evans" <mark.evans_at_[hidden]>
> DA>> To: <abrahams_at_[hidden]>
> DA>> Sent: Saturday, October 14, 2000 5:24 PM
> DA>> Subject: Who is py_cpp
>
>
> >>> Is py_cpp the same thing as the ExtensionClass system used in
> >>> ZOPE? Or something entirely different?
> >>>
> >>> Kind regards,
> >>>
> >>> Mark Evans
> >>> mailto:mark.evans_at_[hidden]
> >>>
> >>>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk