Warp wrote:

> (the principle of abstraction, an extremely important principle in good
> programming).

I rest my case.

-- 
Ken Tyler

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:40348068@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > new ColoredSphere
> > new ColoredSphere
>
> > new Color.White
>
>   Aaargh! No, no and no.
>
>   The fact that you must fill your code with the 'new' keyword in Java
does
> not mean it's a good thing.
>   Why force the user to do that? In all those cases the 'new' keyword is
> obsolete. It contributes nothing to the code.

I see what you're thinking of on this. I think it is there for clarity -- 
the compiler could always check to see what has been defined and decide to
either create a  new class there or use the reference. I believe (and this
is just a personal thing) that the readability of the code is just as
important as the execution of the code because, even if you write a program
in a vacuum without anybody else seeing it, /you/ still have to look at your
code later. Thing is, I see people write really hard-to-read code often and
I figure it could be: a. they don't want you to understand their code, b.
they think it will go magically faster if it is all scrunched together and
the variable names are shorter, c. they want to put as much on the screen as
they can, d. their fingers really hurt and typing causes physical distress,
e. they are so amazingly smart that they can instantly conceptualize the
code no matter how obfuscated it is, or f. they just have bad habits and
don't care. I'm guessing f. :-)

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> I see what you're thinking of on this. I think it is there for clarity -- 
> the compiler could always check to see what has been defined and decide to
> either create a  new class there or use the reference.

  The reference to what?
  The thing after 'new' is a type. How can you make a reference to a type?
Where should the reference point to?

  You can make your scripting language interpreter so that instances are
always created dynamically for simplicity (that way you don't have to
make the distinction between a local variable and a reference because
everything is a reference, like in Java). However, the 'new' keyword
does not contribute anything to this. It's obsolete and can be
completely left out without the expressive power of the language
being degraded.

  Have you ever wondered why you are not forced to define all your
objects in POV-Ray inside object{} blocks, why you are not forced to
put all your material and texture statements into material{} and
texture{} blocks, etc?
  Because forcing the user to write something unnecessary is only
a burden, not a help.

  Even more, object{}, material{} and texture{} are sometimes necessary.
However, I can't imagine a situation where 'new' would be necessary
(assuming we are dealing with a language where all class instances
are created dynamically, as in Java).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   One of the basic features of an object-oriented language are modules.

> FWIW, there are many modular languages that aren't OO.

  So?
  I didn't say modules are a sole feature of OO languages. I said that
modules are a minimum requirement for a language to be OO.

  A good example of a modular language which is not OO is modula. It has
modules (created not very surprisingly with the keyword 'module') which
contains member variables, member functions, private and public parts, etc.
However, since it does not have (AFAIK) inheritance and dynamic binding
it's not an OO language, only a modular one.

> >   A second basic feature of an OO language is inheritance.

> FWIW, there are many OO languages that don't support inheritance.

  Then they are not object-oriented languages. Some kind of inheritance is
a basic feature of object-oriented languages.
  The whole idea of object-orientedness is that you can have a hierarchy
of objects (from more abstract to more specific). If you can't build such
hierarchy, then it's not object oriented.

> Inheritance is something different, designed to 
> allow you to share code between different parts of your program, to ease 
> maintenance.

  Nope, that's a way too narrow way of defining inheritance.

  It's true that inheritance can (and should) be used to group common
code into a single module. However, that's not the only (and depending
on who you ask not even the most important) reason for inheritance.
  There are other ways of grouping common code into single modules,
such as composition (ie. a class having another class as member variable).
You don't necessarily need inheritance for this.

> >   A third basic feature, related to inheritance, is dynamic binding. 

> Dynamic binding is not really necessarily related to inheritance, and 
> vica versa. That's just an artifact of how popular OO languages handle it.

  Lack of dynamic binding would make inheritance more or less obsolete.
If you are going to use inheritance without dynamic binding you could
as well use compositionality instead.

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

"Warp" <war### [at] tagpovrayorg> wrote in message
news:40350372@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > I see what you're thinking of on this. I think it is there for
clarity -- 
> > the compiler could always check to see what has been defined and decide
to
> > either create a  new class there or use the reference.
>
>   The reference to what?
>   The thing after 'new' is a type. How can you make a reference to a type?
> Where should the reference point to?

I made everything objects. I don't know what I was thinking there, though -- 
it should be new Color(Color.White), not new Color.White. I'm braindead
today.

>   You can make your scripting language interpreter so that instances are
> always created dynamically for simplicity (that way you don't have to
> make the distinction between a local variable and a reference because
> everything is a reference, like in Java). However, the 'new' keyword
> does not contribute anything to this. It's obsolete and can be
> completely left out without the expressive power of the language
> being degraded.

To create the object dynamically without the new keyword, the interpreter
would need to look up whether what proceeds it is a Class or something that
the user already defined. That would not effect small scenes, but in scenes
with hundreds of thousands of objects, it would show in the parse time. By
using new, the interpreter /knows/ that what follows it is a class.

>   Have you ever wondered why you are not forced to define all your
> objects in POV-Ray inside object{} blocks, why you are not forced to
> put all your material and texture statements into material{} and
> texture{} blocks, etc?

Nope. You're right -- object is implied.

>   Because forcing the user to write something unnecessary is only
> a burden, not a help.
>
>   Even more, object{}, material{} and texture{} are sometimes necessary.
> However, I can't imagine a situation where 'new' would be necessary
> (assuming we are dealing with a language where all class instances
> are created dynamically, as in Java).

I think it would be a really good idea to make everything an instance of a
class. I'm thinking more like Smalltalk where there are no primitives
(that's what I was thinking when I did the Color.White screw-up -- no
primitives). If the parser is written correctly, this should not affect
parse time. However, what I was thinking was more something that isn't like
a scripting language, but instead, enables structured OO programming for
complex logic and true abstraction.

Post a reply to this message

>   Then they are not object-oriented languages. Some kind of inheritance is
> a basic feature of object-oriented languages.

I'm not entirely sure that's true. The concept of an object does not implicitly
require inheritance, since the principles of modularity with private states etc
can still apply, and as such a language can be oriented about objects without
needing inheritance. Though all the OO languages I know of do have inheritance.

I'm trying to thing back to the OO analysis and design course I did on my
degree, but I can't honestly remember whether it considered inheritance to be
fundamental to OO...

> > Inheritance is something different, designed to
> > allow you to share code between different parts of your program, to ease
> > maintenance.
>
>   Nope, that's a way too narrow way of defining inheritance.
>
>   It's true that inheritance can (and should) be used to group common
> code into a single module. However, that's not the only (and depending
> on who you ask not even the most important) reason for inheritance.

I agree. For example, the only reason I'm planning to implement inheritance is
so that I can have an interface class with virtual functions. No shared code
whatsoever.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> To create the object dynamically without the new keyword, the interpreter
> would need to look up whether what proceeds it is a Class or something that
> the user already defined. That would not effect small scenes, but in scenes
> with hundreds of thousands of objects, it would show in the parse time. By
> using new, the interpreter /knows/ that what follows it is a class.

  Believe it or not, there are faster ways of searching than linear search.

  Even if you have 4000 millions of names, you can find a specific one
by doing at most 32 comparisons.
  In the same way, adding a new name to the set of existing names requires
at most 32 comparisons and other operations.

  Besides, what does it help to tell the interpreter that "what follows is
a type"? By that you can at best just cut the amount of items to search
to half (to 2000 millions in the example above).

> I think it would be a really good idea to make everything an instance of a
> class.

  There's a reason why in Java everything is not an instance of a class.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Tek <tek### [at] evilsuperbraincom> wrote:
> >   Then they are not object-oriented languages. Some kind of inheritance is
> > a basic feature of object-oriented languages.

> I'm not entirely sure that's true. The concept of an object does not implicitly
> require inheritance, since the principles of modularity with private states etc
> can still apply, and as such a language can be oriented about objects without
> needing inheritance. Though all the OO languages I know of do have inheritance.

  Don't confuse modules with object-orientedness.

  As I explained previously, modules are a minimum but not sufficient
requirement for an OO language.
  If you have modules with no inheritance and no dynamic binding what
you have is a modular language, not an OO one. Modula3 is an example of
this.

> I agree. For example, the only reason I'm planning to implement inheritance is
> so that I can have an interface class with virtual functions. No shared code
> whatsoever.

  So basically you will have interfaces (such as in Java) but no inheritable
classes?
  The problem with that is that it forces code repetition, which is not
good (IMHO this is a bad problem in Java interfaces). Besides forcing the
user of the interface to implement things which may be useless, it makes
it too easy to break the true "is-a" relation between base and derived
classes (in other words, when you make code which handles objects of
the type of a certain interface you just have to trust that the inherited
class implements all of its methods properly; you can't force a certain
method to work always in a certain way).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   Then they are not object-oriented languages. Some kind of inheritance is
> > a basic feature of object-oriented languages.

> This isn't correct. There are, for example, delegation-based OO 
> languages, wherein you say "Anything I don't handle, that other class 
> over there handles", but it's not an inheritance heirarchy as such. It's 
> merely delegation.

  Who defines that object-orientedness may not have inheritance?

  The "is-a" (and "has-a") relation between classes is a fundamental
property of object-orientedness.

> No, this is not correct. While it's true that most popular 
> object-oriented languages support inheritance, you can have OO languages 
> without inheritance.

  In what basis can you call it an OO language?
  Having modules is not sufficient.

> Imagine Java with no inheritance of functions, only "inheritance" of 
> what java calls interfaces. Does it stop being "object oriented"? Most 
> people working in the field of designing programming languages I think 
> would say "no, it's still OO".  It still has objects, dynamic dispatch, 
> memory management, classes, instances, etc. Just not inheritance.

  If you inherit class X from class Y you are saying "X is a Y" (that is,
it implements everything Y implements and behaves like Y).
  Y may be completely abstract, meaning that it does not implement anything
itself. However, deriving a class from it still means that the derived
class "is a Y".
  If you make a class which implements an interface you are doing inheritance.
Limited perhaps, but still inheritance.

  (By the way, what does memory management have to do with OO?)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:4035e6de@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > To create the object dynamically without the new keyword, the
interpreter
> > would need to look up whether what proceeds it is a Class or something
that
> > the user already defined. That would not effect small scenes, but in
scenes
> > with hundreds of thousands of objects, it would show in the parse time.
By
> > using new, the interpreter /knows/ that what follows it is a class.
>
>   Believe it or not, there are faster ways of searching than linear
search.

Yep, I know; I spent an entire summer building AVL trees and heaps. But it
is /still time/ and, in a loop, that time adds up.

>   Even if you have 4000 millions of names, you can find a specific one
> by doing at most 32 comparisons.
>   In the same way, adding a new name to the set of existing names requires
> at most 32 comparisons and other operations.

32 comparisons for /one lookup/. Multiply that by, say, 100,000 lookups for
fur.

>   Besides, what does it help to tell the interpreter that "what follows is
> a type"? By that you can at best just cut the amount of items to search
> to half (to 2000 millions in the example above).

In a loop, that makes a difference.

> > I think it would be a really good idea to make everything an instance of
a
> > class.
>
>   There's a reason why in Java everything is not an instance of a class.

I think everything should have been. It was just a programmer's decision to
do that, probably because of their C/C++ experience. However, it is
certainly true that if all primitives were represented by a class, it would
take more memory, and even though it might only take a slight bit more
memory, with hundreds of thousands of instances that can show as well so it
might be a good idea to use primitives in a ray-tracing context anyway.

Post a reply to this message