Thread overview | ||||||
---|---|---|---|---|---|---|
|
March 18, 2003 Trouble with OOP | ||||
---|---|---|---|---|
| ||||
http://okmij.org/ftp/Computation/Subtyping/ |
March 18, 2003 Re: Trouble with OOP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mark Evans | Mark Evans wrote: > http://okmij.org/ftp/Computation/Subtyping/ > > Nice artical. I especially liked a sub-link: http://okmij.org/ftp/Computation/Subtyping/References.html#OOP-problems Bill |
March 19, 2003 Re: Trouble with OOP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Cox | In practice, code reuse is necessary; how many times do you want to have to type the same interface over and over? Even worse, how many times do you want to have to make glue functions that bind an interface to some implementation? The more times you have to type the same thing, the harder it is to ever change that thing. This is why I dislike redundancy in programming languages. It inhibits refactoring. In fact it's almost completely diametrically opposed to refactoring. The only redundancy in the program should be in the unit tests. Ok, maybe a teeny bit of redundancy in cases that people clearly are expected to get wrong. But redundancy for redundancy's sake quickly leads to monstrosity. I'd rather the language find some other way to make it impossible to mismatch types than to have to declare type at both ends. Even if you go through the trouble of making an interface and gluing all your objects which implement this interface to some implementation, you'll find that making an implementation that has enough information about the outside world to actually work usually involves data duplication and proliferation of parameters in its interface. Often this bloats your implementation objects to the point where they're almost as complex as the fullblown composite object, which in turn gets even larger. I don't think we'll see these problems go away anytime soon. Most programmers aren't even aware of the problems because they're subtle. Languages aside from Eiffel don't give you ways to conveniently bind interfaces to separate implementations. Parametric polymorphism is just now gaining industry support, and it's not a cure-all either; it merely addresses part of the problem. I get the feeling that the current generation of languages doesn't address the things that real programmers are actually trying to do. Maybe the nice researchers working on Vault have the answers. I sure don't. Sean "Bill Cox" <bill@viasic.com> wrote in message news:3E77097C.20308@viasic.com... > > > Mark Evans wrote: > > http://okmij.org/ftp/Computation/Subtyping/ > > > > > > Nice artical. I especially liked a sub-link: > > http://okmij.org/ftp/Computation/Subtyping/References.html#OOP-problems > > Bill |
March 19, 2003 Re: Trouble with OOP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean L. Palmer |
Sean L. Palmer wrote:
> I get the feeling that the current generation of languages doesn't address
> the things that real programmers are actually trying to do.
>
> Maybe the nice researchers working on Vault have the answers. I sure don't.
>
> Sean
Yeah, me neither. I don't know what the solution is, but it clear that code like:
class Foo : Bar {
myOveride() { return true; }
}
doesn't explain what the heck is going on. OOP has lead to some of the most obscure code I've ever had to read. Class libraries like MFC are almost useless without full source. Sometimes I have to look 3 or 4 levels in the class hierarchy up to find out what's happening.
Not that OOP is a bad thing... Certainly it's an improvement over plain old C. As much as I hate reading MFC source, it's better than the old Windows C source.
Bill
|
Copyright © 1999-2021 by the D Language Foundation