Unified Type/class

[Pedro Rodriguez]

"Steven Majewski" <sdm7g at virginia.edu> wrote:



> 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.
> 

Yes.

> 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.

Valid points. 
But I think that you can even restrict this capability on classes by
providing the apropriate metaclass, something like 'FinalType' with
a semantic close to 'final' keyword in Java.

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

I have been told that this feature of Objective-C was a real strength 
when comparing C++/Objective-C, since your may, for example, provide
a patch to base class without requiring to compile all applications
that relied on it.

>  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. )
> 

If you have :
    Foundation  
        |
        V
      AppKit <- LoadingWidget Support
Why is this support considered as part of the foundation ?

>  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.
> 

Yes. Trying to create a package for AOP requires this feature.
But you have to be aware there are some restrictions that can be
put on what you can actually do.

>  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.
> 

I clearly understand your point, but as a designer I will probably
consider that creating the extra class will clearly express what
the requirements are. 

I won't try to alter something I don't control. If new features
are required, I will make them part of my framework.

There is one exception to this rule : fixing bugs on base packages.
And even so, I think that the patch should come frome the provider of 
the faulty package. You may provide the patch as part of your application,
and have it do the proper work (like checking if the patch is
required or not). This could also serve as a possibility to centralize
all the patches in one place, preventing reinventing the wheel, and 
possibly, letting you also get access to new feature that will available 
in the future (ex : rot13() will be avail in next python release, but 
you can safely include patch XXX if you need it now).


>  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.
> 

Don't get me wrong, I don't want to rule out the ability to modify
things, but inserting 'behavior UPSTREAM' is fine to me as long as
the downstream impacted is within my control.
(Consider I am an old fashioned person that doesn't want something
 messing my believes ;)

> -- Steve Majewski
> 
> 
> 

Your comments were appreciated. Thanks Steve.
-- 

Pedro