Re: [boost] [function types] New tag type logic [update]

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-03 16:09:29

Rob Stewart wrote:
> From: Tobias Schwinger <tschwinger_at_[hidden]>
> 
>>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