> -----Original Message-----
> From: chromatic [mailto:[EMAIL PROTECTED]
> We are trying to avoid the "java.lang.String is Final"
> problem here in various ways. One of them is not allowing
> library designers to mark things as final.
Overloading "final" was Java's rather inept attempt to define objects with
value semantics rather than container semantics (*1). I would be in favour of
P6 using some much more explicit way of marking that distinction. And using
shorter Huffman coding for "value" than for "container". And work nicely with
"compound literals". And still DWIM. :-)
I'm not entirely convinced that just tagging stuff with ":rw" or ":ro" is the
right way to go; it has too coarse a granularity, so it misses opportunities
for optimization. Using "const" works fine in C++ where pass-by-value is the
default (or at least, has shorter huffman coding) and you get almost-reasonable
copy constructors generated for you. But as we're currently defining Perl6,
anything that's an object is passed by reference by default (*2), and object
aren't actually "inside" other objects, merely referenced by them (*3).
A "const" parameter in C++ lets you pass something to a function and the
function promises not to modify it; what's missing (from C++) is the ability
for the caller to promise not to modify it either.
Likewise in P6 we have no way to pass a "value" object to a sub and at the same
time make a promise to that sub that the "value" won't change under it. Or put
another way, we have no way to tell the sub that it doesn't have to take a copy
to be sure it won't change while it's using it.
There are potentially enormous optimisation benefits if you know that an object
is immutable (for a start, you never have to copy it), but even with lesser
declarative guarantees, in some circumstances you can infer actual
immutability, so both types of declarations are useful.
I'd like to see separate, clear:
- declarative separation of "value" and "container";
- implicit conversion between the two;
- promises BY functions that their parameters won't be changed when it
returns;
- promises TO functions that their parameters won't be changed while
they're working with them.
In a certain sense doing "values" is easy: simply make a class that has no
mutators, sets all its fields in its constructor, and where a field references
another object, require that that object too must likewise be a "value".
The hard bits include:
- getting the programmer to go to the trouble (making the writing of value
classes easier for the programmer than writing container classes);
- extracting and wrapping "values" from "container" classes, if the container
object isn't implemented simply as a singleton reference to a value object (and
there may be good efficiency reasons for this too: think "String" vs
"StringBuf" in Java).
-Martin
(*1: At least that one works; is you want to see something that doesn't know
whether it's a value or a container, have a look at the ugliness that is
java.util.date.)
(*2: While primatives still get passed by value. This is of course how Java
does it, and indeed pretty much every mainstream OO language created since
1990. Which explains a lot about what's wrong with Java, and software
engineering in general: design-by-contract has been reduced to
design-by-approximate-guideline-if-you-feel-like-it.)
(*3: Compact types not withstanding)
-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz
Manage Your Account, check your Vodafone Mail and send web2TXT online:
http://www.vodafone.co.nz/myvodafone
CAUTION: This correspondence is confidential and intended for the named
recipient(s) only.
If you are not the named recipient and receive this correspondence in error,
you must not copy,
distribute or take any action in reliance on it and you should delete it from
your system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those of
the author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
20 Viaduct Harbour Avenue, Private Bag 92161, Auckland 1030
Telephone + 64 9 355 2000
Facsimile + 64 9 355 2001
