|
Boost : |
From: Marcus Lindblom (macke_at_[hidden])
Date: 2006-10-13 04:11:51
Dave Harris wrote:
> In-Reply-To: <4528E0F8.1070503_at_[hidden]>
> macke_at_[hidden] (Marcus Lindblom) wrote (abridged):
>
>> The point I'm trying to make is that there is as almost much opinion on
>> member-access on vectors as there are on code indent size. So, whatever
>> we make ought to support everything, if we want it to be acceptable to
>> a large audience?
>>
>
> And I was making the more-or-less opposite point, that the interface
> doesn't matter too much as long as it doesn't expose the representation.
>
I believe some of my later posts on the topic are a bit more biased in
this direction. Or at least, I've come to think we should make something
that's encapsulation indifferent (i.e. that uses traits or whatever to
access values.). That would allow existing code to use the new
algorithms/ops.
> The core question is whether encapsulation matters for a class like this.
> With emphasis on the "like this" - I'm sure we all love encapsulation
> normally, and the issue is whether this is one of the rare exceptions. If
> we support the v.x syntax we can't store vectors in polar representation,
> or add checks or instrumentation to accesses, or have values that are
> calculated on demand, or use any number of other techniques which rely on
> information hiding. Does it matter in this case?
>
Don't really know.
> It's ultimately a judgement call, and I don't think my own opinion should
> carry any special weight, so I will try to stop posting about it after
> this and let you get on with it.
>
I'm not developing, I'm just expressing opinions, so I should probably
do likewise. :)
Cheers,
/Marcus
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk