Mark A. Biggar skribis 2005-09-25 19:42 (-0700):
> In a private conversation with Larry this afternoon, he said that by
> default "$foo" and ~$foo and $foo.as(Str) all give the same result
> (assuming scalar context, etc.). And that "@foo[]" and [EMAIL PROTECTED] and
> @foo.as(Str) are the same
In a private conversation with Larry this afternoon, he said that by
default "$foo" and ~$foo and $foo.as(Str) all give the same result
(assuming scalar context, etc.). And that "@foo[]" and [EMAIL PROTECTED] and
@foo.as(Str) are the same as join(' ', @foo) where join is effectively:
sub join
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 cont
* wolverian ([EMAIL PROTECTED]) [050925 11:57]:
> On Sun, Sep 25, 2005 at 12:52:08PM +0200, Juerd wrote:
> > Hackers on this list, what do you think?
>
> I think separating the two is extremely confusing. I do not see any uses
> for it, but maybe I am not thinking hard enough.
Of course, having
Ashley Winters skribis 2005-09-25 12:26 (-0700):
> It's not a Date, it's a UnixEpochTimestamp.
That is precisely the flaw. Are you honestly likely to have that class?
If you really need an unix epoch timestamp, wouldn't you just use a very
simple integer for that? Because that's what it *is*, b
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-speci
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 st
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 25, 2005 at 12:52:08 +0200, Juerd wrote:
> > Damian Conway skribis 2005-09-24 8:31 (+1000):
> > > >In my opinion, making the string value in interpolation different from
> > > >the value in Str context is madness.
> > > It's dwimmer
On Sun, Sep 25, 2005 at 12:52:08 +0200, Juerd wrote:
> Damian Conway skribis 2005-09-24 8:31 (+1000):
> > >In my opinion, making the string value in interpolation different from
> > >the value in Str context is madness.
> > It's dwimmery.
>
> It's dwymmery, or dwdmmery indeed. Not at all what I m
On Sun, Sep 25, 2005 at 12:52:08PM +0200, Juerd wrote:
> Hackers on this list, what do you think?
I think separating the two is extremely confusing. I do not see any uses
for it, but maybe I am not thinking hard enough.
--
wolverian
signature.asc
Description: Digital signature
Damian Conway skribis 2005-09-24 8:31 (+1000):
> They ought to, since the two are different in Perl 5.
> For example:
> my @bar = 'bar';
> print "[EMAIL PROTECTED]";
> print "foo[" . @bar . "]baz\n";
This does not compare stringification to interpolation. It compares
scalarification t
Damian Conway skribis 2005-09-24 8:31 (+1000):
> >In my opinion, making the string value in interpolation different from
> >the value in Str context is madness.
> It's dwimmery.
It's dwymmery, or dwdmmery indeed. Not at all what I mean, am likely to
mean, or will ever mean.
> Which often looks l
Juerd wrote:
But will they also see "foo" ~ $bar as something different from
"foo$bar"?
They ought to, since the two are different in Perl 5.
For example:
my @bar = 'bar';
print "[EMAIL PROTECTED]";
print "foo[" . @bar . "]baz\n";
And what context does "foo{ $bar }" use?
Strin
TSa skribis 2005-09-23 19:11 (+0200):
> >> We have: "foo" ~ $bar
> >> I see: a juxtaposition of two operators and an item,
> >>all three separated by whitespace
> >I can only hope you mean two items and one operator.
> So, at last there is hope somewhere. But I fear I'm hopelessly
> drowne
Halo,
someone has switched off my echo ;)
Juerd wrote:
TSa skribis 2005-09-23 15:42 (+0200):
1) the circumfix operator " " has an arity >= 1
I think it's parsed, not having specific arity.
Of course it's parsed, how else should it reach the semantic analyzer?
And I don't consider (arity
On 2005-09-23 06:08, "Juerd" <[EMAIL PROTECTED]> wrote:
> In my opinion, making the string value in interpolation different from
> the value in Str context is madness.
Hear, hear! I agree 100%. This is another place where we should move the
Rubyometer down rather than up, I think (to_s vs. to_st
TSa skribis 2005-09-23 15:42 (+0200):
> 1) the circumfix operator " " has an arity >= 1
I think it's parsed, not having specific arity.
> We have: "foo" ~ $bar
> I see: a juxtaposition of two operators and an item,
> all three separated by whitespace
I can only hope you mean two
HaloO Juerd,
you wrote:
Damian Conway skribis 2005-09-22 23:04 (+1000):
I disagree. I think it's likely that people will think of ~$val and +$val
the same way (i.e. as "coerce the value"), but that they will think of
"$val" quite differently (i.e. as "interpolate a useful string
representati
On Thu, Sep 22, 2005 at 11:59:32AM -0400, Matt Fowles wrote:
> Well said! I completely agree that string interpolation should be
> handled exactly the same as stringification. I would like C< ("foo is
> $foo of course") eq ("foo is " ~ $foo ~ " of course") > at all times.
Yes.
S03 states:
Un
Damian Conway skribis 2005-09-22 23:04 (+1000):
> I disagree. I think it's likely that people will think of ~$val and +$val
> the same way (i.e. as "coerce the value"), but that they will think of
> "$val" quite differently (i.e. as "interpolate a useful string
> representation of the entire val
Juerd wrote:
I think separating stringification and interpolation leads to
unpredictability, and is a very bad thing.
I disagree. I think it's likely that people will think of ~$val and +$val the
same way (i.e. as "coerce the value"), but that they will think of "$val"
quite differently (i.e
Yuval~
On 9/22/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 22, 2005 at 08:20:42 +1000, Damian Conway wrote:
> > Ingo Blechschmidt asked:
> >
> > >my $pair = (a => 42);
> > >say ~$pair; # "a\t42"? "a\t42\n"? "a 42"?
> >
> > Not yet specified but I believe it should be "42" (i
On Thu, Sep 22, 2005 at 08:20:42 +1000, Damian Conway wrote:
> Ingo Blechschmidt asked:
>
> >my $pair = (a => 42);
> >say ~$pair; # "a\t42"? "a\t42\n"? "a 42"?
>
> Not yet specified but I believe it should be "42" (i.e. stringifies to value).
>
> Note that S02 does specify that pairs *i
Damian Conway skribis 2005-09-22 8:20 (+1000):
> Note that S02 does specify that pairs *interpolate* to
> key-tab-val-newline, so you can still get "a\t42\n" by writing "$pair"
> instead.
I think separating stringification and interpolation leads to
unpredictability, and is a very bad thing.
Ju
Ingo Blechschmidt asked:
my $pair = (a => 42);
say ~$pair; # "a\t42"? "a\t42\n"? "a 42"?
Not yet specified but I believe it should be "42" (i.e. stringifies to value).
Note that S02 does specify that pairs *interpolate* to key-tab-val-newline,
so you can still get "a\t42\n" by writin
Eric wrote:
Since you wouldn't expect an object to stringify or numify...
You wouldn't??! I certainly would.
Object references already stringify/numerify/boolify in Perl 5. Unfortunately,
they do so with problematic default behaviours, which is why C
allows you to overload q{""}, q{0+} and
Stuart Cook skribis 2005-09-22 10:39 (+1000):
> If there's no (single) obvious interpretation of "turn a value into a
> number" for a particular type, then don't struggle to come up with a
> non-obvious one--I say just leave it undefined, or have it fail(), or
> whatever.
Leaving it undefined is w
Mark A. Biggar skribis 2005-09-21 17:44 (-0700):
> Now for a related question: is it intended that ~$x and +$n be the same
> as $x.as(Str) and $x.as(Num)? How locked in stone would this be, I.e.,
> ~ and + are macros that give the .as() form?
If I read everything correctly, this is the case.
Eric wrote:
Hey,
Since you wouldn't expect an object to stringify or numify why expect pairs
to? I'm not sure i see any value in thatm, $pair.perl.say would be the best
way to output one anyway.
my $pair1 = (a => 2);
my $pari2 = (b => 3);
say $pair1 + $par2; # Error: illegal stringification of
On 22/09/05, Juerd <[EMAIL PROTECTED]> wrote:
> I don't think +(~$pair) makes any sense, though. It's basically the same
> as +(~$pair.key). It's probably wise to avoid that $pair can be confused
> for its key or value. A good alternative is hard to find, though. I tend
> to prefer 1 at this moment
On 22/09/05, Juerd <[EMAIL PROTECTED]> wrote:
> By the way, is it really this simple?
>
> class HTTP::Header is Pair {
> foo {
> "{.key}: {.value ~~ s/\n/\n /g}"
> }
> }
>
> Where "foo" is whatever is needed to override stringification.
Something along the lines
Eric skribis 2005-09-21 16:46 (-0600):
> Since you wouldn't expect an object to stringify or numify [...]
Oh? I would in fact expect many objects to stringify or numify to useful
values. Just like I expect an array reference to stringify as if it was
an array, I expect an HTTP header object to str
Hey,
Since you wouldn't expect an object to stringify or numify why expect pairs
to? I'm not sure i see any value in thatm, $pair.perl.say would be the best
way to output one anyway.
my $pair1 = (a => 2);
my $pari2 = (b => 3);
say $pair1 + $par2; # Error: illegal stringification of pair.?
I kno
Ingo Blechschmidt skribis 2005-09-21 14:47 (+):
> my $pair = (a => 42);
> say ~$pair; # "a\t42"? "a\t42\n"? "a 42"?
> say +$pair; # 0 (pairs aren't numbers)?
> # 42?
> # 0 ("a" is not a number)?
> # 0 (~$pair can't be used as a nu
34 matches
Mail list logo
