Re: [boost] [Review] ITL review starts today, February 18th

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-03-05 20:30:31

Joachim Faulhaber wrote:
> 2010/3/5 Stewart, Robert <Robert.Stewart_at_[hidden]>:
>> Joachim Faulhaber wrote:
>>> 2010/2/28 Barend Gehrels <barend_at_[hidden]>:
>>>> and then gives the example " mySet.contains(42)". But
>>>> contains is NOT an method of std::set, but YES from
>>>> interval_set. This was confusing.
>>> my view on sets here is not governed by std::sets but rather by the
>>> mathematical notion of a set or the itl::Set concept that is part of
>>> my documentation. In this view the "is element of" function is pretty
>>> fundamental and it is available for itl::interval_set and for itl::set
>>> as bool T::contains(const domain_type&);
>> [snip]
>>> Which is the common interface, the fundamental aspect, that
>>> constitutes this semantic kernel? Would that signature contain
>>> find(x)? Would it contain contains(x)? Would it provide iterators?
>>>
>>> boost::dynamic_bitset does not implement find, it does not implement
>>> iterators. Would we therefore say it is not a set? Its signature does
>>> not provide contains(x) but it contains test(x), which IMO should be
>>> called contains(x).
>> I'm speaking from partial ignorance, but...
>>
>> Wouldn't it be better to use non-member functions for those
>> operations expected of a set?  Then, boost::dynamic_bitset would
>> satisfy itl::contains(bitset, x) because it could be implemented in
>> terms of test().  Likewise, std::set would satisfy because
>> itl::contains(s, x) could be implemented in terms of find().

I use std::set::count for contains.

>> Using that approach, your concepts would apply to any type for
>> which a specified set of non-member functions can be applied while
>> meeting specific semantic requirements.  I should think many more
>> types could be adapted to ITL without needing specific support form
>> ITL with that approach.
> 
> The decision to keep a few functions, like
> 
> bool T::contains(const domain_type&);
> 
> member functions although they could have been implemented as global
> functions comes from a residual resistance of a brain that has been
> thinking in OO-designs for too long ;-) Also I found
> 
> s.contains(x)
> 
> a little more readable than
> 
> contains(s,x)
> 
> but this is a minor advantage compared to the benefits of the global
> function that you described concisely. Luke already took the same line
> in this discussion and I certainly will improve the design in this
> respect.

That's good to hear. Better interaction with existing std and user 
defined types en lieu of itl specific types addresses my main concern 
with the library. So give this a +1 from me.

Jeff