Thorsten Froehlich <tho### [at] trfde> wrote:
: Hmm, you seriously want to call the C++ STL anything else but "spaghetti
: code"?  ;-)

  I don't know. From the point of view of the user of the library it has
a pretty clever and abstract interface and the division into modules looks
good.
  I have never looked into the source code of any STL implementation, though.

: so needed for a C++/Java style implementation allowing references (no
: pointers, pleeeeeeeeeeeease!)?

  References are pointers.
  The syntax for references usually doesn't allow you to make so many things
with them than with pointers, but basically they are the same thing.
  So it doesn't matter if we call them references or pointers. The important
thing is what do we allow and what we don't to do with them.

  In C++ pointers are very free (and thus dangerous) and references are very
strict. For example, you can't assign a new value to a reference. In Java
references are more free than in C++ because you can assign the references
to point to new objects. This is an important feature because without it
it wouldn't be possible to make lists and so on.
  I have always said, that "it's not true at all that there are no pointers
in Java, all the contrary: In Java _everything_ is a pointer".

:>   Just think about the possibilities Include files using common abstract
:> base classes could be used more or less seamlessly together. Clear
:> interfaces will make them easy to use and maintain, and information hiding
:> will help avoiding all namespace trashing problems (there's nothing more
:> annoying than two include files using identifiers with same names).

: For whom?

  From other include files. From the user.

: Great argument!  Who cares if someone can read a POV scene and learn from
: it, why should there be new novice users of POV-Ray?

  So you say that we shouldn't give powerful tools to people who wants them
only because newbies can't read the code?

:> : Would it be fast to parse?
:>
:>   Would it be slower? Does it matter?

: Yes (answering your second question).

  So if it does matter, then we should remove the #macros. They are very slow.
Specially when included. Also #while-loops are usually slow. What about
big triangle meshes and bicubic patches? They are slow to parse so we should
remove them.

  No, I still think that it doesn't matter. Features are not left out because
they are slow to parse.

: Hmm, rejecting a jet engine for a car does not imply rejecting a gasoline
: engine!  There are features that have more relative value compared to their
: cost while others have a lower relative value compared to their (possibly
: very high) cost. Note the "relative".

  Yes, there's a cost in designing a OO-pov language. But that's not a cost
for the user. The users will probably not notice much difference. Someone
may sometimes post a weird OO-pov code in text.scene-files, but they are
usually hard to read anyways ;)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message