>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).

The above paragraph doesn't make any sense unless you swap "to" and
"from" in the first sentence.

>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 don't see how your suggested change for the cast() operator to
falling back to _sprintf would help anything in your example case.
  • 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