In article <40388944@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> > Interfaces are not obsolete. As for abstract classes...what are you 
> > talking about?
> 
>   Interfaces are obsolete of you can make abstract classes. And why
> wouldn't you (unless you want to make the language so that it does
> not support virtual functions, which would limit its OO capabilities
> by a whole lot).

Argh...forget about virtual functions. They are an artifact of C++, 
which does everything statically by default. I specifically said no 
static binding. No virtual functions, because everything is dynamically 
bound.


>   A class is abstract if it has pure virtual functions (that is,
> the class does not implement the virtual function(s) and thus cannot
> be instantiated because of this; it can only be used through
> inheritance so that the derived class implements the virtual
> function(s) in question).

Again, I'm talking about single inheritance. Multiple inheritance is not 
necessary, and is needlessly complex. Abstract classes are not as useful 
in single inheritance models, interfaces cover their functionality. 
Interfaces render multiple inheritance + multiple abstract root classes 
obsolete, not the other way around.


> > Sorry, but I don't. I've never accidentally tried to access a private 
> > member.
> 
>   That's right. *You*. But that's ok only for as long as you don't
> distribute that library of yours containing public member variables...
> Someone will inevitably use it in the wrong way and his code can then
> break with an updated version of the library.

That's their fault for screwing around with stuff that's not documented 
as the public interface. They could do the same thing with preliminary 
code that may eventually be public interface, but which isn't nailed 
down yet. But I've seen enough people trying really hard to do really 
stupid things to get your point...fine if they are the only victims of 
their stupidity, but if I have to work on their code or use their 
software...


>   Well, that's just a question of implementation of the interpreter/compiler.
> If you can implement the interpreter so that the private part does not need
> to be specified at the same place as the public part, good thing. (In C++
> this is not possible for technical reasons, but in an interpreted
> scripting language it may very well be possible.)

Oh, it's possible for C++, just more complex to compile. The compiler 
would have to collect both definitions before it could compile anything 
using more than a pointer or reference to the type. Probably be best to 
have special directives specifying the files that have the 
implementation and interface. Or tie the class names to the file names, 
like Java.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message