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

> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > don't need primitive types.
> 
>   I disagree with this. (Unless you are ready to add operator overloading.)

I am. I definitely would want operator overloading. I've never seen a 
good argument against it..."you can make the plus operator multiply" is 
not a good argument. I can make a "plus()" method that multiplies as 
well...I can also do a lot of useful things with the ability to use 
operators with my own types.


> > Just straight public inheritance, probably with categories 
> > and interfaces.
> 
>   I have no idea what "categories" are,

Additions to the interface of a class after the main class has been 
defined. For example, a vector class may have an OpenGL category that 
implements methods useful for using vectors with OpenGL, but which isn't 
part of the core functionality of the class, and which does not work as 
a subclass.


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


> > I'm undecided about private/protected access. They would 
> > be a good thing to have from the language design point of view, but 
> > aren't really necessary...
> 
>   They are necessary, believe me... ;)

Sorry, but I don't. I've never accidentally tried to access a private 
member. They do serve a documentation purpose, but IMO if a language has 
them, they should be defined in a separate place, with only the public 
interface in a header file. But for POV, this would be too restrictive 
and complex, IMO.


>   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 this is too drastic, then the language would work so that a public
> member variable can be moved to the private part and overloaded with
> an accessor method (which is used in the same way as when accessing
> the variable directly).

I have some misgivings about the idea of accessor methods of this type, 
though it makes more sense if you have no public variables. I've 
considered this approach for Ember, which could (eventually) optimize 
the overhead away.


> class Foo { public: int i(); private: int i_; }
>   Accessing 'i' would still be the same (ie. eg. "instance.i") but after
> the change it calls the method i() instead of reading the variable
> directly.

There's also a "modifier" feature I've seen...in Ruby, I think. 
Basically you define a "myMember=" method, and this:

myObject.myMember = foo;

is equivalent to:

myObject.myMember=(foo);

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