Sebastián E. Peyrott wrote:

>>Every decade seems to have its programming buzzword:
>>
>>60's: artificial intelligence
>>70's: structured programming
>>80's: user-friendly
>>90's: object oriented programming
>>00's: metaprogramming 
> 
> Then, it may be in D's best interest to start thinking
> which will be the 10's buzzword ;)

I am afraid it will be: "virtualization"

--anders

Walter Bright wrote:
> The trouble with OOP is, well, not everything is an object. For example, take the trig function sin(x). It's not an object. Of course, we could bash it into being an object, but that doesn't accomplish anything but obfuscation.
> 

sin(x) isn't an object, but x is, and sin can be made a property of that object.

Deewiant wrote:
> Walter Bright wrote:
>> The trouble with OOP is, well, not everything is an object. For example, take the trig function sin(x). It's not an object. Of course, we could bash it into being an object, but that doesn't accomplish anything but obfuscation.
>>
> 
> sin(x) isn't an object, but x is, and sin can be made a property of that object.

How would you define a binary mathematical function then? atan2(y,x) and binominal(n,k) for instance.

/Oskar

Walter Bright wrote:
> "Craig Black" <cblack@ara.com> wrote in message news:dun68p$30kv$1@digitaldaemon.com...
> 
>>A lot of the bias towards OOP purism comes from Java vs. C++ comparisons, much more convincing than Anything vs. D.  Hopefully the simplicity and power of D can help to eliminate OOP purism.
> 
> 
> The trouble with OOP is, well, not everything is an object. For example, take the trig function sin(x). It's not an object. Of course, we could bash it into being an object, but that doesn't accomplish anything but obfuscation.

That's because we've been taught math in a procedural way ;)
Ideally, x, the angle, would be an object, and sin is a method on that object.
However, I think that we're so used to think about math functions in a procedural way, so it's better they stay procedural.

Like you said, it'll be a bit confusing if it was an object, but that's not because it can't be an object, but mainly because that's not how we think about it.


> Sometimes, I think C++ went hard over in the opposite direction - nothing is an object. OOP programming seems to be regarded as "oh, so 90's" by the modern C++ crowd.

C++ doesn't really support OOP .. it's just a myth :(

Oskar Linde wrote:
> Deewiant wrote:
> 
>> Walter Bright wrote:
>>
>>> The trouble with OOP is, well, not everything is an object. For example, take the trig function sin(x). It's not an object. Of course, we could bash it into being an object, but that doesn't accomplish anything but obfuscation.
>>>
>>
>> sin(x) isn't an object, but x is, and sin can be made a property of that object.
> 
> 
> How would you define a binary mathematical function then? atan2(y,x) and binominal(n,k) for instance.
> 
> /Oskar

Sure .. (y,x) is an object, (n,k) is also an object.
not that I know what binominal(n,k) means, but since (n,k) is the data you're working with, this data can be the object.

If you're referring to this http://mathworld.wolfram.com/BinomialCoefficient.html
then binominal(n,k) means "n choose k" which reads like a the messege "choose k" to the object "n" ;)

n.choose(k);

I think, for atan2, x,y are coordinates, no? hence x,y is a point.

Oskar Linde wrote:
> Deewiant wrote:
>> Walter Bright wrote:
>>> The trouble with OOP is, well, not everything is an object. For example, take the trig function sin(x). It's not an object. Of course, we could bash it into being an object, but that doesn't accomplish anything but obfuscation.
>>>
>>
>> sin(x) isn't an object, but x is, and sin can be made a property of
>> that object.
> 
> How would you define a binary mathematical function then? atan2(y,x) and
> binominal(n,k) for instance.
> 
> /Oskar

My reply was somewhat tongue in cheek - I suppose I should have added a smiley. Of course everything is not an object.

Although binomial(n, k) I'd define as n.choose(k). <g>

Deewiant wrote:
> Oskar Linde wrote:
> 
>>Deewiant wrote:
>>
>>>Walter Bright wrote:
>>>
>>>>The trouble with OOP is, well, not everything is an object. For
>>>>example, take the trig function sin(x). It's not an object. Of
>>>>course, we could bash it into being an object, but that doesn't
>>>>accomplish anything but obfuscation.
>>>>
>>>
>>>sin(x) isn't an object, but x is, and sin can be made a property of
>>>that object.
>>
>>How would you define a binary mathematical function then? atan2(y,x) and
>>binominal(n,k) for instance.
>>
>>/Oskar
> 
> 
> My reply was somewhat tongue in cheek - I suppose I should have added a smiley.
> Of course everything is not an object.
> 
> Although binomial(n, k) I'd define as n.choose(k). <g>

n.choose(k) is actually /less/ confusing than binomial(n,k)

Hasan Aljudy wrote:

>> Sometimes, I think C++ went hard over in the opposite direction - nothing is an object. OOP programming seems to be regarded as "oh, so 90's" by the modern C++ crowd.
> 
> C++ doesn't really support OOP .. it's just a myth :(

Hmm, I don't get it. Has anyone told all those making OO C++ libraries this?

I get a feeling sometimes that there is a belief that the languages preaching OOP (Java, Eiffel, etc) defines OO. Object orientation is an idea of how to group what belong to each other together. There are umpteen books on best practices how to do this, and AFAICS, the Java books from the past two years differs hugely from those I used back in 98-99 when I started at the University. Especially I read the other day that although inheritance solves a lot, it is often a bad practice if you want a system that is reusable and extensible (Head First Design Patterns, one of the current top books in the Java category.)

There are no rules to OOP! There are guidelines, and depending on your project, it might be smart to follow one of those, or guidelines that are totally different.

Lars Ivar Igesund wrote:
<snip>
> 
> I get a feeling sometimes that there is a belief that the languages
> preaching OOP (Java, Eiffel, etc) defines OO. Object orientation is an idea
> of how to group what belong to each other together. There are umpteen books
> on best practices how to do this

True, OO is not so well defined, mainly because alot of people think they understand oop, when they really don't.

I wish the whole world learned object oriented principles from Schock
http://pages.cpsc.ucalgary.ca/~schock/courses/w05/cpsc233/lectures.html



>, and AFAICS, the Java books from the past
> two years differs hugely from those I used back in 98-99 when I started at
> the University. Especially I read the other day that although inheritance
> solves a lot, it is often a bad practice if you want a system that is
> reusable and extensible (Head First Design Patterns, one of the current top
> books in the Java category.)

The problem is when people look at OOP superficially as a set of tools, e.g. inheritance!
OOP is not a set of tools, it's a set of principles. Inheritance is not there just for the sake of it, it serves a very good purpose: increasing cohesion by pulling common/shared code in a super class.

You can (hypothetically, at least) write object oriented code that doesn't use inheritance, and you can write non-object oriented code that uses inheritance & classes (this happens alot).

Hasan Aljudy wrote:

> I wish the whole world learned object oriented principles from Schock http://pages.cpsc.ucalgary.ca/~schock/courses/w05/cpsc233/lectures.html

I doubt he is the only lecturer out there to have understood object orientation ;)

> 
> The problem is when people look at OOP superficially as a set of tools, e.g. inheritance!

OOP _is_ a set of tools. Nothing more, nothing less.

> OOP is not a set of tools, it's a set of principles. Inheritance is not there just for the sake of it, it serves a very good purpose: increasing cohesion by pulling common/shared code in a super class.

Yes, and by this you get tight coupling and reduced reusability and extendability. Principles just get in the way for practicality. Using inheritance just for the sake of it, or because of principles, is nothing even close to practical.

But then my programming principles encompass pragmatism :)