Christopher James Huff <cja### [at] earthlinknet> wrote:
> I am. I definitely would want operator overloading. I've never seen a 
> good argument against it...

  Ask Java worshippers. They know. ;)

  I personally am all for operator overloading in the same way as you,
and it's one thing why I hate Java so much.

> > but interfaces are obsolete.
> > If you want to make an "interface", just make an abstract class.

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

  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).
  If every member function it has is purely virtual, then it's basically
the same thing as an interface. (This is how "interfaces" are done in C++
if you *really* need to make one.)

> >   They are necessary, believe me... ;)

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

> They do serve a documentation purpose

  That's not their purpose at all. Public and private parts have clear
maintainability, abstraction and safety purposes.
  If you can't use the library in the wrong way (ie. the compiler does
not allow you to), then you will not use it in the wrong way.

> but IMO if a language has 
> them, they should be defined in a separate place, with only the public 
> interface in a header file.

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

> But for POV, this would be too restrictive 
> and complex, IMO.

  What do you mean "restrictive"?
  That's like saying #local is too restrictive. It doesn't make sense.

  The private part of a class has the same visibility purpose as for
example #local has: It's safer to use #local whenever possible than
always using #declare.

> >   I would even go so far that member variables are always private (ie.
> > you *can't* make them public).

> I wouldn't care for this. Think of vector member access...vec.x, vec.y, 
> etc...vec.x() just adds more visual noise.

  If you read my article completely I suggested adding support for calling
member functions without parentheses (supposing they don't take parameters).
There's nothing problematic with that.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message