<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><SPAN class=218185915-25062007><FONT face=Arial
color=#0000ff size=2>Sounds quite interesting, You have my
vote.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=218185915-25062007><FONT face=Arial
color=#0000ff size=2>max</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> baypiggies-bounces@python.org
[mailto:baypiggies-bounces@python.org] <B>On Behalf Of </B>Ken
Seehart<BR><B>Sent:</B> Saturday, June 23, 2007 5:26 AM<BR><B>To:</B>
Python<BR><B>Subject:</B> [Baypiggies] Possible talk: A Nondualist Alternative
to ProxyWrapper Theory<BR></FONT><BR></DIV>
<DIV></DIV>If you read my previous email that was accidentally sent here
instead of python.org, you have some idea of what this is about.<BR><BR>What
is new is that I did some experimenting and came up with some interesting
results. In fact I have implemented a proof-of-concept of what I
describe below.<BR><BR>So let me know if you would like me to give a talk on
this subject.<BR>
<H3>Overview:</H3>Anyone who has wrapped C or C++ libraries that contain
methods which use and/or return instances of the types that are being wrapped
has encountered what I call the <I>inheritance/proxy wrapper
dilemma</I>.<BR><BR>The general scenario is that we have a python extension
library which we wish to enhance by writing a python layer to add
functionality and improve syntax. A good example is the wxPython
library. The most obvious thing to do is to derive our classes from the
extension types. This works fine until we have to deal with methods in
the extension library that create and return instances of the low level
types. We want to only expose instances of our classes, not the low
level objects.<BR><BR>At this point we do a little research and find out that
we should be using composition rather than inheritance. So we make a
proxy system and inevitably wind up with a rather unwieldy pile of meaningless
wrappers on all of our methods. This solution is generally considered
better than inheritance, but it creates a new set of problems. Two
obvious problems associated with the proxy solution are the extra function
call overhead of the wrappers, and the necessity of generating piles of
boilerplate code. Also there is a tendency for the dualism between the
proxy object and the raw object to be an ongoing annoyance. Once most of
the bugs are weeded out, the proxy system works adequately, but can't really
be considered fun.<BR><BR>
<H3>A Nondualist Alternative to Proxy Wrapper Theory:</H3>In this talk, I will
demonstrate a technique for implementing wrappers without proxies that
nevertheless have all the desirable features that we expect from composition
based solutions, and all the simplicity we had hoped for with simple
inheritance. We eliminate dualism along with the unnecessary run-time
overhead of wrappers. The challenge is to keep an open mind when faced
with scary seeming violations of well established object oriented theory, and
focus on the practical considerations.<BR><BR>Time: 45 minutes to 1
hour. Probably not for beginner night :-) Let me know if you are
interested.<BR><BR>- Ken Seehart<BR><BR></BLOCKQUOTE></BODY></HTML>