• Mark Evans (1/1) Mar 17 2003 http://okmij.org/ftp/Computation/Subtyping/
• Bill Cox (4/7) Mar 18 2003 Nice artical. I especially liked a sub-link:
• Sean L. Palmer (32/39) Mar 19 2003 In practice, code reuse is necessary; how many times do you want to hav...
• Bill Cox (14/20) Mar 19 2003 Yeah, me neither. I don't know what the solution is, but it clear that

Mark Evans <Mark_member pathlink.com> writes:

http://okmij.org/ftp/Computation/Subtyping/

Bill Cox <bill viasic.com> writes:

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

"Sean L. Palmer" <seanpalmer directvinternet.com> writes:

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

Bill Cox <bill viasic.com> writes:

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