RE: [Zope] Re: Modifying __bases__
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derrick Hudson Sent: Wednesday, May 25, 2005 9:55 AM To: zope@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: [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[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: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Modifying __bases__
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.
The phrase encodes a bunch of folklore and geek sentiments in a
humourous ("half in fun but full earnest") meme:
- Monkey patching can invalidate documented APIs and behavior; in
this sense, a monkey patch is "taking out a loan" which will be
repaid later, either by the original perpetrator or by some other
poor schmuck ("Vinny's crowbar *hurts*.")
- A monkey patch is often a pure expedience: "Rather than redo *my*
software to correct a problem *I* injected, I'll just bash the base
software to work around it." In this mode, it is a sign of poor
design or quality in the perpetrator's code.
- Sometimes, a monkey patch is the only way to address a particular
issue without updating the underlying software (most "hotfixes" for
security issues involve monkey patching). In this mode, the patch
is a sign that the underlying software has a bug, hard-wired some
policy that it shouldn't have, or is otherwise defective.
> What is morally wrong with modifying live objects in a dynamic language
> to achieve desired functionality?
> 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".
In general, the use case is fine; we would prefer to address it by
making the core software more flexible / configurable, such that it is
not necessary to monkey patch.
Tres.
- --
===
Tres Seaver [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCj1B9+gerLs4ltQ4RAmWjAJ97Qvr2xnv5qsCRYC7it4UtHdxvewCg2Zu9
ADCK48Ly7ZMUWbV8E6wS6Q0=
=3SS5
-END PGP SIGNATURE-
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
