Hacker News Comments on
Component Software: Beyond Object-Oriented Programming (ACM Press)
·
10
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this book.Ironically, the ECS advocates kind of miss the part that ECS models are based on OOP literature.https://en.wikipedia.org/wiki/Component-based_software_engin...
"Component Software: Beyond Object-Oriented Programming"
https://www.amazon.com/Component-Software-Beyond-Object-Orie...
"Component Software: Beyond Object-Oriented Programming"https://www.amazon.com/Component-Software-Object-Oriented-Pr...
The first edition uses Component Pascal instead,
https://www.amazon.com/Component-Software-Beyond-Object-Orie...
Then even if it hasn't taken the world by storm,
"Designing Object Oriented C++ Applications Using The Booch Method"
https://www.amazon.com/Designing-Object-Oriented-Application...
Assuming you also feel like reading about UML design stuff
"Object-Oriented Analysis and Design with Applications"
https://www.amazon.com/Object-Oriented-Analysis-Design-Appli...
⬐ rendallThanks!
They have, but there is a certain tendency to ignore CS literature."Component Software: Beyond Object-Oriented Programming"
https://www.amazon.com/Component-Software-Beyond-Object-Orie...
1st edition, 1998
Not a game, but standard software models,"Component Software: Beyond Object-Oriented Programming", 1998
As I mentioned in another thread,"Component Software: Beyond Object-Oriented Programming", 1998
ECS like systems were well known in CS even before that."Component Software: Beyond Object-Oriented Programming", 1998
It is a bit hard to just explain in a bunch of comments.In your examples you need to add extra layers, just like you would do with the microservices.
There would be the DTOs that represent the actual data that gets across the models, the view models that package the data together as it makes sense for the views, the repository module that actually abstracts if the data is accessed via SQL, ORM, RPC or whatever.
You should look into something like:
"Domain-Driven Design: Tackling Complexity in the Heart of Software"
https://www.amazon.com/Eric-J-Evans/dp/0321125215
"Component Software: Beyond Object-Oriented Programming"
https://www.amazon.com/Component-Software-Beyond-Object-Orie...
Start here,"Object-oriented programming: Some history, and challenges for the next fifty years"
https://www.sciencedirect.com/science/article/pii/S089054011...
Than read on BETA design for example,
Follow up with "The Art of the Metaobject Protocol",
https://mitpress.mit.edu/books/art-metaobject-protocol
and "Xerox LOOPS"
http://www.softwarepreservation.org/projects/LISP/interlisp_...
Then "Component Software: Beyond Object-Oriented Programming" (the 1st edition with Component Pascal)
https://www.amazon.com/Component-Software-Beyond-Object-Orie...
"Applying Traits to the Smalltalk Collection Classes"
https://rmod.inria.fr/archives/papers/Blac03a-OOSPLA03-Trait...
"Self – The Power of Simplicity"
http://media.cichon.com/talks/Introduction_Self_Language_OOP...
https://blog.rfox.eu/en/Programming/Series_about_Self/index....
How about this for starters?
⬐ tom_melliorThis is pretty good for starters! It makes it clear that you're not interested in a real discussion. Requiring that people read The Art of the Metaobject Protocol before you'll engage with their arguments on whether C++ programmers write OOP code is clearly just evasion on your part.This isn't knocking the book, I've read it and agree that it's edifying. This list is a good resource on OOP in general. It's just not helpful in the context of this thread.
⬐ pjmlp⬐ discreteevent> If you have knowledge, share it, or at least share concrete references to concrete resources where one might learn what you think should be learned.Your own words, documentation and knowledge was shared, apparently you are the one not interested.
⬐ tom_melliorYou missed the "concrete" part. Which of these sources, concretely, should one read to evaluate the claim that "Modern C++ generally doesn’t use OOP all that much anyways.", which is what you seemed to criticise in this subthread?Again: Does one really, concretely, have to read The Art of the Metaobject Protocol, a book about Lisp, to evaluate this claim about C++? Having read the book, I would say no. Which is why I say that you are evading a real discussion.
(And for that matter, it would be interesting if you fleshed out your counter-claim -- "Other than the classes used to implement all those STL concepts." -- in a bit more detail. Are you saying that all uses of C++ classes are OOP? Or that only certain uses are, but that the way classes are used to implement the STL fall into this category? Will I find the answer to these concrete questions in The Art of the Metaobject Protocol?)
⬐ pjmlp> Are you saying that all uses of C++ classes are OOP?Definitely, any use of class constructs with data members and member functions is OOP.
Any use of data members inside class constructs represents aggregation and if any member function on a data member happens to be called, as means to help a member function to do their work, that is delegation.
Any template implemented as class that uses its type parameters to decide at compile time what gets called, makes use of dynamic dispatch decided at compile time.
If you prefer we can pick any random STL type and dissect all their uses of OOP features, lets start with something like std::set?
⬐ ncmncm> Definitely, any use of class constructs with data members and member functions is OOP.Definitely not.
OOP requires, also, runtime binding and polymorphism. You can get the polymorphism by inheritance, delegation, or what-have-you. You can get runtime binding with a vtable or a name lookup.
The usual term for just-encapsulation is "object-based". The STL is definitively not object-oriented, according to its author, Stepanov, who has said that giving the STL classes member functions was a mistake.
OOP is a niche technique. It has uses, sometimes. More often, a function pointer suffices.
⬐ pjmlpNo it doesn't, hence why I mentioned that one should learn what OOP is all about.Object based languages are part of the OOP universe from CS point of view, plenty of literature, that apparently is too much to ask to read about, some of which I have provided above.
So here we go about std::set and it being OOP.
1 - class set, a means for encapsulation, with most of its members de
2 - Uses delegation for memory allocation via the allocator_type
3 - Uses delegation for key lookups and value comparisasion
4 - Implements the concepts Container, AllocatorAwareContainer, AssociativeContainer, ReversibleContainer alongside their respective concept dependencies, which in OOP speak are protocols/traits/categories;
5 - The actual types used for comparisaion and allocation are instances of the respective protocols, with dispatch being decided at compilation time of std::set uses, given the respective implementations as type parameters, in a way similar to multi-method-dispatch.
As bonus here is a simplified UML diagram. It isn't more detailed, because my patience to draw ASCII art is limited.
------------------------------------------------------------------------------------------- |std| | ----- | | __________________ | | | <<protocol>> | | | | Container | | | |-----------------| | | |-----------------| | | |-----------------| | | | constructor | | | | copy-constructor| | | | destructor | | | | begin() | | | | end() | | | | cbegin() | | | | cend() | | | | swap() | | | | size() | | | | max_size() | | | | empty() | | | ------------------- | | /\ | | -- | | | extends | | | | | ______________ _______________________ _______________________ | | | <<protocol>>| | <<protocol>> | | <<protocol>> | | | | Allocator | | ReversibleContainer | | AssociativeContainer | | | |-------------| |----------------------| |----------------------| | | |-------------| |----------------------| |----------------------| | | | constructor | | rbegin() | | key_comp() | | | | destructor | | rend() | | value_comp() | | | | allocate | | crbegin() | |----------------------| | | | deallocate | | crend() | /\ | | | max_size | |----------------------- -- | | | construct | /\ | | | | destroy | -- implements | | | --------------- | | | | /\ | | | | -- | implements / | | | \ / | | | implements \ / | | | \ / | | | \------------------ | | | | | | | | | | | ------------------ | | ---------------- | <<protocol>> | | | | allocator<T> | uses | set | | | |---------------|<------------------------/\|------------------| | | |---------------| \/| constructor | | | | destructor | | | | begin() | | | | end() | | | | cbegin() | | | | cend() | | | | rbegin() | | | | rend() | | | | crbegin() | | | | crend() | | | | operator= | | | | get_allocator() | | | | empty() | | | | size() | | | | max_size() | | | | clear() | | | | insert() | | | | emplace() | | | | emplace_hint() | | | | erase() | | | | swap() | | | | extract() | | | | merge() | | | | count() | | | | find() | | | | contains() | | | | equal_range() | | | | lower_bound() | | | | upper_bound() | | | | key_comp() | | | | value_comp() | | | ------------------ | |-----------------------------------------------------------------------------------------|⬐ ncmncmIt has and does all of these things, but it does not have runtime binding, therefore by definition is not object-oriented.Concretely, you cannot take a Container pointer and point it at a std::set. You can take a T, and bind T to std::set at compile time; but that is Generic Programming: analogous, in some ways, but not the same.
In the '90s it was fightin' words to say "X is not Object Oriented", because Object-Oriented was taken as a high-status way to say Good, and "Not Object-Oriented" translated implicitly to "Not Good".
But in our brave new world, object-oriented is but one design discipline, and we have others, and enough language primitives to construct our own disciplines by mix-and-match as problems dictate.
And, I have myself simplified code that had used a virtual function to use, instead, a function pointer, and it was (still) Good. Better, even.
⬐ pjmlp> It has and does all of these things, but it does not have runtime binding, therefore by definition is not object-oriented.What renowned SIGPLAN or IEEE paper states that runtime binding is required for 100% of all OOP programming languages ever created and polymorphic dispatch at compile time doesn't count?
⬐ ncmncmNot interested in classifying programming languages, or in SIGPLAN- or IEEE-sanctioned opinions.Changing the definition would be moving the goalposts. A new definition deserves a new word.
Alan Kayhttps://news.ycombinator.com/item?id=11940050
On Understanding Data Abstraction Revisited
https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
The Power of Interoperability: why objects are inevitable
https://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf
A closure is a poor man's object
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
Neither => Component Based Programming,"Component Software: Beyond Object-Oriented Programming"
https://www.amazon.com/Component-Software-Beyond-Object-Orie...
https://www.amazon.com/Component-Software-Object-Oriented-Pr...
Which is ironic, given that people tend to forget that it was C++ which made OOP mainstream, there wasn't any Java or C# back then, two fully OOP based languages.The other part is that component oriented programming is actually a branch of OOP, from CS point of view, with books published on the subject at the beginning of the century.
"Component Software: Beyond Object-Oriented Programming"
https://www.amazon.com/Component-Software-Beyond-Object-Orie...
First edition uses Component Pascal, Java and C++, with the 2nd edition replacing Component Pascal for C#.