3 ms·

> > It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to

> > It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to be able to automatically generate the rendering code for my widget based on the existing rendering logic for its constituent shapes. Actually, what's interesting is that both Lisp macros and C++ templates allow this to work pretty easily if you set up the boiler plate well enough. All this article is really talking about is making it easier to set up and use that boilerplate (e.g. put it in the language). > What's really huge for maintainability is this thing called aspect-oriented programming: Don't litter each of your classes with a line of boilerplate for this and another line for that. Make a file "serialize.cpp" that contains the serialization code for all the types, and nothing else. And that works if your project is not meant to ever be extended. But generally the point of having object oriented systems is being able to make new objects that can take the place of old ones. Of having abstraction.

jstimpfle 9y ago
If by "abstraction" you mean ADTs - of course there are some (not many) places where they are useful. And you can easily have them or change to them later. It's just another few lines of boilerplate to make a few method tables. But I don't like to have the implementation logic in the places where method dicts are wired, especially for interfaces with very little coherency, like GameModel3d: render, click, contextString, serialize... Doing that instead of aspect-oriented is a violation of the "separation of concerns" principle.
- tcbawo 9y ago
  Isn't the dream of a reflection library to build serialization using an Observer pattern, where the serialization logic is unbounded and business logic never mixes? It would be great if the standard came up with something that would be so broadly useful and allow developers to focus on their domain instead of serialization.

jstimpfle 9y ago

If by "abstraction" you mean ADTs - of course there are some (not many) places where they are useful. And you can easily have them or change to them later. It's just another few lines of boilerplate to make a few method tables. But I don't like to have the implementation logic in the places where method dicts are wired, especially for interfaces with very little coherency, like GameModel3d: render, click, contextString, serialize... Doing that instead of aspect-oriented is a violation of the "separation of concerns" principle.

tcbawo 9y ago
Isn't the dream of a reflection library to build serialization using an Observer pattern, where the serialization logic is unbounded and business logic never mixes? It would be great if the standard came up with something that would be so broadly useful and allow developers to focus on their domain instead of serialization.