I agree, when discussing type casts. Value casts, as I am focused on,
is a rather different story. The field is sort of mudded up in pike,
as the workings of the type system isn't all that obvious to the naked
eye.

If we instead discuss it in terms of data representation conversion,
or data type conversion, rather than type casting, we significantly
disambiguate and unmuddle things.

In Pike, data type conversion is typically handled completely by
whatever type of object is being converted to, with no help from the
object being converted from. This is done in create(), and to convert
an array of integers treated as time_t seconds-since-the-Epoch, into
Calendar.Second objects, for instance, we can't employ any help from
the pike's cast LFUNs -- (array(Calendar.Second))integers -- but have
to resort to map( integers, Calendar.Second ), or the (very brittle)
automap syntax Calendar.Second( integers[*] ), which I personally
avoid even in those very basic cases where it actually works (like
this).

I do data type conversion a lot, especially near database operations
persisting or reading back objects from storage. Having largely been
away from pike hackery for a while, found the lack of language support
for it, if not surprising (I'm not new to pike), then at least not a
pleasant feature hole to rediscover.

I do consider pike's array value casting a very elegant and readable
higher order operation. It's just painfully limited in scope. A lot
like automap, actually. :-)
  • Default cas... Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum
    • Defaul... Peter Bortas @ Pike developers forum
      • De... Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum
    • Defaul... Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum
      • De... Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum
    • Re: De... Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum
      • Re... Martin Bähr
      • Re... Peter Bortas @ Pike developers forum
        • ... Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum
          • ... Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum
            • ... Johan Sundstr�m (Achtung Liebe!) @ Pike (-) developers forum

Reply via email to