[Zope] Re: Modifying __bases__

[Dan Pozmanter]

Yes, this definitely makes sense.  Which is why monkey patching is never
used lightly,
but also why clean code and good documentation are so necessary.  Any
code is difficult to maintain
when it is murky, undocumented, and the developer lacks the relevant
historical background.

In any case, I'll pass this on to the fellow who is muddling about with
User Objects.

Many Thanks,

Dan

-----Original Message-----
From: zope-bounces+dan=siteworx.com at zope.org
[mailto:zope-bounces+dan=siteworx.com at zope.org] On Behalf Of Derrick
Hudson
Sent: Wednesday, May 25, 2005 9:55 AM
To: zope at zope.org
Subject: [Zope] Re: Modifying __bases__

On Fri, May 20, 2005 at 05:10:30PM -0400, Dan Pozmanter wrote:
| Out of curiosity, I've noticed the word "evil" attached to patching of

| various and monkey kinds.  Not "bad", or "unwise", but "evil", 
| implying a morality associated with the act.

I think it is used mainly to give added emphasis to lessons learned from
painful experience.  As Paul reported, hours can be wasted tracing the
wrong code trying to understand what is happening.

| What is morally wrong with modifying live objects in a dynamic 
| language to achieve desired functionality?

The problem is maintainability.  When you dynamically rewrite the code,
the code is then very difficult to follow, verify, and modify.
It is even harder for someone else to maintain the code because they
don't have the historical background to rememeber where , what and why
the code is dynamically changed.

| The idea is "I want to modify the zope core in a way that survives 
| version to version, yet does not impose a specific use case on all 
| zope users".

The good pattern for handling this is to create a new class that extends
the core classes that provide almost the functionality you want.  Then,
in your part of the database, create an instance of your class instead
of the built-in core class.

Specifically for your case, extend the basic UserFolder class to create
instances of your custom User class instead of the built-in one.  It
would be good if the UserFolder allowed you to parameterize it so you
could simply say "use this User class", but in the absence of that
foresight, you can extend the UserFolder clas.

HTH,
-D

--
Whoever loves discipline loves knowledge, but he who hates correction is
stupid.
        Proverbs 12:1
 
www: http://dman13.dyndns.org/~dman/            jabber:
dman at dman13.dyndns.org