Why is it _setObject(), and why is it undocumented
I have a few tutorials / How_to's on zope.org. And sometimes I get some interresting mails because of that. Somebody asked me today why _setObject() has that name, as it is used in many products, and thus ought to be an interface method. And called something like "setObject()" or "manage_setObject()" And also he didn't understand why it wasn't documented anywhere. So why is that? does anybody know? regards Max M
maxm wrote at 2003-1-31 00:35 +0100:
I have a few tutorials / How_to's on zope.org. And sometimes I get some interresting mails because of that.
Somebody asked me today why _setObject() has that name, as it is used in many products, and thus ought to be an interface method. And called something like "setObject()" or "manage_setObject()" And also he didn't understand why it wasn't documented anywhere. "_setObject" has an "_" because it is a "private" method which should not be called by TTW code.
It should be documented in the ZDG. If it is not, file a collector issue (documentation request). Dieter
Dieter Maurer wrote:
"_setObject" has an "_" because it is a "private" method which should not be called by TTW code.
Ok ... but that is not really what is meant by a private method. Usually a private method is used purely as a mean of implementation. And should never be called from other objects. This is not the case here, as the method is clearly a part of the api. That is why I find it missleading. regards Max M
From: "maxm" <maxm@mxm.dk>
Usually a private method is used purely as a mean of implementation. And should never be called from other objects. This is not the case here, as the method is clearly a part of the api.
Well, no, it isn't really, since it starts with _. However, python do not in itself enforce privacy, so therefore you *can* call it. But by starting it with _ it is private by convention. Zope also implements some of this privacy, so you can't call it from Python scripts and so on.
Lennart Regebro wrote:
From: "maxm" <maxm@mxm.dk>
Usually a private method is used purely as a mean of implementation. And should never be called from other objects. This is not the case here, as the method is clearly a part of the api.
Well, no, it isn't really, since it starts with _. However, python do not in itself enforce privacy, so therefore you *can* call it. But by starting it with _ it is private by convention. Zope also implements some of this privacy, so you can't call it from Python scripts and so on.
Sorry but I don't see that. How on earth are you suposed to add an object to an objectmanager, if you don't use _setObject() ?? Every time you make an object that subclasses ObjectManager, wich is often, you need to use that function. That can hardly be called private. -- hilsen/regards Max M Rasmussen, Denmark http://www.futureport.dk/ Fremtiden, videnskab, skeptiscisme og transhumanisme
From: "Max M" <maxm@mxm.dk>
Sorry but I don't see that. How on earth are you suposed to add an object to an objectmanager, if you don't use _setObject() ??
You use another method that in turn calls _setObject. Now you may argue that there should be a public method that does the same, but that is strictly another question.
Every time you make an object that subclasses ObjectManager, wich is often, you need to use that function. That can hardly be called private.
It depends on what you define as "private". I have never seen the use of shielding a method from future subclasses of a class. It only causes problems and unessecary restrictions. For me, private means that you shield it from use outside of the object, not from your subclasses.
Lennart Regebro wrote at 2003-2-1 15:48 +0100:
From: "Max M" <maxm@mxm.dk>
Sorry but I don't see that. How on earth are you suposed to add an object to an objectmanager, if you don't use _setObject() ??
You use another method that in turn calls _setObject.
Now you may argue that there should be a public method that does the same, but that is strictly another question.
Every time you make an object that subclasses ObjectManager, wich is often, you need to use that function. That can hardly be called private.
It depends on what you define as "private". I have never seen the use of shielding a method from future subclasses of a class. It only causes problems and unessecary restrictions. For me, private means that you shield it from use outside of the object, not from your subclasses. Some more notes about "private".
"private" as used in Zope is not the "private used in C++ (or Java)". In Python, "C++'s private" is emulated by names starting with "__" (and not ending in "__"). Such attributes can not be (easily) accessed by subclasses. Zope's private means "cannot be used by TTW code". Dieter
On Sat, 2003-02-01 at 12:16, Max M wrote:
Lennart Regebro wrote:
From: "maxm" <maxm@mxm.dk>
Usually a private method is used purely as a mean of implementation. And should never be called from other objects. This is not the case here, as the method is clearly a part of the api.
Well, no, it isn't really, since it starts with _. However, python do not in itself enforce privacy, so therefore you *can* call it. But by starting it with _ it is private by convention. Zope also implements some of this privacy, so you can't call it from Python scripts and so on.
Sorry but I don't see that. How on earth are you suposed to add an object to an objectmanager, if you don't use _setObject() ??
Every time you make an object that subclasses ObjectManager, wich is often, you need to use that function. That can hardly be called private.
The problem here are not the subclasses of OM, but all objects that are supposed to be added to an objectManager. There is no other method in the OM class to add an object to an OM instance so it's obviously not a "private" method (in the "others shouldn't be calling it" sense). All objects that are designed to be added to an OM instance call it either in their __init__ or in a factory function (like manage_addSomething()) Let's not confuse this with TTW public methods. _setObject should obviously not be made TTW accessible (let alone TTW public :-), but it should be a "public" method, that is, have a sensible name and be specified in an eventual IObjectManager interface -- Ideas don't stay in some minds very long because they don't like solitary confinement.
Leonardo Rochael Almeida wrote at 2003-2-3 18:42 -0200:
... Let's not confuse this with TTW public methods. _setObject should obviously not be made TTW accessible (let alone TTW public :-), but it should be a "public" method, that is, have a sensible name and be specified in an eventual IObjectManager interface I think an additional reason for the "_" in the name of "_setObject" is to prevent acquisition.
With acquisition, you may not set the object where you think you will. Dieter
Dieter Maurer <dieter@handshake.de> wrote:
I think an additional reason for the "_" in the name of "_setObject" is to prevent acquisition.
With acquisition, you may not set the object where you think you will.
Ah, that's a very good argument. (Another reason why implicit acquisition is bad... Long live Zope 3!) Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
maxm <maxm@mxm.dk> wrote:
I have a few tutorials / How_to's on zope.org. And sometimes I get some interresting mails because of that.
Somebody asked me today why _setObject() has that name, as it is used in many products, and thus ought to be an interface method. And called something like "setObject()" or "manage_setObject()" And also he didn't understand why it wasn't documented anywhere.
So why is that? does anybody know?
The weight of history I guess. I agree that there should be a setObject() method, it's a fundamental API of ObjectManagers. Same thing for _getOb(), even if __getitem__ often is enough (it has some WebDAV magic though). Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
participants (6)
-
Dieter Maurer -
Florent Guillaume -
Lennart Regebro -
Leonardo Rochael Almeida -
Max M -
maxm