Re: [Boost-users] [MPL] Front of a set of types

Subject: Re: [Boost-users] [MPL] Front of a set of types
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-09-01 04:39:15

On Tue, Sep 1, 2009 at 2:18 AM, Marco Guazzone<marco.guazzone_at_[hidden]> wrote:
> On Mon, Aug 31, 2009 at 10:51 AM, OvermindDL1<overminddl1_at_[hidden]> wrote:
>> Yea, I agree that the documentation on this should be cleared, not
>> necessarily by saying that front returns possibly any element, but
>> rather how it internally stores the type so we know what things like
>> front/back/etc. will actually do. Â :)
>
> Hmmm... But in this way (i.e., tying an high-level behavior to a
> low-level detail) we (as users) loose any advantage of encapsulation.
>
> I think it would be better to fix (and document) the behavior of
> "front< set >" regardless of the internal representation of a set.
> That is, the front element of a set is "blah blah blah" regardless of
> how a set is internally implemented.
>
> Another solution is to deprecate and subsequently remove this
> operation from sets; but probably this impacts on backward
> compatibility.
>
> Ah, obviously the same issue apply to mpl::map (didn't tried yet but
> conceptually the front of a map has an ambiguos meaning)

I just think of it this way, front() will get the first element in a
container, now sometime those containers are linear, like vector or
list or cons, but other times they are not linear, then who knows what
I may get first, like with set and map.  Besides, is it not more
proper to use an iterator?  I have never personally used front, always
use an iterator since I need all elements to test with when using a
set/map, only ever used it with vector/list/cons, where it makes
sense.