At first, I decided to try learning C++, then I heard C was "better", now I'm hearing Lisp is good. I'm getting annoyed with indecisiveness, so I'm going to ask this one last time... Which language would be best to learn out of these three? My intentions in programming will be small projects, game mods, network applications and other things of that sort. What would you all recommend out of those three, and why? Not looking for anything outside the above three.
Please halp.
> It is possible to say a language is more OOP than another.
Sure. It's possible to say the sky is green and grass is blue. It isn't meaningful to say those things though, and you're not communicating with other people when you do.
As far as I know, you're arguing that the C++ "*" in variable and function prototypes means C++ is less object-oriented than Visual Basic. I parse that to mean you dislike the asterisk. You keep arguing with me about it though.
You've also made baseless arguments that C++ is less object oriented than Visual Basic because of multiple inheritance. You have so far refused to substantiate that.
> This is where there is a disconnect. Your example uses strings which are value types in VB.Net and not treated the same as objects. I am talking about objects which are reference types.
Use objects then:
Sub Foo(ByRef X As Object)
Set X = CreateObject()
End Subversus:
Sub Foo(ByVal X As Object)
Set X = CreateObject()
End SubThe former modifies the caller's idea of X and is thus called a reference. This definition meshes with what C++ users refer to as reference.
"Reference types" versus "Value types" is uncommon amongst C++ programmers. You can point to Jeffrey Richter all you want, but you still haven't explained yourself. What exactly is Jeffrey Richter supposed to be supporting you on? That Visual Basic has things called reference types and value types? Or that C++ does?
Care you provide an exact citation and explain exactly what you're arguing?
Care to justify your baseless arguments about how something is more or less OOP?
> Well a quick search shows that the word evaluate is used in many different contexts in Sun's Java docs.
You made it sound like you already had the appropriate sound-bite ready and were citing Sun as an authority using that term. I accept them as an authority, but you still need to provide the evidence that they define pointers in that way. Finding the passage "A reference variable is one that evaluates to a pointer." would do that.
> Making the change through assignment won't tell you what in the object changed either.
So encapsulation is preserved.
> Why would one write a function that takes an object, creates a copy of it, changes that copy, and returns the copy?
Because correctness is more important than efficiency. People maintain code, therefore to improve the likelihood that code changes are correct you trade off efficiency. What's the point of a super-fast algorithm if it gets the answer wrong.
If you really need that performance in a profiled chunk of code, references are still there, just not the default. You know what you're getting into.
In addition, for a high-level language, just because it has pass-by-value semantics doesn't mean it's doing copying under the hood. As I mentioned earlier, it's trivial to determine if a basic block will modify a variable. Why should a programmer waste time worrying about a detail that a compiler is guaranteed to get correct (unlike the person)?
And last, with NUMA architecture, actual copying will eventually become a performance advantage. You want to keep data you're modifying local to your processor, otherwise RFOs will kill any chance at near-linear scaling with cores.
> I could do the same (as a reference) with:
Yes, but what if you start with the second. You're faced with the following code:
x = 1
foo( x )
bar( x )
baz( x )What is the value of x at the end? Is it safe to reorder the calls? If you have this:
x = 1
foo_x = foo( x )
bar( foo_x )
baz( foo_x )You know the following at the end:
>That Visual Basic has things called reference types and value types? Or that C++ does?
That VB.Net, C#, Java etc make a distinction of how objects variables are treated in OOP. That distinction means the programmer is always working with instances of the objects they create. It is OBJECT Oriented Programming.
A object variable in a language that has reference variables is ALWAYS going to be refering to the instance of the object created in any scope it is passed to. C++ certainly can do this, but this is not its default behavior. You have to create the reference or pointer to give it to different scopes. It takes extra in C++ steps to do a very basic OOP thing properley. So as an OOP language I do not see C++ being that great at it. The language itself should abstract the proper way to work with objects. I feel the proper way is to always refer to the instance of an object (as I understand OOP and working with objects in it), these other languages just handle it with references to that instance and the solution is a good one C++ already abstracts many things from the programmer, so it should abstract this basic conept of OOP (but can't of course lest it break its other paridigms).
>Finding the passage "A reference variable is one that evaluates to a pointer." would do that.
Yes, I did a quick search for that again. I can't remember the first search I did to find that. It is in there somewhere, but the documentation is extensive.
>So encapsulation is preserved.
Except implelementing the change to the instance is left up to the calling scope. If I pass a car to a paint funciton, I want that function to paint the car I gave it. I don't want it to paint another car. And then make that other car the car I just told the function to paint.
>In addition, for a high-level language, just because it has pass-by-value semantics doesn't mean it's doing copying under the hood.
That could be true, but now the programmer needs detailed knoweldge of the compiler optimizations making that not so high level.
>Yes, but what if you start with the second. You're faced with the following code:...
Your example makes sense. But I would contented that if someone else where to be modifying the code, they would at least need to know what those functions do. If they had no idea, they would most likey have no need to reorder those calls or insert calls inbetween them that would affect later calls. If that person does not understand that chunk of code, then they wouldn't be modifying it as their modifications wouldn't have anything to do with it, because that person would have an understanding of the modifications they are trying to accomplish.
> That distinction means the programmer is always working with instances of the objects they create. It is OBJECT Oriented Programming.
> The language itself should abstract the proper way to work with objects.
Whoops, accidentally posted without finishing my message. I'm a moron. :(
Anyways--I was quoting those to say that you seem to believe there is one "proper" way to approach object-oriented programming, and that simply isn't true. As I said in >>100, you should look into other languages that present OOP in different ways. As it is your view of OOP seems very narrow since, like I said, you keep making mention about "proper" OOP. There are all kinds of ways to do OOP, and it will make you a better programmer to learn about them. I also believe that would really change your point of view about the reference topic at hand.
But even if it doesn't, it won't hurt to expand your view.
> (babbling removed)
> The language itself should abstract the proper way to work with objects.
> (babbling removed)
Just so we're clear: Your objection is that C++ is less object-oriented because you have to type the asterisk * as part of the type name.
There are a number of benefits in making the copy-constructor the default: RAII is impossible without it, and garbage collection can be done on a per-class basis (think about how you would implement automatic reference counting without the copy constructor).
> if someone else where to be modifying the code, they would at least need to know what those functions do
Right. So instead of tracking just what the function is supposed to return, they need to also track what effects there are on every argument.
Documentation isn't enough, because what if I change a sub-call to mutate a reference?
> because that person would have an understanding of the modifications they are trying to accomplish
With references you need to understand a whole lot more -- in a degenerate case the whole codebase -- in order to make the exact same change.
> That could be true, but now the programmer needs detailed knoweldge of the compiler optimizations making that not so high level.
No, they do not. Their code works just as they intended, no matter how the compiler implements it.
It is only if they really need to optimize the code they need to know anything about the internals of the compiler, but that is true of any kind of optimization, not just this particular one!
I am not contending that there is 1 true way to OOP. Just that C++ just doesn't do it well.
>Just so we're clear: Your objection is that C++ is less object-oriented because you have to type the asterisk * as part of the type name.
To oversimplify it, yes.
>There are a number of benefits in making the copy-constructor the default: RAII is impossible without it,
Not really. In C# and VB.Net there is the using statement and IDisposable interface along with manual garbage collector control (a topic many seem to be confused about because even though the GC is nondeterministic and automatic, you can easily control when it collects and what it collects). RAII is completley possible in .Net with its reference variables.
>and garbage collection can be done on a per-class basis (think about how you would implement automatic reference counting without the copy constructor).
You mean collect all instances of a given class in scope? Not that that sounds like a bad idea, I can't think of where I have seen that or why someone would want to do that.
>Right. So instead of tracking just what the function is supposed to return, they need to also track what effects there are on every argument.
Yes, it would make sense that if one were going to modify some code that calls a function, they would need to know what that function is doing.
>Documentation isn't enough, because what if I change a sub-call to mutate a reference?
I would say you need to stick to the idea that each object variable should always refer to an instance of the object.
>No, they do not. Their code works just as they intended, no matter how the compiler implements it.
So your coding and you think to yourself: "This makes it clear, but doubles the memory footprint and invokes extra initilization instructions in code, but it doesn't matter because the compiler will know I am fucntionally working with 1 instance of this object."
or
"Since I am working with 1 instance of an object, my code will refelect that."
> it would make sense that if one were going to modify some code that calls a function, they would need to know what that function is doing.
This has already been covered with the last paragraph in >>113.
> I would say you need to stick to the idea that each object variable should always refer to an instance of the object.
I don't know what this means; you're going to have to rephrase it. D:
> RAII is completley possible in .Net with its reference variables.
http://www.hackcraft.net/raii/
disagrees with you. Please justify your claim.
Furthermore, .NET needs to not just be able to express RAII idioms, but be able to do so better than C++ in order to back this claim: "C++'s OOP usage I say its fundamentally flawed."
> > and garbage collection can be done on a per-class basis
> You mean collect all instances of a given class in scope?
No. I mean what if you want some classes to collect their garbage automatically, and others that I want to collect explicitly?
> I am not contending that there is 1 true way to OOP.
Fine. Look here:
> Just that C++ just doesn't do it well.
If you meant there were multiple ways to do OOP, you would say "Just that C++ doesn't do any of them well".
That is of course a challenge for us to find one thing OOP that C++ does well. I've already suggested RAII and object-specific garbage collection. If you manage to find some language that can do either of these better than C++, I can probably come up with more things.
>disagrees with you. Please justify your claim.
There are a lot of people confused about the .Net GC. Its default behavior is to be non-deterministic, as in you don't know when it will run. But, what few people seem to know is you can manually control it and dertermanistically clean up your objects whenever you would like.
>Furthermore, .NET needs to not just be able to express RAII idioms, but be able to do so better than C++ in order to back this claim: "C++'s OOP usage I say its fundamentally flawed."
A language does not have to be able to effectivley implement RAII to be OOP as RAII is an OOP design pattern.
>No. I mean what if you want some classes to collect their garbage automatically, and others that I want to collect explicitly?
Again, in .Net you certainly can do that.
>If you manage to find some language that can do either of these better than C++, I can probably come up with more things.
I am not trying to get down to some nitty gritty things. I am focusing on how C++ treats objects, the basis of OOP.
> But, what few people seem to know is you can manually control it and dertermanistically clean up your objects whenever you would like.
You can implement LISP in nearly any language. That doesn't mean any language is as powerful as LISP.
> A language does not have to be able to effectivley implement RAII to be OOP as RAII is an OOP design pattern.
No, but you made a broad claim that C++ does OOP poorly. You have offered a single example (You don't like typing asterisks- and you feel they shouldn't be the default), to which I've offered two counterexamples why they should.
RAII is something C++ is going to do better than Visual Basic. RAII is useful, and it's an OOP design pattern.
> Again, in .Net you certainly can do that.
Can is not the same thing as do. People don't do that in .NET languages because it is difficult at best.
> I am not trying to get down to some nitty gritty things. I am focusing on how C++ treats objects, the basis of OOP.
You're unfocused.
You said C++ does OOP worse than Visual Basic because the asterisk should be the default. I provided two reasons that the asterisk should not be the default. Since you haven't argued against them being good reasons, I'll take it you accept my premise.
Therefore, because they do not have copy constructors, Visual Basic and .NET languages do OOP poorly. ∎
>You can implement LISP in nearly any language. That doesn't mean any language is as powerful as LISP.
What does a LISP implementation have to do with the .Net GC?
>You have offered a single example (You don't like typing asterisks- and you feel they shouldn't be the default), to which I've offered two counterexamples why they should.
That is the symptom you are focusing on. I am taking issue with the broader approach of how C++ lacks object instance abstraction. You choose to focus on one aspect of that.
>Can is not the same thing as do. People don't do that in .NET languages because it is difficult at best.
Difficult according to who? Implementing IDispoable to give you a function to do cleanup and calling GC.Collect is not difficult.
>I provided two reasons that the asterisk should not be the default. Since you haven't argued against them being good reasons, I'll take it you accept my premise.
I have, you just dismiss them because you are so stuck in thinking that C++ is so good at OOP.
>Therefore, because they do not have copy constructors, Visual Basic and .NET languages do OOP poorly.
There seems to be this obsession with copying object instances. You keep bringing up Visual Basic which I have already said is kind is moot because VB.Net is more OOP (in that it implements more OOP idioms) and Visual Basics next version is still in the works and not release.
If you really want to copy an instance of an object, the .Net framework does have the ICloneable interface.
But the copying of objects is something to generally be avoided. C++'s STL String classes go to great lengths to only copy the instance on write so it can be passed around by reference other times internally. .Net does something similar, buts it goal is to treat the string object as a value type making the string reference immutable.
But because making all these string copies on write incurres a huge performance overhead, there is the .Net StringBuilder class to work with mutable strings.
So in the end, all copying object instances does is produce complexity and performance issues. And providing a default constructor to do it that you are probably going to override anyway doesn't make a language OOP better.
> What does a LISP implementation have to do with the .Net GC?
What does .Net's theoretical capabilities have to do with what C++ makes simple?
> That is the symptom you are focusing on. I am taking issue with the broader approach of how C++ lacks object instance abstraction. You choose to focus on one aspect of that.
I keep asking you to explain yourself. Here's your chance again.
I am only focusing on what you bring up specifically. Broad claims get broad counterclaims.
> Difficult according to who? Implementing IDispoable to give you a function to do cleanup and calling GC.Collect is not difficult.
More difficult than an asterisk.
> I have, you just dismiss them because you are so stuck in thinking that C++ is so good at OOP.
Excuse me?
Where did I say that C++ is good at OOP?
I was arguing that Visual Basic isn't "better" at OOP than C++, and perhaps that C++ isn't obviously bad at OOP.
> There seems to be this obsession with copying object instances.
Copying things is a good way to do a lot of things. You have even agreed that some of those things are good.
> You keep bringing up Visual Basic which I have already said is kind is moot because VB.Net is more OOP (in that it implements more OOP idioms) and Visual Basics next version is still in the works and not release.
And I think you're a jerk for taking a term like "OOP" and redefining it such that there are no languages that implement "OOP" according to your private definition (that you have still refused to share with us) until Visual Basic.NET.
Specifics, please!
> If you really want to copy an instance of an object, the .Net framework does have the ICloneable interface.
Does every object implement ICloneable?
> But the copying of objects is something to generally be avoided.
Says you. If copying is the default, and I can override the copying semantics, I can get COW trivially.
Taking away programmer power by adding restrictions on the programmer is not something to be done lightly. Here is a way that C++ is more powerful than .Net, and it is something that is useful to expose to objects- it lets you use a natural method of interacting with the objects, and yet still lets you provide a high-performance implementation.
> But because making all these string copies on write incurres a huge performance overhead, there is the .Net StringBuilder class to work with mutable strings.
What the hell are you talking about now?
Who is talking about copying strings? Why are you talking about copying strings?
I was talking about minimizing copies by making it easy to share strings. Exposing that at the language level makes it easy to have a "string" class that equally-well works on large (multi-terabyte) strings and small in-memory chunks. Such a beast requires string-operations to be an interface.
.Net cannot implement this, but C++ can. That seems like a very useful object-oriented thing.
>What does .Net's theoretical capabilities have to do with what C++ makes simple?
So your point is that the .Net garbage collector has something to do with implementing LISP in C++. That makes no sense.
>I keep asking you to explain yourself. Here's your chance again.
And as I have repeated many many times. Reference variables always refer to an instance of an object in any scope they are in or passed to. In OOP, one primarily is working with instances of ojects. C++ does not abstract the object instance references. It is left up to the C++ programmer to do that themselves. If they are doing OOP, that means they are doing this extra work a lot.
>More difficult than an asterisk.
So if an object allocates resources, clean up of those resources is automatic when passing a pointer. You have no idea what is going on here buddy.
>I was arguing that Visual Basic isn't "better" at OOP than C++, and perhaps that C++ isn't obviously bad at OOP.
I hope you meant VB.Net because I have stated more than once that Visual Basic isn't good at covering the OOP bases.
>Copying things is a good way to do a lot of things. You have even agreed that some of those things are good.
I understand the need to do it sometimes in order to point out that focusing on working on object instances does not mean you have to sacrifice the ability to copy where it is appropriate. But at the same time, the copying constructs the C++ STL and .Net's string object make the string object very complex. Complexity that is needed for a library object like string, but not complexity one is going to be implementing in many if any other classes they make. And few classes have the ubiquity of string.
>And I think you're a jerk for taking a term like "OOP" and redefining it such that there are no languages that implement "OOP" according to your private definition (that you have still refused to share with us) until Visual Basic.NET.
As I have said many times before, I am focusing on object abstraction. It Object Oriented Programming. So by definition, the programming style is oriented towards working with objects and I have not needed to delve much deeper at this point.
>Does every object implement ICloneable?
It would not make sense for every object to implement ICloneable as the members of ICloneable would in fact be members of Object, as every type implicity inherits object.
Object has a protected MemberwiseClone function that creates a shallow copy of the object (that should actually be exposed by ICloneable). If you want to make a deep copy, then you put the code you would put if you were writing a copy constructor.
Since we aren't ever passing reference variables by value, there isn't a whole lot of need for a copy constructor. You can easily replicate that sort of thing by calling the clone method when using an object as a parameter. C++ like to make copies of objects in lots of different places. .Net does not, it would prefer one work with a single instance of an object. So if you need to work with a copy, you gotta create it.
C++:
function(Object myObject)
C#:
function(Object myObject.Clone)
do the same thing. And writing your Clone function is not any more difficult that writing custom logic in a copy constructor, and just trivially annoying if you want a shallow copy as you have to call and return the protected MemberwiseClone member of Object where in C++ you don't have to write anything.
>Taking away programmer power by adding restrictions on the programmer is not something to be done lightly.
As explained above the how to do this is trivial in .Net.
>Here is a way that C++ is more powerful than .Net, and it is something that is useful to expose to objects- it lets you use a natural method of interacting with the objects, and yet still lets you provide a high-performance implementation.
The natural way to work with an object is to work with one instance of that object.
And I just covered in my last post how the string objects copying (in .Net and C++) is not very per formant when you want to change the value of a string. Creating extra copies of what is essentially 1 thing does not lead to performance. Extra memory + extra instructions to create the copy of the one thing + extra instructions to sync the copy and the original instance + extra instructions to handle the memory of the copy once it is not needed and it will not be needed again very soon is not performed.
If you want to make a copy of an object, the you should be making another instance of that object based off of the first and treating the new object as a completely separate instance. In other words, copies are 2 separate instances. Copies should not be multiple instances of an object that eventually become 1 instance of an object. Its like building a car. They don't make 3 new full cars that are exactly the same, then modify 2 of them, then take parts from those 2 and put them on the first car and destroy what wasn't used and make 1 new car.
>Who is talking about copying strings? Why are you talking about copying strings?
In the context given, why not to copy instances of objects. Strang you didn't understand that. Thought I would bring up a very common class that uses copies of its instances internally to produce horrible performance.
If you know your stuff, you should know concatenating strings (when the number of concatenations is unknown using the + operator at design time especially) using the STL String class in C++ in not very performant. It is the same story in .Net and Java because they work with strings in a similar matter. To make them mutable, they gotta copy their contents.
>I was talking about minimizing copies by making it easy to share strings.
Well that's strange because that is my whole point of abstracting objects as references.
>.Net cannot implement this, but C++ can. That seems like a very useful object-oriented thing.
That's just wrong. In .Net and C++ the STL still makes intermediate instance copies. They both suck at it and they both require one to use a class built for certain purposes when working with mutable strings of write their own.
Now please pay attention so I don't have to repeat myself again.
> C++ does not abstract the object instance references. It is left up to the C++ programmer to do that themselves. If they are doing OOP, that means they are doing this extra work a lot.
You seem to be under the impression C++ programmers usually write code like this:
Foo *x = new Foo(1234);
x->Moo("Bar");
delete x;They don't. Instead it looks like this:
Foo x(1234);
x.Moo("Bar");And yet you insist:
function(Object myObject)is somehow worse than typing:
function(Object myObject.Clone)> So if an object allocates resources, clean up of those resources is automatic when passing a pointer. You have no idea what is going on here buddy.
If an object allocates a file, you similarly have no idea. It just so happens one resource is automatically managed.
Automatic resource tracking isn't anathema, and is in fact very very expensive. Requiring it is like calling the programmer stupid.
> The natural way to work with an object is to work with one instance of that object.
That's one kind of object-orientedness; the kind C++, CL (sortof), Simula, Perl, and Python uses.
Another variety is the kind Smalltalk, Ruby, Java, and C# use which is the message-passing model, whereby you're not working with an instance of an object at all but instead communicating with an object by-way-of messages.
>You seem to be under the impression C++ programmers usually write code like this:...
The function signatures are very different.
>Automatic resource tracking isn't anathema, and is in fact very very expensive. Requiring it is like calling the programmer stupid.
So then what was your point?
>That's one kind of object-orientedness; the kind C++, CL (sortof), Simula, Perl, and Python uses.
Another variety is the kind Smalltalk, Ruby, Java, and C# use which is the message-passing model
They use different techniques to accomplish the same thing, working with object instances. However, in C++ it is left up to the developer to explicitly add extra operators to work with object instances in different scopes. The latter languages abstract working with object instances to the point that you are always doing so. OOP wants you to always work with object instances. Object is defined as an instance of a class. So you could call it class instance oriented programming. If variables by default are not oriented twords working with class instances, then they are not doing OOP well. C++ is jut doing OOP, not doing it well.
> The function signatures are very different.
So what?
The function signatures for similar VB or C# code is different too.
> They use different techniques to accomplish the same thing,
Uh no. No they don't.
Smalltalk based systems can have doesNotUnderstand messages, and CLOS objects don't have methods or messages.
> C++ is jut doing OOP, not doing it well.
You keep saying that, and I keep demonstrating that object-oriented covers a very wide berth. For you to be correct, C++ cannot do any aspect of OOP very well.
You offer a single example that C++ does OOP poorly by showing that it performs a single task poorly, and saying that task means OOP. For you to be correct, that would mean OOP must not have existed until VB and .Net, because that task is meaningless in Smalltalk and in CLOS.
I think it's pretty clear you are complaining about typing an asterisk. The burden still remains why this is essential to OOP, or you need to demonstrate that C++ doesn't do any aspect of OOP very well.
Alternatively, you can coopt the term "OOP" to only include languages that have the message-passing semantics and a distinction between machine and object types.
>The function signatures for similar VB or C# code is different too.
Different in that you don't need extra syntax to pass an object instance to the functions scope. There is syntax that exists for value to non-object variables, but that syntax is moot for objects because no matter what you try, its passed by reference.
>Uh no. No they don't.
Your response in context indicates that you are trying to say that C++ and Python (and the others mentioned) work with object instances the same way. I can tell you that just isn't true. All Python variables are references to the variables value.
>You keep saying that, and I keep demonstrating that object-oriented covers a very wide berth. For you to be correct, C++ cannot do any aspect of OOP very well.
You keep drifting away from the aspects of how C++ treats objects and that object appears in the name OOP.
>You keep saying that, and I keep demonstrating that object-oriented covers a very wide berth. For you to be correct, C++ cannot do any aspect of OOP very well.
It is pretty common to say that some languages are poor at OOP. Visual Basic is said to be a poor OOP language because of the way it handles inheritance and some other things. So for you to be correct, you would have to contend that all languages that implement some OOP idioms do so well because they just implement them. How they are implemented is irrelevant. I would say that's not correct.
>I think it's pretty clear you are complaining about typing an asterisk. The burden still remains why this is essential to OOP, or you need to demonstrate that C++ doesn't do any aspect of OOP very well.
As stated before, the asterisk is a symptom of how C++ fails to abstract object instances and leaves that to the developer. Something as basic as working with instances should be inherent to the language.
>Alternatively, you can coopt the term "OOP" to only include languages that have the message-passing semantics and a distinction between machine and object types.
Well it would be nice if there was 1 true term to describe all of OOP. So we can narrow down the main languages of discussion here to Class Based OOP (which includes C++ and C++ does not try to implement any other style of OOP like Prototype Based OOP). In class based OOP object identity is fundamental. C++ does not abstract an object's instance as being unique by default. The way it implements identity is to create copies when passing to other scopes destroying the uniqueness of the identity. Uniqueness is part of the definition of identity in Class Based OOP.
So for C++ to do Class Based OOP well, it should handle identity as unique by default and not leave it up to the developer to put in to place extra syntax and procedures to ensure this basic idiom of Class Based OOP.
Is that specific enough?
> As stated before, the asterisk is a symptom of how C++ fails to abstract object instances and leaves that to the developer. Something as basic as working with instances should be inherent to the language.
You don't always want to abstract away instances, as people have pointed out in other posts. Not every language abstracts everything. Your complaint seems to be that C++ makes you type a little more than other languages, and that's true. That verbosity provides finer degrees of control. If you want finer control over things you use a language like C++. If you don't, use something else.
This all just seems to be an argument of personal preferences. You don't like typing an asterisk, so you don't like C++. There's nothing wrong with that, but you should just say so instead of turning it into this issue of C++ having some sort of fundamental problem.
> that syntax is moot for objects because no matter what you try, its passed by reference.
No it isn't.
I've already established what that means. By reference means using ByRef in VB and & in C++. The only language I'm aware of where all objects are passed by reference is Fortran.
Stop coopting terminology. I'd prefer you use made up words if you don't know what they mean.
> Your response in context indicates that you are trying to say that C++ and Python (and the others mentioned) work with object instances the same way. I can tell you that just isn't true. All Python variables are references to the variables value.
Then get your fucking eyes checked.
I said the OOP that Smalltalk supports and the OOP that CLOS supports doesn't map comparatively to C++ or Python. I also said that C++'s OOP doesn't map comparatively to Visual Basic.
I've been saying there are many kinds of OOP. For some reason, you keep arguing with this.
> So for you to be correct, you would have to contend that all languages that implement some OOP idioms do so well because they just implement them.
The onus isn't on me to do so. I'm not saying any particular language is poor at OOP. I'm not saying any particular language is good at OOP either.
You're the one making blanket statements that you cannot back up with anything but an asterisk complaint.
> Something as basic as working with instances should be inherent to the language.
C++ works with instances just fine, look:
x.bar = 1234;See?
There are many kinds of OOP. For some reason, you keep arguing with this. You need to focus on exactly what is wrong with C++'s kind of OOP instead of trying to redefine object-oriented programming to exclude every programming style and language except your Visual Basic dot net.
> So for C++ to do Class Based OOP well,
Rejected. "Class based OOP" means something very specific to programmers, as does "By Reference". You've already attempted to coopt the latter to be synonymous with "pointer", so I reject this entire paragraph on the grounds you don't have any fucking clue what you're talking about.
Point to an external reference that describes class-based oop the way you just did if you want to argue about it.
> Is that specific enough?
No it isn't. You just said C++ doesn't support OOP because x == x might not be true. Python therefore doesn't support OOP either. Neither does SmallTalk, for that matter.
Just shut the fuck up already. You clearly don't have any idea what you're talking bout.
>You don't always want to abstract away instances, as people have pointed out in other posts.
You do when the very basis of Class Based Object Oriented Programming is to maintain unique identity of class instances.
I have not seen any valid reasons to refer to the value of an object instance.
>Not every language abstracts everything. Your complaint seems to be that C++ makes you type a little more than other languages, and that's true. That verbosity provides finer degrees of control.
Class Based Object Oriented Programming languages should abstract the very basic workings of Classes in Object Oriented Programming.
How is greater control accomplished when working with object instances in a practical manner?
>This all just seems to be an argument of personal preferences.
It is a discussion about how C++ drops the ball on a fundamental of Class Based Object Oriented Programming.
>but you should just say so instead of turning it into this issue of C++ having some sort of fundamental problem.
Except that I have explained some of the fundamentals of Class Based Object Oriented Programming and how C++ does not adhere to those fundamentals by defaults.
> You do when the very basis of Class Based Object Oriented Programming is to maintain unique identity of class instances.
You keep using that word. I do not think it means what you think it means.
You're clearly arguing something you're very impassioned about. It just doesn't make any sense beyond you "don't like the asterisk".
Class-based object oriented programming is where inheritance is derived through taxonomy- that is, short for classification. See: http://en.wikipedia.org/wiki/Class-based_programming for more details.
Identity comes from mathematical identity and refers to a comparison that remains true regardless of (or without comparing) any of the constituent variables. See http://en.wikipedia.org/wiki/Identity_(object-oriented_programming) for more details.
While C++, Smalltalk and Java are all "class-based", that doesn't mean that their object models are identical; It is impossible to implement some algorithms in C++ that are trivial to implement in Smalltalk, especially those that depend on #doesNotUnderstand:.
> I have not seen any valid reasons to refer to the value of an object.
See >>108.
> How is greater control accomplished when working with object instances in a practical manner?
By "control" I meant being able to decide when I want to pass by value and pass by reference. By "verbosity" I meant that damned pesky asterisk. I don't entirely understand your question though; I work with objects in "practical manners" all the time and pass them by value.
> It is a discussion about how C++ drops the ball on a fundamental of Class Based Object Oriented Programming.
See >>131.
> Except that I have explained some of the fundamentals of Class Based Object Oriented Programming and how C++ does not adhere to those fundamentals by defaults.
No you haven't. All you have explained is that C++ doesn't pass objects by reference by default, and you act like this makes proper OOP impossible with C++.
>I've already established what that means. By reference means using ByRef in VB and & in C++.
And as I have corrected you, that is not true.
The signatures:
Function(ByVal thing As Object)
Function(ByRef thing As Object)
When compiled in VB.Net (or VB) they mean the same thing which is Function(ByVal thing As Object).
thing holds a reference to a value of type Object. Passing thing ByRef will pass a reference to the reference of thing's value because thing is a reference type variable. This is something that has no practical application, so the compiler ignores ByRef and treats it as ByVal. ByVal and ByRef are used for value type variables (which is basically anything that is not an object).
>The only language I'm aware of where all objects are passed by reference is Fortran.
Like C++, VB.Net, C#, Java etc. are pass by value languages. The confusion comes in because thee latter languages have reference type variables where the value of the reference is what you are passing. So I would just avoid the whole "pass by value"/"pass by reference" language terms because that just adds confusion and I wouldn't want to co-opt what those mean.
>I've been saying there are many kinds of OOP. For some reason, you keep arguing with this.
Which is why I went on to further define the type of these languages as Class Based OOP which has a more specific definition.
>I'm not saying any particular language is poor at OOP. I'm not saying any particular language is good at OOP either.
So your counter-point is that C++ implements object instances correctly? Or is it that there is no correct way for a language to implement object instances.
If it is the former, then you need to understand that my point is that while a programmer can correctly implement object instances in C++, C++ as a language does not correctly implement them for the programmer. Since OOP features are high-level features of the language, it should include this abstraction (but of course it can't).
If it is the latter, then you must be contending there is no basic definition of any style of OOP or its constructs. But if that was true, anything could call itself OOP.
You seem to want to weasel out of any rational discussion of this by saying that there is no definition of anything regarding OOP, and any language can implement whatever it wants and call itself OOP.
>C++ works with instances just fine, look:
Now pass that object to another scope. The language will break the instances unique identity unless you specifically tell it not to. The language should always maintain instance identity.
>You need to focus on exactly what is wrong with C++'s kind of OOP instead of trying to redefine object-oriented programming to exclude every programming style and language except your Visual Basic dot net.
Its kind of OOP is Class Based OOP. Look up exactly what that means yourself from a reliable source. And focus on how it defines identity.
>"Class based OOP" means something very specific to programmers
See, at least you admit that it means something specific. No you must learn what those specifics are.
>as does "By Reference". You've already attempted to co-opt the latter to be synonymous with "pointer"
I have not. I understand that C++ does not have a direct correlation for a reference type variable. C++ pointers and references are used to accomplish functionality similar to what reference variables do, but I have never said they were exactly then same, just comparable.
>Point to an external reference that describes class-based oop the way you just did if you want to argue about it.
Well Wikipedia came up first, you can Gogole yourself if you don't like it.
http://en.wikipedia.org/wiki/Class-based_programming
"The most popular and developed model of OOP is a class-based model, as opposed to an object-based model. In this model, objects are entities that combine state (i.e., data), behavior (i.e., procedures, or methods) and identity (unique existence among all other objects)."
Note the words identity and unique. Combing this uniqueness with the default copying behavior when passing objects to other scopes. Copies of the same instance are not unique, hence the use of pointers and references, that the language does not abstract, to enforce uniqueness. It requires the programmer to implement uniqueness (a fundamental) themselves. Identity is fundamental to this style of OOP and the language should be thing thing implementing it, bot the programmer.
>You clearly don't have any idea what you're talking bout.
You clearly need to take more time to learn these concepts.
> You seem to (gibberish snipped) by saying that there is no definition of anything regarding OOP, and any language can implement whatever it wants and call itself OOP.
That's exactly what I'm saying!
I keep asking you to define OOP; I said we cannot have a meaningful discussion about what is less OOP without one, and that's what you seem to want to do.
The definitions you've provided exclude Smalltalk and Common-Lisp, which I think takes an enomrous amount of hubris.
Then you harp about "class-based object oriented programming" in a way that makes no sense, and have the nerve to call me a weasel.
You say:
> And as I have corrected you, that is not true.
and yet, to what end? You cannot compare what C++ calls a reference with what VB.NET calls a reference if they aren't the same thing. You clearly seem to know this:
> I understand that C++ does not have a direct correlation for a reference type variable.
and yet they both have something similar to what C++ calls a reference. You then use a term called "call by reference" which has a shared meaning amongst both C++ and VB programmers and have coopted it to be a term that can only be meaningful amongst VB.
Your sole appeals to authority include some vague reference to a Java documentation that you can't provide a link to, and a VB programmer who doesn't agree with you either.
I'm happy to have a meaningful discusson about what's wrong with C++, but so far all you've got is a dozen posts with nothing more meaningful than you don't like the asterisk.
Then I noticed this:
> (an object oriented) language should always maintain instance identity.
Says you. Unjustified. Without example, or citation.
I've offered a number of reasons why a language shouldn't do that, and we've demonstrated that a number of algorithms are hard to express when a language does that.
dmpk2k even pointed out that it makes debugging a lot easier, because it's harder for errors to creep backwards deep from within a function.
The onus is still on you to say why the copy-on-call-semantics are the antithesis of object-oriented programming.
OK, lets get some of these basics out of the way.
Do you agree:
That at a high level we can define Object-oriented programming (OOP) as a programming paradigm that uses "objects" and their interactions to design applications.
And at a high level objects are conceptual entities that generally correspond directly to a contiguous (to the program) block of computer memory of a specific size at a specific location. I say "contiguous (to the program)" because the memory may not be contiguous at run-time, but that implementation detail is abstracted from the developer, at least in the languages of dicussion.
And that C++ implements a specific OOP style called Class Based OOP. Also, VB.Net, C#, Smalltalk and Java also implement this type of OOP. And that while there are many languages that could be discussed, it is better to just limit the discussion to only a few similar languages that implement these concepts in different ways.
And that Class Based OOP implements classes of objects. In this model objects are entities that combine state (data), behavior (procedures, or methods) and identity (unique existence among all other objects).
And that identity is realized through references.
And that a reference (at a high level, not a specific implementation of it yet) contains the information that is necessary for the identity property to be realized and allows access to the object with the identity.
So objects have an identity and the identity is access through a reference to that identity.
And that reference is implemented in these languages by:
C++ - the use of pointers and references (which will be called C++ references to distinguish between the reference concept and C++'s implementation of it)
And that VB.Net, C#, Java implement reference by using the concept of reference type variables where the programmer works with a variable that is only a type-safe managed pointer to the actual object instance.
Do you agree?
> That at a high level we can define Object-oriented programming (OOP) as a programming paradigm that uses "objects" and their interactions to design applications.
No.
At least, not if "their interactions" requires the methods or receiver be associated with the object (or its class). CLOS for example, uses multiple-dispatch only, and I certainly consider it object-oriented.
C++ also has something like multiple-dispatch that they call "overloading" (common) or "dynamic dispatch" (less common).
> And at a high level objects are conceptual entities that generally correspond directly to a contiguous (to the program) block of computer memory of a specific size at a specific location. I say "contiguous (to the program)" because the memory may not be contiguous at run-time, but that implementation detail is abstracted from the developer, at least in the languages of dicussion.
This is jibber-jabber, and means nothing substantial. What you've said is true of all Von-Neumann systems, and has nothing to do with object-oriented programming.
> And that C++ implements a specific OOP style called Class Based OOP. Also, VB.Net, C#, Smalltalk and Java also implement this type of OOP.
Accepted.
C++ also implements other OOP styles, including Dynamic Dispatch, and a form of Generic functions. It may implement other OOP styles as well.
> And that Class Based OOP implements classes of objects.
Rejected. Class-based means that the receiver or methods are actually inside the class instead of in the object, and specifically with regards to inheritence, Class-based means that when a message is not understood, or a method does not exist, the class has some number of superiors that are searched in place of the class.
> And that identity is realized through references.
Pleonastic jibber-jabber. C++ objects have a mathemtical identity whether or not there are any references to them.
> And that a reference (at a high level, not a specific implementation of it yet) contains the information that is necessary for the identity property to be realized
Rejected. You haven't demonstrated it is necessary, and I can come up with at least one counter-example.
Smalltalk objects may have multiple references (by way of proxy objects) that point to the same object, but do not share the same identity.
> and allows access to the object with the identity.
Clearly not. C++ objects have a mathematical identity whether or not there are any references to them.
> So objects have an identity and the identity is access through a reference to that identity.
Rejected.
> And that reference is implemented in these languages by: C++ - the use of pointers and references (which will be called C++ references to distinguish between the reference concept and C++'s implementation of it)
Accepted, although your terminology is confusing.
> And that VB.Net, C#, Java implement reference by using the concept of reference type variables where the programmer works with a variable that is only a type-safe managed pointer to the actual object instance.
Accepted, although your terminology is confusing.
> Do you agree?
No.
>At least, not if "their interactions" requires the methods or receiver be associated with the object (or its class)
It does not. Its Objects AND their interactions. Does not imply that the object explicity owns any particular interaction.
>This is jibber-jabber, and means nothing substantial.
Your right, it is not substantial because it does not decribe the implementation of an object, just a concept of an object at a high level. And it does have to do with OOP.
>C++ also implements other OOP styles, including Dynamic Dispatch, and a form of Generic functions. It may implement other OOP styles as well.
This I understand. It also implements other programming styles. But the discussion should be limited to Class Based OOP because it is arguable the most popular OOP style used by C++ develoepers.
>Rejected. Class-based means that the receiver or methods are actually inside the class instead of in the object
I will agree. The working was poor. Do we say:
An object is an instance of a class. A class defines behavior (i.e., procedures, or methods) while the instance contains state (i.e., data), and identity (unique existence among all other objects).
>Pleonastic jibber-jabber. C++ objects have a mathemtical identity whether or not there are any references to them.
Because all languages do not do everything in the same way, we need to define the concept, and then the implementation.
In this context a reference is the concept describing the means by which the programmer interacts with an object. Object instances inheirently have an indentity. Their identity is the fact that they exist and are a unqiue instance. A reference is how one gets the identity. Objects have identity, and references are how a programmer realizes that identity.
By mathmatical identity do you mean like ≡ (not a congruance relation)?
>Rejected. You haven't demonstrated it is necessary
Without a reference to an objects identity, the program would be unaware of its existance.
>Smalltalk objects may have multiple references (by way of proxy objects) that point to the same object, but do not share the same identity.
You have just decribed an alternative way Smalltalk can realize reference. While the proxy objects will each have their own identity, the objects reference the identity of the object they are proxy for. It is just another implementation to meet a specific need but it does not make a case for the concept that objects have identity and references realize that identity.
>Accepted, although your terminology is confusing.
To be clear.
The basic way C++ realizes the concept of reference is through pointers (* operator) and C++ references (& operator).
The basic way VB.Net, C# and Java realize the concept of reference is by distinguishing all objects as "reference type" variables. Object variables contain a type-safe managed pointer to the actual object instance. It is type safe because pointer arithmatic is not allowed. It is managed because the runtime that is executing the code is responsible for memory management and maintaining the pointer to the object instance.
These are not the only way these languages realize reference, but it is the most fundamental. (proxy objects, weak references and the like are another topic of discussion).
If you don't like some of these definitions you are gonna have to offer up your own.
> Its Objects AND their interactions. Does not imply that the object explicity owns any particular interaction.
Then the definition is meaningless; C meets this criterea. It simply doesn't let you create new methods, nor new object types.
> we need to define the concept (identity), and then the implementation.
Agreed.
Care to supply one?
> In this context a reference is the concept describing the means by which the programmer interacts with an object. Object instances inheirently have an indentity. Their identity is the fact that they exist and are a unqiue instance. A reference is how one gets the identity. Objects have identity, and references are how a programmer realizes that identity.
This definition fails for Smalltalk. There is no way to get the identity of an object in Smalltalk, because of doesNotUnderstand: and how common it is to use for proxies.
> By mathmatical identity do you mean like ≡ (not a congruance relation)?
Strict equivalence is often interchangable with mathemtical identity.
> The basic way VB.Net, C# and Java realize the concept of reference is by distinguishing all objects as "reference type" variables.
Okay.
> Object variables contain a type-safe managed pointer to the actual object instance. It is type safe because pointer arithmatic is not allowed.
This specifically disallows C++, and is thus tautological. You must demonstrate that C++ does object oriented poorly by defining what object-oriented is.
If your definition of object-oriented-programming requires garbage collection and managed pointers, you're on shaky ground. I don't think you can prove that object-oriented-programming requires those things.
Since Java and C# let you defeat the garbage collection system, does that mean they aren't object-oriented?
> Without a reference to an objects identity, the program would be unaware of its existance.
The program isn't an aware thing. What exactly do you mean? That access to the reference can be lost?
> These are not the only way these languages realize reference, but it is the most fundamental. (proxy objects, weak references and the like are another topic of discussion).
I disagree that it is the most fundamental. C++ programs don't usually interact with the references, as I've pointed out.
> If you don't like some of these definitions you are gonna have to offer up your own.
I already did; I keep pointing to Wikipedia. You kept coopting them. It seems important for you to refer to these things with visual-basic-like terminology, and I don't think it matters that much.
>Then the definition is meaningless; C meets this criterea. It simply doesn't let you create new methods, nor new object types.
Well if you can't design your own objects, then the language is not OOP.
>This definition fails for Smalltalk. There is no way to get the identity of an object in Smalltalk
Identity is the concept of the unique existance of an object instance. You can certainly work with object instances in small talk. The various waysyou work with objects instances is the concept of reference.
>This specifically disallows C++
Of course it does, it explains how the other languages implement the concept of reference to an object identity. They don't implement it in the same way and they don't have to. And I am not contending there is 1 correct way to implement the concept of reference.
>The program isn't an aware thing. What exactly do you mean? That access to the reference can be lost?
Without a reference to an object identity, there is nothing for the language to work with. If you delete all references to an object that is left in memory, and then through some meachnism identify that block of memory as being that object, you are just implementing the concept of reference.
>I disagree that it is the most fundamental. C++ programs don't usually interact with the references, as I've pointed out.
So we say that C++ programs most typically work with objects by using object variables and pointers.
>I already did; I keep pointing to Wikipedia. You kept coopting them.
If you are goning to reject something, offering your definition is the best best objection.
>It seems important for you to refer to these things with visual-basic-like terminology, and I don't think it matters that much.
When talking about Visual Basic implementations. Remeber, lets get the definitions of the concepts hammered down and their implementations. The concept is not language specific.
> Well if you can't design your own objects, then the language is not OOP.
In C, objects are created with malloc(). C simply doesn't have the ability to create object types. CLOS doesn't either- all objects must be classified, but types cannot be used in dispatch specialization.
> Identity is the concept of the unique existance of an object instance. You can certainly work with object instances in small talk. The various waysyou work with objects instances is the concept of reference.
So if I do:
1 print.am I modifying the object "1" or a copy of it? How about this?
1 + 1.How about this?
1 foo: 1How about this?
x foo: barFact is, with smalltalk, you cannot tell what object you're actually working with. You don't know if it's the only instance of an object, if it's making a copy, nor anything about it. Metaclasses can be used to make transparent copies like C++ does, or to forward the messages via proxy. No extra syntax required.
If you cannot see the identity (that is, there is no un-overloadable comparison operator like eq in CL), then it might as well not be there.
> Without a reference to an object identity, there is nothing for the language to work with.
What exactly does this mean in C++:
x.y();Are we working with a reference to "x" in your twisted universe?
If so, then how exactly does this prove does C++ do OOP poorly?
> If you are goning to reject something, offering your definition is the best best objection.
I offered you other people's definitions.
>In C, objects are created with malloc(). C simply doesn't have the ability to create object types. CLOS doesn't either- all objects must be classified, but types cannot be used in dispatch specialization.
C as a language does not provide mechanisms oriented for working with objects. CLOS does.
>If you cannot see the identity (that is, there is no un-overloadable comparison operator like eq in CL), then it might as well not be there.
Smalltalk has the = operator for equality and the == operator for identity as these are 2 different concepts.
>What exactly does this mean in C++: x.y();Are we working with a reference to "x" in your twisted universe?
If x is an instance of an object, be it a pointer, C++ reference or a variable initialized to an instance of an object in scope then yes x is a reference to an object.
>I offered you other people's definitions.
You seem to be focusing on misunderstand implementations of these concepts to prove that that don't exist or don't mean what it is accepted that they mean.
How would you define identity and reference in OOP?
> C as a language does not provide mechanisms oriented for working with objects. CLOS does.
Unqualified. What are the most axiomatic mechanisms that a language must have in order to be considered "object oriented"?
Several languages are considered object oriented, but have orthogonal mechanisms including "message passing/sending", and "multiple dispatch", "dynamic dispatch" (vtables), "direct dispatch", and so on.
> Smalltalk has the = operator for equality and the == operator for identity as these are 2 different concepts.
You're wrong. They're both messages. They mean whatever the receiver thinks they mean. Proxy objects usually redefine the == operator in order to make their use completely transparent.
It's also important in order to implement storage/prevalence mechanisms, so you'll see those applications redefine == as well.
Smalltalk implementors could also choose to redefine == for Symbols if they were implementing Smalltalk in Self.
> If x is an instance of an object, be it a pointer, C++ reference or a variable initialized to an instance of an object in scope then yes x is a reference to an object.
What if "x" is an instance of an object, but isn't a pointer?
string x;In C++: This is clearly not a pointer, and clearly not a reference. What is it if not an instance of a string?
> You seem to be focusing on misunderstand implementations of these concepts to prove that that don't exist or don't mean what it is accepted that they mean.
You are the one that made the extremely broad claim that C++ did OOP poorly, so it is your job to defend that. I made no such claim, so the onus is not on my to attack it.
I don't think the words you're using have been meaningful; they either have overloaded definitions, have been completely irrelevant, or even outright bogus. You're very clearly interested in demonstrating that "C++ does OOP poorly", but have offered nothing to support this except that you don't like the asterisk.
You've tried to make garbage-collection an essential component of object-oriented programming (by defining references as managed), but you've failed to do so as both Java and Smalltalk make it possible to defeat the garbage collector for the purpose of implementing proxy objects.
You've also tried to define object-oriented programming very narrowly, but won't commit to saying languages that fail your definition (like CLOS and Smalltalk) aren't object-oriented.
>Unqualified. What are the most axiomatic mechanisms that a language must have in order to be considered "object oriented"?
Well lets not get ahead of ourselves here. I am pointing out one basic way that C++ does not OOP well. So you need to focus on the OOP concept of reference/identity. You keep wanting to get away from this or go around in circles because I suspect you either just don't understand it, can't separate implementation from concept or know that what I am saying is true.
>Proxy objects usually redefine the == operator in order to make their use completely transparent. They mean whatever the receiver thinks they mean.
Since == is referred to as the identity operator and is used to compare the identity of 2 references, using it any other way is what is known as fucking stupid. I could override the string concatenation operator + to delete the contents of the string and ignore the other string. But I would never do that because its fucking stupid.
Just because the language allows you powerful mechanisms that can be misused by idiots, does not mean those meachinisms (overriding the function of a specific operator to do something the operator is not intended for) does not invalidate the concepts that operator represents.
If a proxy object wants to override the identity operator to make its identity comparison transparent for the object it is being proxy for then great. There is nothing wrong with that. The proxy object is implementing the concept of reference appropriate for what a proxy is. Once would say that the proxy object is acting as a proxy for another object, go figure.
>What if "x" is an instance of an object, but isn't a pointer? string x;In C++: This is clearly not a pointer, and clearly not a reference. What is it if not an instance of a string?
Wow, you are really struggling here. x is a reference to to a string object. It isn't a pointer and it isn't a C++ reference. It is a variable that is a reference to a specific object of type string that uses value semantics to work with the object. If you would have used a pointer or C++ reference you would be working with reference semantics.
>You are the one that made the extremely broad claim that C++ did OOP poorly, so it is your job to defend that.
I am trying very hard, but I keep having to repeat myself. But before I state my reasons again, I need to teach you some thing about OOP.
>I made no such claim, so the onus is not on my to attack it.
That is true, you have only proven you fail to understand the reasons.
>You've tried to make garbage-collection an essential component of object-oriented programming (by defining references as managed), but you've failed to do so as both Java and Smalltalk make it possible to defeat the garbage collector for the purpose of implementing proxy objects.
And this really points out your lack of reading comprehension and inability to understand that different languages may implement the same concepts differently. This will be the third time that I point out that I clearly defined that variables that reference objects in VB.Net, C# and Java are distinguished as reference type variables that are managed type-safe pointers. I have never said or implied that other languages must implement these concepts with the same mechanisms.
>You've also tried to define object-oriented programming very narrowly, but won't commit to saying languages that fail your definition (like CLOS and Smalltalk) aren't object-oriented.
And you have yet to offer a counter-definition. So far all you have done is misapplied the implementation of OOP concepts in specific circumstances to specific languages to incorrectly say that there is no way to define OOP and that all languages are OOP and not OOP at the same time.
> I am pointing out one basic way that C++ does not OOP well.
No you're not. You haven't even defined OOP in any way except as "that which C++ does poorly", or perhaps "without asterisks".
You cannot do that. You must offer a set of definitions that defines OOP, that supports existing languages that are accepted as OOP. I've required that contain at least the following languages: CLOS, Smalltalk, and Python. I've specifically left Simula, Self, and Perl out of that list.
You have failed to do this.
> I am trying very hard, but I keep having to repeat myself. But before I state my reasons again, I need to teach you some thing about OOP.
STOP DOING THAT
Your reasons are so-far inadequate.
If you are incapable of explaining your broad statement "C++ does OOP poorly", then that is your failing, and not mine.
I've pointed to a very simple way that you can demonstrate your point. You can enumerate the things that make OOP, that include accepted OOP languages, that excludes C++.
I've also suggested you appear to an authority we can agree on (like Alan Kay). However, I don't think there are any authorities that agree with you.
Finally, I've also suggested you learn something about what you're talking about. You clearly aren't that familiar with enough different programming languages in order to adequately and concisely compare them.
> Since == is referred to as the identity operator and is used to compare the identity of 2 references, using it any other way is what is known as fucking stupid.
I disagree. If you're writing a prevalence layer that records the contents of (say) a hashtable to the disk periodically, you may need to reload parts of those contents periodically. Without overriding the == to be aware of locations on the on-disk database, your prevalence layer isn't fully transparent.
If you're writing a proxy to copy messages over the network, say for a distributed server, you may want to push a comparitor over the network. Without overriding == you'll need to intern every object that you receive from a remote host, in order for those comparitors to be network-portable.
Now, calling it "fucking stupid" demonstrates you can't think of any reason why you would want to do it. It's not the same thing as proving there aren't any reasons.
By the way, C++ most certainly has an identity; you can use: ((void*)x)==((void*)y) to test for it.
> Just because the language allows you powerful mechanisms that can be misused by idiots, does not mean those meachinisms (overriding the function of a specific operator to do something the operator is not intended for) does not invalidate the concepts that operator represents.
Because == cannot mean that the pair occupy the same memory address, it also means it cannot satisfy your definition of identity.
If an object has identity, but is inaccessible to the program, how exactly does it matter if it has identity or not?
> I have never said or implied that other languages must implement these concepts with the same mechanisms.
Yes, you did. Here:
>>> Object variables contain a type-safe managed pointer to the actual object instance. It is type safe because pointer arithmatic is not allowed. It is managed because the runtime that is executing the code is responsible for memory management and maintaining the pointer to the object instance.
That sure reads a whole hell of a lot like you're defining object variables as type-safe managed pointers.
I don't think you meant it though: Once I pointed out what this meant, you backpedaled:
>>> I am not contending there is 1 correct way to implement the concept of reference.
Even though >>136 definitely contends there is one correct way to implement the concept of reference, and this is it.
Never mind. You indicate now, that managed pointers, and garbage collection don't have anything to do with object-oriented programming. I don't know why you brought it up then, but we can work with that.
So just to enumerate what object-oriented programming is:
That about right?
> And you have yet to offer a counter-definition. So far all you have done is misapplied the implementation of OOP concepts in specific circumstances to specific languages to incorrectly say that there is no way to define OOP and that all languages are OOP and not OOP at the same time.
You keep saying that the onus is on me to do so. You're the one making a broad claim. You seem to think it's all wrapped up in some magic definition of "identity" that you can't point to on another page; that you must describe in prose here, on 4-ch.
Why do you think no one has ever tried to define object-oriented in the way you are doing now? Why do you think you can't point to an authority (like Alan Kay) who agrees with you?
Why can you not use anyone of considerable merit's definitions on this subject? Does this suggest no real programmer does object oriented programming? Or is it simply more likely, that you have no idea what you're talking about
>Why do you think you can't point to an authority (like Alan Kay) who agrees with you?
See, there you were able to give what you feel is a definition of OOP.
Here is a neat email exchange between him and an author:
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
So there, Alan Kay says C++ isn't OOP to him because it doesn't do EXTREME late binding in all things.
I mean my whole thing was that C++ want to create new unique instances of objects when passing it to another scope unless the developer implements mechanisms to maintain an objects uniqueness and that it would be better if it was the other way around because objects are a unique instance of a class.
But Alan Kay kills it with extreme late binding. That really limits the number of actual OOP languages to just a few.
> See, there you were able to give what you feel is a definition of OOP.
I did not.
I said I would accept Alan Kay as an authority. I chose him on purpose because his definition of OOP is incompatible with yours.
> Here is a neat email exchange between him and an author:
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
HTTP/1.1 403 Access Denied.
> I mean my whole thing was that C++ want to create new unique instances of objects when passing it to another scope unless the developer implements mechanisms to maintain an objects uniqueness and that it would be better if it was the other way around because objects are a unique instance of a class.
First of all, C++ programmers don't do that. Stack allocation is very popular in C++. The heap isn't used for objects so much as it is used for buffers.
Second of all, that's a far cry from doing OOP poorly.
>http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
HTTP/1.1 403 Access Denied.
Wow, that site doesn't like 4-ch
Google: alan kay object oriented programing definition
first result
>First of all, C++ programmers don't do that.
That is true, they have to implement extra features of the language to use objects properly.
Lets say I want to paint my house.
class Person {
void Paint(House houseToPaint) {
... }
...
}
class House {
...
}
Person me;
House myhouse;
me.Paint(myhouse);
So what did I just do. I created a new house, painted it and destroyed my new house resulting in my actual house not being painted. Damn the language sucks at working with objects. Lets try what someone else wanted to do...
class Person {
House Paint(House houseToPaint) {
... }
...
}
class House {
...
}
Person me;
House myhouse;
myhouse = me.Paint(myhouse);
Not too bad, I only had to change a few things. But what did I just do? I built a new house just like the old one, moved in to it, painted it, and destroyed my old house.
Clearly, that is more work that I wanted to do.
Lets do something seemingly more practical.
class Person {
House Paint(House* houseToPaint) {
... }
...
}
class House {
...
}
Person me;
House myhouse;
me.Paint(myhouse);
Success! My house is painted without extra steps. All I had to do was type an asterix (or I could have even done an ampersand).
The thing is, why does the language want me to work with myhouse with value type semantics in the scope is was declared and then implement reference type semantics myself when passing to another scope. The language should be oriented towards working with objects. The language clearly supplies me with the mechanisms to do so. But it is left up to me to implement those mechanisms each time I want to work with the object in a practical manner (which is using the instance of the object when I want to work with the instance of an object).
If I am working with objects, I will be working with instances of those objects. The language wants to create a new completley new and unquie instance unless I tell it not to. If the language was oriented to working with objects, when working with an object it should always use the instance unless I tell it not to.
Yeah ,its just a simple astrix but it exposes the fact that the language does not treat object instances as unique entities. The programmer is left up to doing that on theri own.
> Success! My house is painted without extra steps. All I had to do was type an asterix (or I could have even done an ampersand).
You actually need an ampersand. What you wrote isn't valid C++. Person::Paint(House *foo) needs to be called as me.Paint(&myhouse);. Inside Person::Paint(House *foo), foo can be manipulated with ->
Many C++ programmers find it useful; if they're using -> it means they don't own the object and should be careful about stashing it anywhere.
> The thing is, why does the language want me to work with myhouse with value type semantics in the scope is was declared and then implement reference type semantics myself when passing to another scope.
I don't think you understand what you're saying. Inside Person::Paint(House &foo), foo is manipulated as if it were in the parent scope- using ..
C++ programmers don't do this because it's confusing without full exact garbage collection.
> If I am working with objects, I will be working with instances of those objects. The language wants to create a new completley new and unquie instance unless I tell it not to. If the language was oriented to working with objects, when working with an object it should always use the instance unless I tell it not to.
You're running in circles. You can use the copy constructor to get whatever semantics are most-useful in dealing with the kind of object. Without garbage collection, you need using the copy-constructor to be the default, or you cannot track access and usage to an object's resources.
You see, the copy constructor makes it possible to avoid the performance cost associated with object-oriented programming. You'll note that much of C++ is designed to make it possible to avoid performance costs. Turning more control over to the compiler means you get to avoid an asterisk, but it also means you're losing control.
> Yeah ,its just a simple astrix but it exposes the fact that the language does not treat object instances as unique entities. The programmer is left up to doing that on theri own.
So what? Several object-oriented languages don't treat instances as unique, as we've been over before.
>>150 "(To link to this page, please use the canonical URI "http://www.purl.org/stefan_ram/pub/doc_kay_oop_en" only, because any other URI is valid only temporarily.)"
Thanks >>152 , but I'm still getting access denied.
Any mirrors?
>>153
Just copy and paste the url, or turn off your referrer header. Works fine.