On Fri, Nov 22, 2002 at 12:10:11PM -0800, Michael Lazzaro wrote:
> On Friday, November 22, 2002, at 10:59 AM, Luke Palmer wrote:
> >> From: Michael Lazzaro <[EMAIL PROTECTED]>
> I've been under the impression that the following would _not_ work:
>
> $s ~~ //;
> print "I found $number";
On Friday, November 22, 2002, at 10:59 AM, Luke Palmer wrote:
From: Michael Lazzaro <[EMAIL PROTECTED]>
(This is a bit off-topic, but it's a tiny bit sad that you can name
subrules, but you can't refer to them by name in the interpolation
unless you use hypothetical vars. Eh, no biggie: it would
> Date: Fri, 22 Nov 2002 10:49:08 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
>
> Or, using hypothetical vars:
>
> $s ~~ s/ $num := /$num.as(MoneyFormat)/;
>
> (This is a bit off-topic, but it's a tiny bit sad that you can name
> subrules, but you can't refer to them by name in the i
On Thursday, November 21, 2002, at 11:22 AM, Tanton Gibbs wrote:
It would be very useful in the second half of a s///, too (grab a
match, rewrite it in a canonical form):
$s ~~ s///;
once again, I think it could just be
$s ~~ s//$1.as(MoneyFormat)/
Or, using hypothetical vars:
On Wed, Nov 20, 2002 at 05:51:17PM -0500, Tanton Gibbs wrote:
> It's going to be hard to beat sprintf( "%x", $i ) for clarity or
> conciseness.
my $s = "%x" % $i; # python wins for conciseness :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Larry Wall <[EMAIL PROTECTED]> writes:
> On Thu, Nov 21, 2002 at 01:29:32AM -0500, Tanton Gibbs wrote:
> : Properties have bothered me, but for a different reason. It appears that
> : everyone's answer to everything is "make it a property!"
>
> Yes, properties should generally be a last resort, n
On Thu, Nov 21, 2002 at 09:10:53AM -0800, Larry Wall wrote:
> On Wed, Nov 20, 2002 at 10:16:54PM -0800, Dave Storrs wrote:
> : As a tangent...one of the things that has bothered me about "but" and
> : "is" for properties since the beginning is that they make for
> : excessively long code. Does th
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote :
>
> 1) "Formats" as classes. What I _want_ to do is to be able to
> associate a named "format" with a given class/instance/output, because
> I tend to use the same few formats over and over. So if I want to
> frequently output numbers as '%-4.2d', I j
> 1) "Formats" as classes. What I _want_ to do is to be able to
> associate a named "format" with a given class/instance/output, because
> I tend to use the same few formats over and over. So if I want to
> frequently output numbers as '%-4.2d', I just call it "MoneyFormat" or
> something:
>
>
On Thursday, November 21, 2002, at 12:16 AM, Dave Storrs wrote:
I do agree that having it be a method (and hence overloadable) is the
best solution. I just wish there were some way to get away from those
dratted sprintf format strings.
Amen. God, I've hated those things for years. And yet m
> If I'm understanding them correctly, another way to think of runtime
> properties is "dynamic inheritance", or more specifically
> "instance-based inheritance". When you say:
>
> $v but foo(5);
>
> You're saying that instance/value $v now inherits the behaviors of
> foo(5), in addition to it
On Thursday, November 21, 2002, at 12:24 AM, Dave Storrs wrote:
On Thu, Nov 21, 2002 at 01:29:32AM -0500, Tanton Gibbs wrote:
Properties have bothered me, but for a different reason. It appears
that everyone's answer to everything is "make it a property!"
Properties are just strange to compre
On Thu, Nov 21, 2002 at 01:29:32AM -0500, Tanton Gibbs wrote:
: Properties have bothered me, but for a different reason. It appears that
: everyone's answer to everything is "make it a property!"
Yes, properties should generally be a last resort, not a first resort.
: Properties are just strange
On Wed, Nov 20, 2002 at 10:16:54PM -0800, Dave Storrs wrote:
: # Could you really tell what this does at a glance?
: my $s = ~hex:w4p2d0rs $i;
:
: my $s = ~hex $i but width 4
: but precision 2
: but padded 0
:
On Thu, Nov 21, 2002 at 03:26:09AM -0500, Tanton Gibbs wrote:
> Dave Storrs wrote
> > best solution. I just wish there were some way to get away from those
> > dratted sprintf format strings.
>
> Well, for the general case, you could create convienence functions that
> handle getting the correct
> > > my str $s = sprintf("%x", $i);# 30 characters
> > > my str $s = hex $i; # 19 characters
> > > my $s = ~hex $i; # 16 characters
> >
> > I think these are good, but I really think that Larry's idea of an "as"
> > function is the best. Not only does it provide
On Thu, Nov 21, 2002 at 01:29:32AM -0500, Tanton Gibbs wrote:
>
> > As a tangent...one of the things that has bothered me about "but" and
> > "is" for properties since the beginning is that they make for
> > excessively long code. Does this bother anyone else?
> >
> > --Dks
>
> Properties have b
On Thu, Nov 21, 2002 at 01:22:50AM -0500, Tanton Gibbs wrote:
> > I actually rather like MikeL's suggestion for the unary ops; clear,
> > concise, and highly readable. And look:
> >
> > my str $s = sprintf("%x", $i);# 30 characters
> > my str $s = hex $i; # 19 characters
> > my $
> As a tangent...one of the things that has bothered me about "but" and
> "is" for properties since the beginning is that they make for
> excessively long code. Does this bother anyone else?
>
> --Dks
Properties have bothered me, but for a different reason. It appears that
everyone's answer to
> I actually rather like MikeL's suggestion for the unary ops; clear,
> concise, and highly readable. And look:
>
> my str $s = sprintf("%x", $i);# 30 characters
> my str $s = hex $i; # 19 characters
> my $s = ~hex $i; # 16 characters
I think these are good, but
On Wed, Nov 20, 2002 at 05:51:17PM -0500, Tanton Gibbs wrote:
>
> It's going to be hard to beat sprintf( "%x", $i ) for clarity or
> conciseness.
Unfortunately, it's pretty easy to beat it for readability. It's also
a holdover from C, an ancestor language that we are (at least to a
degree) tryi
Larry wrote:
> "\$i is $i.format('%04x')"
> "\$i is $i.form('%04x')"
> "\$i is $i.frm('%04x')"
> "\$i is $i.as('%04x')"
> "\$i is $i.f('%04x')"
If we keep it a method, then we do have the added benefit of being able to
override it for custom classes...something that sprintf doe
On Wed, Nov 20, 2002 at 02:46:22PM -0800, Michael Lazzaro wrote:
: On Wednesday, November 20, 2002, at 01:45 PM, Tanton Gibbs wrote:
: string interpolation? (where we need it most!)
I agree. But it's already there. We can interpolate method calls.
: "\$i is $(sprintf('%04x',$i))"
Assu
> I'd certainly like a way to easily (1) treat a string as bin/oct/hex,
> and (2) stringify a number to bin/oct/hex, because those are two pretty
> common cases. I've tried tons of things to get a more general syntax,
> and nothing is really working. The string interpolation case is the
> most in
On Wednesday, November 20, 2002, at 01:45 PM, Tanton Gibbs wrote:
my int $i is formatted('%4x');
$i = 255;
print $i;# prints '00ff';
I too don't see much use in the former. The latter puts distance
between the formatting and the thing being formatted and that can't
be good.
> > my int $i is formatted('%4x');
> > $i = 255;
> > print $i;# prints '00ff';
> >
> > Anyone care to comment?
>
> I too don't see much use in the former. The latter puts distance between
> the formatting and the thing being formatted and that can't be good.
In situations such a
On Tue, Nov 19, 2002 at 10:59:02AM -0800, Michael Lazzaro wrote:
> (A) Unification of Literal <--> Stringified Numeric Behaviors
>
> An old proposal that I can't find anymore suggested that strings should
> be converted to a number according to the exact same rules as literals,
> such that:
>
>
On Wed, Nov 20, 2002 at 10:05:38AM -0800, Michael Lazzaro wrote:
: On Tuesday, November 19, 2002, at 06:34 PM, Larry Wall wrote:
: >On Tue, Nov 19, 2002 at 10:59:02AM -0800, Michael Lazzaro wrote:
: >: (A) Unification of Literal <--> Stringified Numeric Behaviors
: >:
: >: 0123 == "0123"
: >
On Tuesday, November 19, 2002, at 06:34 PM, Larry Wall wrote:
On Tue, Nov 19, 2002 at 10:59:02AM -0800, Michael Lazzaro wrote:
: (A) Unification of Literal <--> Stringified Numeric Behaviors
:
: 0123 == "0123"
: 0xff == "0xff"
: 20#1gj == "20#1gj"
: 1e10 == "1e10"
:
: i
On Tue, Nov 19, 2002 at 10:59:02AM -0800, Michael Lazzaro wrote:
: OK, back to this, so we can finish it up: we have a number of proposals
: & questions re: string-to-num conversions, and from Luke we have some
: initial docs for them that need completing. Can I get more feedback on
: these iss
Michael Lazzaro said:
> (A) Unification of Literal <--> Stringified Numeric Behaviors
>
> An old proposal that I can't find anymore suggested that strings should
> be converted to a number according to the exact same rules as literals,
> such that:
>
> 0123 == "0123"
> 0xff == "0xff
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> OK, back to this, so we can finish it up: we have a number of proposals
> & questions re: string-to-num conversions, and from Luke we have some
> initial docs for them that need completing. Can I get more feedback on
> these issues, plz, and any other
>
> (E) We need to finalize what happens when a string isn't a number,
> or has additional trailing stuff. Damian gave his initial
> preference, but we need to verify & set in stone:
>
> my int $i = 'foo'; # 0, NaN, undef, or exception?
> my int $i = '5foo'; # 5, NaN, undef, or exce
33 matches
Mail list logo
