On Oct 3, 5:13 pm, Carl Banks <pavlovevide...@gmail.com> wrote: > On Oct 3, 3:04 pm, Rock <rocco.ro...@gmail.com> wrote: > > > No, I was just working with a normal library > > class which was supposed to be derived. So that's what I did, but in > > the process I found myself needing to create an instance variable and > > it dawned on me: "how do I know I'm not clobbering something > > here???" ... I'd have to look at the docs, right? But I still wasn't > > sure ... so, then I thought "let's look at the source", and then I > > found out. But! It took me some time to make sure, and I was puzzled > > as well. I mean, what if I have no source to look at? What if the > > library I'm using doesn't realase the source, or what if I just can't > > get my hands on it for some reason or another? > > > That was a big disappointment with Python for sure. Somehow PHP makes > > me feel a little safer, in that respect at least. > > Name collisions are only one of several pitfalls that can happen when > you subclass a third-party clasa. Another pitfall is uncertainly over > which methods a certain behavior is implemented, which is something > you can't determine from the interface alone, in any language I'm > aware of. If you want to override such a behavior you have to look at > the class's implementation to find out how. Point is, if Python > corrected this "defect", you still wouldn't be "safe" because there > are other dangers, which exist in other langauges, too. > > Now, if a class is specifically designed to be subclassed by third- > party users, and it's not using name mangling or some other way to > avoid name collisions, then I would call it defective. >
Yep, and a well-designed library can go a long way toward avoiding name collisions simply by providing an API that facilitates logical extensions. If a library knows when it needs to delegate to a caller, it can have a callback mechanism. If a library knows how subclasses are likely to change its state, it can provide an API that lowers the temptation to muck with internals. -- http://mail.python.org/mailman/listinfo/python-list
