Home Original page

Unified Type/class

Steven Majewski sdm7g at Virginia.EDU
Sat Jan 26 14:25:24 EST 2002 
On Sat, 26 Jan 2002, Pedro Rodriguez wrote:

> "Jason Orendorff" <jason at jorendorff.com> wrote:
>
> > Pedro Rodriguez wrote:
> >> CORE language provides some features, if anyone (L1, L2) are allowed to
> >> alter those features, what should Appl. developper expect from the
> >> CORE. Even adding a method could be a problem. I consider that, when
> >> requiring to augment CORE features, it should be dealt as part of the
> >> library framework and not by altering the CORE directly.
> >
> > Note that this is a general bit of engineering good sense.
>
> Agreed. The questions are
> - why did Ruby team allow this feature on standard classes ?
>   (maybe 'str' is not a class on which Ruby interpreter relies ?)

Being able to modify existing classes is often very useful.

I'm not sure that it's a problem in Python that the capability is
restricted to classes coded in Python. In cases where you need
to substitute for a built in capability, you can often use python's
module and namespace mechanism's to do the substitution. The main
problem is that you can't redirect the interpretation of literals:
If you want to replace the builtin string of list classes, there's
no easy way to get "quotes" or [ list, square, brackets ] to
become a constructor for your replacement classes.

 Objective-C supports categories, which is a way of adding methods
to existing classes.

 One use is to streamline some of the base classes. If another
package requires new capabilities from one of the basic classes,
it can add those methods -- they don't all have to be supported
in the foundation classes. ( Example: in OSX/NextStep, the GUI
framework "AppKit" needs some support from the Foundation classes
for loading widgets, but this extra code isn't added unless
you use AppKit. )

 Another use is programmer convenience and the ability to package
things by something other than classes. This is part of the idea
of Aspect Oriented Programming: that some code may be more readable
(and writable) if it's packages as an aspect or facility that
cuts across classes.

 Another is in customizing default behaviour. You may have an
existing library of classes built from a base class, and you
need a change or added feature to be available to all of the
subclasses, so you need to insert it in the parent class.
You can also somethimes do this by modifying the inheritence
order to insert a modified class in between parent and children
classes, but that's more confusing to follow.

 Yes -- there would be problems if you had two different libraries
that both wanted to add the same method to an existing class.
That a definite limit to the capability. But the benefits outweigh
that one limitation. The rule should be not to use that feature
if subclassing or separate modules or some other facility can
solve the problem. But sometimes, you absolutely have to insert
behavior UPSTREAM so that it gets propagated to everything downstream.

-- Steve Majewski
More information about the Python-list mailing list