On 21.12.2010 18:45, Bruno Medeiros wrote:
On 09/12/2010 21:55, Simon Buerger wrote:
From a pragmatic viewpoint you are right, copying containers is rare.
But on the other hand, classes imply a kind of identity, so that a set
is a different obejct then an other object with the very same elements.
Yeah, classes have identity, but they retain the concept of equality.
So what's wrong with that? Equality comparisons would still work the
same way as by-value containers.
Identity is wrong, because if I pass th set {1,2,3} to a function, I
would like to pass exactly these three values, not some mutable
object. This may imply that the function-parameter should be const,
which is probably a good idea anyway. I want it to be mutable, I want
to use "out"/"ref", the same way as with the simple builtin-types.
That feels wrong from an aesthetical or mathematical viewpoint.
Aesthetics are very subjective (I can say the exact same thing about
the opposite case). As for a mathematical viewpoint, yes, it's not
exactly the same, but first of all, it's not generally a good idea to
strictly emulate mathematical semantics in programming languages. So
to speak, mathematical "objects" are immutable, and they exist in a
magical infinite space world without the notion of execution or
side-effects. Trying to model those semantics in a programming
language brings forth a host issues (most of them
performance-related). But more important, even if you wanted to do
that (to have it right from a mathematical viewpoint), mutable
by-value containers are just as bad, you should use immutable data
instead.
You might be right that modeling mathematics is not perfect, at least
in C/C++/D/java. Though the functional-programming is fine with it,
and it uses immutable data just as you suggested. But I'm aware that
thats not the way to go for D.
Anyway, though total math-like behavior is impossible, but with
auto A = Set(1,2,3);
auto B = A;
B.add(42);
letting A and B have different contents is much closer to math, than
letting both be equal. Though both is not perfect.
And for the "immutable data": Its not perfectly possible, but in many
circumstances it is considered good style to use "const" and
"assumeUnique" as much as possible. It helps optimizing,
multi-threading and code-correctness. So it is a topic not only in
functional programming but also in D.
Furthermore, if you have for example a vector of vectors,
vector!int row = [1,2,3];
auto vec = Vector!(Vector!int)(5, row);
then vec should be 5 rows, and not 5 times the same row.
Then instead of "Vector" use a static-length vector type, don't use a
container.
Maybe you want to change that stuff later on, so static-length is no
option. Following example might demonstrate the problem more clearly.
It is intended to init a couple of sets to empty.
set!int[42] a;
version(by_reference_wrong):
a[] = set!int.empty; // this does not work as intended
version(by_reference_correct):
foreach(ref x; a)
x = set!int.empty;
version(by_value):
//nothing to be done, already everything empty
Obviously the by_value version is the cleanest. Furthermore, the first
example demonstrates that by-reference does not work together with the
slice-syntax (which is equivalent to the constructor-call in my
original example). Replacing "set!int.empty" with "new set!int" doesnt
change the situation, but make it sound only more weird in my ears:
"new vector"? what was wrong with the old one? and I dont want "_an_
empty set", I want "_the_ empty set". Every empty set is equal, so
there is only one.
Last but not least let me state: I do _not_ think, that
value-containers will go into phobos/tango some day, that would to
difficult in practice. I just want to state that there are certain
reasons for it. (And originally this thread asked for some small
changes in the language to make it possible, not the standard).
Krox
ps: I'll go on vacation now, see you next year, if there is still need
for discussion. Merry christmas all :)
