On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 25, 2005 at 10:59:38 -0700, Ashley Winters wrote:
>
> > The Stringification of a UnixEpochTimestamp should probably be the
> > same as its Integerization -- 12345678900. However, the Interpolation
> > of it should be the locale-specific POSIX-style datetime string.
>
> Why? What value does the stringification of a date have as a
> stringified integer? If we were to implement such semantics,
> wouldn't it be wiser to print "The time in seconds since the epoch
> is { +$time }"? That's much more readable, obvious and
> nonsurprising, without being overly long or tedious.
It's not a Date, it's a UnixEpochTimestamp. I'm choosing my classes
for maximum expositive effect, and in this case a UnixEpochTimestamp
is explicitly defined as number-of-non-leap-seconds-since-1970. You
probably need to either .strftime(), .posix_localtime(),
posix_gmtime() or .as(Perl6::Time) to get a proper formatting.
> > Here's how I would do it if $Ashley == any(@Larry)
>
> You mean eqv.. =(
Ouch. You're right, but that's a painful adjustment.
> > The .as(Str) of an object would be its serialization
>
> as is formatting, not serialization:
>
> $time.as('%d');
>
> or something... I don't really know how this works
>
> For serialization you have the .perl method, which is roughly the
> same as Data::Dumper (code to be evaled), or some more heavy duty
> package (i expect Storable to have a pretty consistent interface).
Yes, .perl, .json, .xml, .repr, whatever.
>
> > my Thingy $foo .=from($thing);
>
> my Thingy $foo = eval($thing.perl);
This should really really really be discouraged and/or prevented. This
will be a Perl6 Worst Practice in short order. Please, consider:
my Thingy $foo = eval:data $thing.perl or eval:json $thing.json or
eval:xml $thig.xml
eval() itself feels like the wrong function for doing this. I'm trying
to parse(), not eval().
But, I digress...
> > The Interpolate role's method would return the pretty-printed,
> > possibly LOSSY presentation of the object's information.
>
> Uhuh, which is a flawed concept, because whose to decide what should
> be lost? why does the perl prelude have to decide what's valueable
> and what can be lost during *stringification or interpolation* now,
> when this language is supposed to live for another 20 years?
In Perl5, stringified NVs are only printed to however many digits Perl
thinks are worth printing. At the extreme range, it decides to print
with scientific notation. That is done for the convenience for
interpolation into an output string -- the real decimal representation
could be 0.00000000000000000000002378462387462341220983458672348961234
I'm not necessarily arguing this is the right or the best dividing
line, but I'm saying a line can be drawn if we want.
> > For example:
> >
> > my $color = new HTML::Color("magenta");
> > if $color.as(Str) eq '#FF00FF' and "$color" eq "magenta" {
> > $Ashley++;
> > }
>
> $color.hex_triplet; # no alpha
> $color.name; # if we have one... or we can try to make one up (#ff0033 is
> bluish red ;-)
>
> I see no reason why these two should behave in anyway, except that
> one of them is the canonical format. There is no mnemonic device
> whatsoever to link interpolation to color naming, and
> stringification to hexadecimal representation.
>
> Why isn't the str method "(255,0,255)"? Why isn't interpolation more
> expressive and "Dwimmy"?
I chose this class for expositive purposes as well. It's the canonical
representation of a color in HTML -- 6 digit hex. The DWIM factor
comes from printing what the object thinks its own value is. A
UnixEpochTimestamp thinks of itself as seconds-since-1970. An HTML
color thinks of itself as whatever you passed to its constructor,
whether that was #A4c or MaGeNtA or #ffffff
say "The Unix Epoch Timestamp is $time" --> The Unix Epoch Timestamp
is 1234567890
say "The HTML Color is $color" --> The HTML Color is magenta
> > So, to summarize, I want .as(Str) to be the lossless canonical
> > representation, as well as the basis for the default .hash method,
> > while Interpolate would be the pretty-printed localized lossy
> > presentation Role.
>
> For localization we need another thing. I propose a new prefix
> operator, with some funny char we haven't used yet. It would be a
> part of the Localizable role, and it would return a Str.
I'm not attached to the name or the function. I want something for
presentation that's different from representation that's different
from serialization and I want them to be easy and safe, and I want to
know which one will be used to hash my object by default. :)
Ashley Winters
