On 3/24/02 4:16 PM, "Aaron Held" <aaron@...> wrote:
>> the middle-tier? Don't know. Perhaps. In the object world,
>> triggers are observers. Whenever a observer
> I just read an article in the Java Developer Journal about how
> you can use a new Java feature, the Java Proxy class to add
> logging to an existing class.
> It seems like a lot of work for what I accomplished with a few
> Python mix-in.
Yes, but mix-ins can be deadly. Zope 2 is a prime example of "death by a
thousand mix-ins". Mix-ins can work well, but in order to do so in a large
system they do have to be designed carefully so as not to tread on other
aspects of a class.
Ruby does mix-ins in a nice way. Ruby is single inheritance, with the
allowance of 'modules' (different than the Python concept of modules) to be
mixed into a class. As a result, the core libraries have a number of
mix-ins such as Enumerable (anything list-like) and Comparable that are used
by many of the major classes.
But still, in large systems, mix-ins can hurt as much as they can help.
Java and Smalltalk, to their own degrees, have succeeded as rigorous
single-inheritance, richly OO systems by promoting aggregation. Wrapping
things up in a proxy or any one of the structural GoF patterns (Adapter,
Bridge, Decorator) or behavioral ones like Mediator allow functionality to
be extended at run time - sometimes through configuration! This is a design
feature they're counting on for Zope 3, because right now it can sometimes
be too hard to change/replace fundamental Zope behaviors because the static
class hierarchy is too rich.
An interesting design example is the Cocoa frameworks of Mac OS X (and also
the Enterprise Objects Framework, one of the finest object-relational
persistence frameworks around). Cocoa makes heavy use of "Delegates",
objects which get attached to instances that implement a certain interface.
A delegate for a Window might be asked "can this window be closed now?", or
be warned that a certain window is about to be closed. It's basically an
interesting way of event handling, allowing a programmer to customize the
behavior of the "Close" widget for his/her application without having to
subclass NSWindow. It may sound like a small thing, but it's actually quite
significant. An example out of the Enterprise Objects Framework is from the
EUDatabaseContext delegate, which gives fine grained control over how a
primary key is generated, how and if objects are locked, etc. In theory,
with MiddleKit, I can write my own delegate implementing my businesses
primary key needs and use whichever database adapter I want, and do it all
through aggregation, maybe even through a configuration file.
So, back to the original statement of "it seems like a lot of work for what
I accomplished with a few Python mix-ins", the flexibility of Python can be
a joy, and the verbosity of Java can be awful. But beware of the death by a
thousand mix-ins - I've experienced this first hand in large Python systems
too many times.
> A while ago I promised this list a Java Servlet <-> Webware
> comparison (and a Cheetah quich ref guide).
> If anyone has any similar Java / Python / Servlet comparisons,
> please send them to me, on or off list, so I can write something
> useful up.
An interesting thing might be to find or implement a decent Jython servlet
and compare it to an identical-functionality servlet in Webware. It would
show a good contrast of the API's without getting stuck in language
semantics. To try to force myself to learn WebKit Servlet/PSP programming,
I tried doing a Python interpretation of a co-workers Java servlet system,
but got bogged down at points with language differences (particularly Java's
ability to call different methods with the same name but different argument
Jeffrey P Shell