51–60 of 72 posts
A value, with a type. Nothing else. Stop highjacking everything into your OO religion. If you take everything of a value that originated elsewhere, there will be nothing left in the OOD.
Okay, now give me some collection like object, who can handle everything. No, don't use void*. There are some benefits if everything is an object, like generics.
Okaaaaaaay, so if we left everything what OOP gived us (properties^1, generics, lot of good patterns^2, lot of abstractions for generic things, like interface^3, events, higher level datastructures, delegates, namespaces, modules^4 etc.) then we get C? Omg, thank you Captian Obvious! Learn OOP first. What a bullshit article. 1) C++ for OO example? Seriously, why??? Grab a modern language who have properties at least.…
Earlier quoted context omitted.
Are you saying all these outlets (labels, text box, buttons) are inheriting from a base FormObject that can be rendered? That would work without OOP. Make a FormRender component that manages that logic (being rendered in a form) and other components, one that manages a keyboard, other that can be clicked and handle hover, touch states, etc.
Sure, but routing get's complex in your solution. The point was OOP is a natural fit for collections of different types in some context ex:GUI, Simulation, etc. The classic OOP case is probably a MUD where OO code ends up being very straightforward. IMO, the problem is it works really well in so many contexts that people end up trying to use it everywhere.
Earlier quoted context omitted.
A struct is an object. Even a plain integer is an object, considering the referred article was talking about C++. (Yes, you cannot inherit all kinds of objects – but you definitely can inherit any kind of struct, POD or not.)
Well, if everything is an object, I guess everything is an object. Usually when people are talking about OO objects they mean data+behaviour.
The distinction between behavior being "a set of methods defined inside a class", and "a set of methods whose first param is a particular type of struct" is not that important.
Earlier quoted context omitted.
> Without inheritance, as soon as you want to cast mixer to something else, you're either relying on binary wizardry by the compiler Why would you want to cast mixer to something else? What real-life task does it solve? > If we assume we have both a hardware mixer and a soft mixer which both have the set volume method, we wan't polymorphism so we can treat them equally. Polymorphism isn't OOP feature. You can have ov…
> Why would you want to cast mixer to something else? Did you ever heard about interfaces? You can have a IMixer interface, a Mixer baseclass and some concrete mixer classes depending on your task. Like null-mixer for mocking, software mixer for legacy computers, hardware mixer with GPU support, etc. Use your imagination, Luke!
>Now here's what this would look like in C++ without using objects: mixer_set_volume(m, 0.8); What is m, if not an object?
The point is not a lack of objects but a lack of OOP. Yes, there are "objects" but there is also a separation between objects and methods etc.. The issue with m->set_volume(.08) is it becomes difficult to tell what happens inside set_volume() because in the method scope you have access to the internals of the "m" object, not just the interface. With mixer_set_volume(m, .08) you have ".08" and "m" but only the interfa…
>> The issue with m->set_volume(.08) is it becomes difficult to tell what happens inside set_volume()
Isn't that the point? That you shouldn't have to care what happens inside set_volume? If mixer was designed and implemented well, then set_volume (along with the rest of its interface methods) should consistently and correctly handle its internal state.
Earlier quoted context omitted.
Exactly. OOP is: a) A code naming/organisational issue b) Some formalisation of structure, so that developers can specify what is/isn't allowed in their code. Both of thise have advantages and disadvantages, and the structure can be over-formalised and made too complex. But this doesn't make OOP bad. It makes bad design bad.
Well yes, when you redefine "OOP" to mean "well-organized code," then all well-organized code is object-oriented. That's not what people mean when they refer to OOP though -- they're talking about data+behavior encapsulation, inheritance, message-passing, etc.
Earlier quoted context omitted.
Okay, now give me some collection like object, who can handle everything. No, don't use void*. There are some benefits if everything is an object, like generics.
Ever seen STL? It is as anti-OOP by design as it gets.
Okaaaaaaay, so if we left everything what OOP gived us (properties^1, generics, lot of good patterns^2, lot of abstractions for generic things, like interface^3, events, higher level datastructures, delegates, namespaces, modules^4 etc.) then we get C? Omg, thank you Captian Obvious! Learn OOP first. What a bullshit article. 1) C++ for OO example? Seriously, why??? Grab a modern language who have properties at least.…