Ubuntu's Unity Written In Qt/QML For "Unity Next"

[dee.]

C++ method is different from C function. Method is part of class namespace, but function is declared in global namespace.
In real OOP data are private and you have to use methods to access data. Direct access to private data in structure passed as reference isn't possible.
Vala compiler converts OO code to non-OO code. C code is never real OO code.

Seriously guy, you're starting to sound like a high school computer class teacher. Really sure that what you're saying is right, just because you've had one more course than your students, while the ones who actually know computers snicker in the back row seats and roll their eyes....

Can you please realize that OOP is not a language-dependent feature. It's a programming method, which can be used on pretty much any language - even assembler, you just have to build the abstractions yourself.

NONE of the features which you claim are necessary for OOP actually are. Namespaces are irrelevant, do you know anything about name mangling? Yeah, those C++ methods of yours are actually converted to C functions at compile time, and the namespace, class name etc. are appended to the function name, according to a complex scheme. So in the end there is no practical difference to a function and a method. And also, you actually CAN access private data directly in C++, because C++ doesn't have real runtime encapsulation.

[dee.]

They have dynamic/anonymous classes.

What are you even talking about. No...

[Luke_Wolf]

Seriously guy, you're starting to sound like a high school computer class teacher. Really sure that what you're saying is right, just because you've had one more course than your students, while the ones who actually know computers snicker in the back row seats and roll their eyes....

Can you please realize that OOP is not a language-dependent feature. It's a programming method, which can be used on pretty much any language - even assembler, you just have to build the abstractions yourself.

NONE of the features which you claim are necessary for OOP actually are. Namespaces are irrelevant, do you know anything about name mangling? Yeah, those C++ methods of yours are actually converted to C functions at compile time, and the namespace, class name etc. are appended to the function name, according to a complex scheme. So in the end there is no practical difference to a function and a method. And also, you actually CAN access private data directly in C++, because C++ doesn't have real runtime encapsulation.

This ^

OOP is purely about modeling things, their interactions, their properties, and their relationships with other things. There are nice language specific tools that make this easier for you such as classes and properties but they're just tools that embody standard design patterns. The blocking out direct access thing for instance is to model how you interact with things, lets say you have a thermostat you're not directly reading the temperature setting off of the central heating, nor are you setting it directly, you're going through the thermostat which is using the central heating's interface to control it. Yes you could bypass the thermostat but you'd need something to read off of the central heating's interface...

Also object orientation as I've stated previously in this thread isn't specific to programming, it's general to linguistics as a whole and is how language is actually used. So english for instance is OO go a couple pages back for the breakdown. In relational databases there's this process called normalization which is really a fancy term for breaking things down into objects. Even if you don't work with databases normalization is still a great thing to learn because of that, because it helps you figure out how you design your objects and how things break down. Then we've got the mark-up languages which are really just data languages where you're organizing data into objects, but you'll note that markup languages are completely declarative they have no methods or anything else really other than constructs for nouns yet they are OO. So yeah...

[dee.]

Also object orientation as I've stated previously in this thread isn't specific to programming, it's general to linguistics as a whole and is how language is actually used. So english for instance is OO go a couple pages back for the breakdown. In relational databases there's this process called normalization which is really a fancy term for breaking things down into objects. Even if you don't work with databases normalization is still a great thing to learn because of that, because it helps you figure out how you design your objects and how things break down. Then we've got the mark-up languages which are really just data languages where you're organizing data into objects, but you'll note that markup languages are completely declarative they have no methods or anything else really other than constructs for nouns yet they are OO. So yeah...

"Object" in grammar and linguistics is not the same thing as "object" in programming languages.

[JS987]

Encapsulation? You can do it, the compiler don't help you obviously. But you can do it in c? Dee. has already said how. Structs with data and with functions with pointers to operate on the data and you have a simple solution.
I do not now any practical easy way to get inheritance (I'm sure you can do it?) but I don't think that is a requirement for OOP. I'm sure most of the basic OOP patterns is older than the OOP languages.

You can't have same encapsulation with C as with C++ because C doesn't support methods and private data.
Languages like C++, Java, C# support and their libraries are using inheritance, which isn't recent invention as C++ is 30-year-old.

[JS987]

Seriously guy, you're starting to sound like a high school computer class teacher. Really sure that what you're saying is right, just because you've had one more course than your students, while the ones who actually know computers snicker in the back row seats and roll their eyes....

Can you please realize that OOP is not a language-dependent feature. It's a programming method, which can be used on pretty much any language - even assembler, you just have to build the abstractions yourself.

NONE of the features which you claim are necessary for OOP actually are. Namespaces are irrelevant, do you know anything about name mangling? Yeah, those C++ methods of yours are actually converted to C functions at compile time, and the namespace, class name etc. are appended to the function name, according to a complex scheme. So in the end there is no practical difference to a function and a method. And also, you actually CAN access private data directly in C++, because C++ doesn't have real runtime encapsulation.

You shouldn't create any abstractions. You don't have to create abstractions with C++. Using C with non-standard emulation of OOP instead of C++ which supports OOP is retarded.
It doesn't matter how compiler compiles code.
You can access private data using pointer, but you are doing it intentionally to break encapsulation.

[Luke_Wolf]

"Object" in grammar and linguistics is not the same thing as "object" in programming languages.

Actually yes, yes they are. They're exactly the same thing because object is just a fancy word for "noun" and saying "There is a red apple" is saying that a location object named "there" has an "apple" object which has a property "color" that is set to "red", which also has implicit properties of being a food and a type of fruit and so on...

[Luke_Wolf]

You shouldn't create any abstractions. You don't have to create abstractions with C++.

You don't know what you're saying. Modeling is inherently about abstracting information into something that can actually be worked with, and even if you're going to turn around and restrict that to OOP design patterns. For instance C++ doesn't have properties at the language level and so in Qt we use a macro to get around that issue, which is essentially a wrapper around a private piece of data, a getter, and a setter.

Using C with non-standard emulation of OOP instead of C++ which supports OOP is retarded.

Yeah it is kinda slow to have to write those capabilities for abstracting the related design patterns in yourself as opposed to just using one of the languages that already has done most of the work for you in that regard. That doesn't however mean that you can't use or create those standard design patterns yourself. It's slow and painful, and likely to be buggy as you're building up from scratch as opposed to using something well tested but you can do it.

[dee.]

Actually yes, yes they are. They're exactly the same thing because object is just a fancy word for "noun" and saying "There is a red apple" is saying that a location object named "there" has an "apple" object which has a property "color" that is set to "red", which also has implicit properties of being a food and a type of fruit and so on...

Actually, no. "Object" in grammar has a very specific meaning - it's part of a sentence structure. In many languages the basic structure is subject - predicate - object (although the order varies depending on the language). The subject defines the actor, the predicate defines the type of action, and the object defines the target of the action. For example: "Luke eats Apple" - the object in this sentence is "Apple" ("Luke" is the subject, and "eats" is the predicate).

Whereas, in programming, an object can be - depending on the language - anything. A variable, a function, a reference, a module... any of these things can be objects. In a language that treats functions as first-class objects, such as Python for example, a function is an object, but grammatically speaking, a function is a predicate - it defines the type of action that is applied on some other object(s). The definition of "object" in programming is much more flexible than the grammatical definition.

[Luke_Wolf]

Actually, no. "Object" in grammar has a very specific meaning - it's part of a sentence structure. In many languages the basic structure is subject - predicate - object (although the order varies depending on the language). The subject defines the actor, the predicate defines the type of action, and the object defines the target of the action. For example: "Luke eats Apple" - the object in this sentence is "Apple" ("Luke" is the subject, and "eats" is the predicate).

Whereas, in programming, an object can be - depending on the language - anything. A variable, a function, a reference, a module... any of these things can be objects. In a language that treats functions as first-class objects, such as Python for example, a function is an object, but grammatically speaking, a function is a predicate - it defines the type of action that is applied on some other object(s). The definition of "object" in programming is much more flexible than the grammatical definition.

Okay that's a fair point and I blame the people who came up with the name OOP for making the terminology break (and entrenched vocabulary means that it can't be fixed now to something like "Modeling Based Design"). It doesn't change that language as a whole is object oriented in the programming sense of the term though, because in the programming sense that sentence says that I as a person object am interacting with an apple object by the method of eating it.