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