Mark Overmeer skribis 2005-09-25 17:28 (+0200):
> Stringification/Numification should be used to let an object play its
> natural role within the program.
Agreed, but...
> For instance, some "Temperature" object producing 273 when compared to
> the melting point of water.
That's for numeric context, in which it will do this. It doesn't say
much (or anything) about strings.
For a temperature, it happens to make sense to use the number for
stringification as well, because we humans are used to numbers for
temperatures.
I think more abstract types are more interesting, when it comes to how
they behave as strings and in string literals (which I think should be
exactly the same).
I think that indeed arrays, hashes and pairs are great objects of this
discussion. Pairs in much lesser extent, because what they should do in
any scalar context is still under discussion: evaluate to the .value,
propagating context, or evaluate to something that has to do with the
pair itself. For the record, I prefer the latter, for several reasons.
Arrays and hashes as numbers evaluate to their number of elements. This
is terribly useful. Arrays and hashes as further unspecified scalars
evaluate to references to themselves. This too is very useful indeed,
especially because we also have automatic dereferencing nowadays.
In string context, an array evaluates to its stringified elements joined
by whitespace. This is possibly lossy, because the elements may contain
spaces as well. It doesn't make sense to me to make it behave any
differently in string context than in interpolation. Or, as I really do
prefer to put it: to have items in non-string context when they're
interpolated. A part of a string is a string, and we shouldn't
differentiate between it being part of a string that was built in
pieces and it being part of a string that was built as a whole, a string
literal.
> Interpolation should be used on places where output is generated, where
> the outside consumer has less knowledge about the internals. Like "273'C"
> for the same Temperature object. Sorry, my program uses Celcius ;-)
Sure, including the unit does make sense. Still, how you built the
complete string for the end user shouldn't determine how the object is
stringified.
Whether I use
say "t=" ~ $temperature;
or
say "t=", $temperature;
or
say "t=$temperature";
it is all presentation to the human. I don't want to be told that for
telling things to humans, I must use interpolation. Mostly, because most
of the time I don't (I pass the value to a templating thing (and I don't
want to have to care about HOW that uses the value later on), and often
I use printf).
> I like to have this behavior.
You're not commenting on the difference between using it as a string and
using it as an interpolated value, though. Your example compares numeric
use to string use, and indeed those should be different.
This thread is about strings only, and would your temperature ever make
sense as both one form of string and another? In other words, what would
say $temp;
print, and what would
say "$temp";
print instead? And to conclude it, what would you want
say get_temperature();
to print? Are you willing to have this big difference between this and
say "{ get_temperature() }";
(Still assuming we won't have "auto freezing" and "auto thawing" in much
the same way we will have "auto referencing" and "auto dereferencing",
because I'd like those operations to be very clear and explicit.)
> The more constructs (like pairs, junctions, and hashes) produce
> different results for both cases, the better the choice for
> distinction is, because people get aware of it without reading a book.
Yes, if things are different, they should be really different.
For this reason I want ~$foo and +$foo be different where something
making sense can be thought of and implemented without much effort, and
pairs to evaluate to something OTHER than their values (they're not
aliases, and this is most evident with \$pair, which shouldn't be in any
way like \$pair.value, and in "$pair", which shouldn't be in any way
different from ~$pair.)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
