Rob Stewart wrote:
From: Tobias Schwinger <tschwinger@neoscientists.org>
Rob Stewart wrote:
groups covered by a single tag are just that -- groups or combinations of tags.
The tags in the reference are all "aspect tags": One for each "variation" of each "aspect" there is.
Some represent groups of variations, right?
Well, not exactly. Some _match_ groups of (other) variations (in an appropriate context) *but* _represent_, well, /abstract/ concepts that include them.
In that sense, they do represent groups of variations. That is, "any_decoration" covers "reference_decoration" and the others. I don't mean that it is a bit pattern that includes the bits from the others, just that when you match reference_decoration, you can also match any_decoration.
Having said that, however, it is not true that reference_decoration is a specialization of any_decoration. Instead, it's like color and red. Red is not a specialization of color; it's an instance or example of color. You could model this with a class called Color and one called Red, but you'd be much more likely to have Red be an instance of Color. If you then have an "any color" object, you would probably model that with a special Color instance, not with a base class for the normal colors. Thus, Red isn't a specialization of "any color" but just another Color.
Red is a color (and that's what counts). Whether it is good design to use inheritance here or not is pretty much a matter of what having that color means in your particular context (and if there is code or only data). "Color" is an abstract concept (at least by the Webster's-defintion): Something can be colored but can't in itself; it takes a particular color for something to be colored. <snip>
It isn't that they are improper words or that they can't be set in context. It is that the cognitive effort needed to learn the vocabulary of the library can be more complicated than understanding the library itself. Just discussing the behavior and syntax may be sufficient in many cases. Creating a term for something can complicate matters.
I agree. A lot of these problems should have been eliminated by now, though. http://lists.boost.org/boost/2005/07/29659.php http://lists.boost.org/boost/2005/07/29657.php
-> what's wrong with "abstract?" <-
Precisely what I've been saying all along. It implies a generalization/specialization relationship that I don't see.
I believe it's a matter from which perspective and with which level of abstraction we look at things. However I consider this point solved, since this part has been removed from the interface.
Have I've helped you understand my thinking with this message?
Yes, I think can understand your perspective looking at it. <snip>
Fine. I'm lost then and I'm sorry to say I can't spend much more time on this.
Fine with me. Thank you for your help! I enjoyed discussing with you. Regards, Tobias