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

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2010-03-05 18:31:48

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().
>
> 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.

Thank you for the hint.
Joachim