--------------enigD8FB0013240361C4D9D26B81
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
David Vallner wrote:
=20
<snip>
=20
Point taken. I can't imagine wanting to do 'logan' + 115 and have it be= =20
'logans' (as opposed to just doing 'logan' + 's'), but I'm sure there=20
are applications for adding ASCII values.
=20
That's a convention / burp of Ruby. Indexing a string with an integer
instead of a Range returns the ASCII code of the character at that
position. Adding an integer to a string does cause an exception to be
thrown. However,
irb(main):001:0> foo =3D 'quux'
=3D> "quux"
irb(main):002:0> foo[-1] =3D 115
=3D> 115
irb(main):003:0> foo
=3D> "quus"
irb(main):004:0> foo[-1] =3D 'bar'
=3D> "bar"
irb(main):005:0> foo
=3D> "quubar"
That means the behaviour is reflexive and at least somewhat consistent,
a minor redeeming quality.
As far as I know, in Ruby 1.9, and 2.0, indexing a String will return a
one-character string instead of making that a special case, so the need
for this type conversion will disappear.
(Technically, an int -> char conversion isn't a change of data. However,
since Ruby doesn't have the char data type, the above behaviour is
contextual overloading of the integer datatype - a special case when an
integer isn't treated as a character, and that is, at least for me,
confusing.)
=20
Hmm, what's the difference? IIRC, PHP's docs referred to (int)$stringva= r=20
as casting, which seems the same as to_s, to_i, etc.
=20
Casting is usually an explicit conversion, coercion an implicit one. PHP
documents are correct on that, except PHP performs a much larger set of
type conversions that way than most other languages where type casting
appears (C, Java; C++ and C# let you overload type conversion, but don't
do type conversion between wildly heterogenous types out of the box).
Noted explicitly, it's not really a problem, since you don't have to pay
attention to the context to see whether the type conversion does or does
not happen.
Coercion is an implicit conversion that the language runtime does for
you. The problem with it is that it's not readily visible when it
happens, and tends to contribute to language "gotchas" - unobvious rules
you have to keep in your head when reading code. Ruby has a one of those
with String#match() - if the argument to the method is a String, it gets
coerced to a Regexp. Of course, I had to fire up irb to find out if the
method receiver or the argument is the coerced object.
Extensive "magical" behaviour of a programming language in the long term
leads to people ending up with more of the language in their head
especially when not dealing with write-only code to maintain it, and
keeps information needed to read the code out of sight. It isn't harmful
in some cases - for example for String#format, the printf-specifiers
already indicate that a certain argument will be interpreted for example
as an integer, and it's redundant to have to restate this. It's not good
when the coercion would be ambiguous though, and actively harmful
(PHPism) when conversion doesn't ever fail cleanly - like a string that
doesn't contain a single number that coerces into 0.
David Vallner
--------------enigD8FB0013240361C4D9D26B81
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
iD8DBQFFHyj8y6MhrS8astoRAuJPAJ4u3JOLzb5xORhACgmNNxFcjxDqvwCfYSAr
CWlE1Z1IxY5Q4RjAg8JdQds=
=zwnu
-----END PGP SIGNATURE-----
--------------enigD8FB0013240361C4D9D26B81--