I had imagined the way things like
$R = 0 but true
would work is that the scalar would grow another couple of slots
in it, which would be the conversion operators. Everything defaults
to how it has worked in the past, but could be overridden. So the
boolean value starts as "default c
Larry Wall <[EMAIL PROTECTED]> writes:
> That's part of why I named it "btw" in the first place. The problem with
> "prop" is it's not quite obscure enough.
In the Netherlands, we have a value added tax named BTW. So it's not
unlikely for financial programs to implement a btw property or
method
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> I think it would be better if we stilled two curds with one bone. We
LW> can have a more obscure name, plus differentiate the prop tables at the
LW> same time. So how 'bout we have two methods, such as:
LW> $foo.variable_is
On Sat, May 19, 2001 at 11:26:36AM +1000, Damian Conway wrote:
> Not. The run-time property is set on the *value* in $Foo, not on the variable
> itself. Change the value, change the properties.
Ok, that makes me happy. :)
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~sch
[EMAIL PROTECTED] writes:
: Graham wrote:
:
:> On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote:
:> > > print keys $foo.prop; # prints "NumberHeard"
:> > > print values $foo.prop; # prints "loneliestever"
:>
:> This is an example of one of my co
On Sat, May 19, 2001 at 06:41:29PM +1000, Damian Conway wrote:
>
> Graham wrote:
>
>> On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote:
>> > > print keys $foo.prop; # prints "NumberHeard"
>> > > print values $foo.prop; # prints "loneliestever"
>>
>
Graham wrote:
> On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote:
> > > print keys $foo.prop; # prints "NumberHeard"
> > > print values $foo.prop; # prints "loneliestever"
>
> This is an example of one of my concerns about namespace overlap
> wit
Piers wrote:
> > >> Can 'undef' valued thingys have properties
> > >
> > > Yes.
> > >
> > >> and functions?
> > >
> > > No.
> > >
> >
> > Why not?
>
> You can always set a property on a function reference. But it seems a
> little weird that
On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote:
> > print keys $foo.prop; # prints "NumberHeard"
> > print values $foo.prop; # prints "loneliestever"
This is an example of one of my concerns about namespace overlap
with methods. What would happen if there was a me
Graham Barr <[EMAIL PROTECTED]> writes:
> On Fri, May 18, 2001 at 08:31:21AM -0500, Jarkko Hietaniemi wrote:
> > On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
> > >
> > > --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > >
> > > > It's probably just a matter of coding what yo
Graham Barr <[EMAIL PROTECTED]> writes:
> On Fri, May 18, 2001 at 03:01:38PM +1000, Damian Conway wrote:
> >> Also, what's the difference between a 'property' and an
> >> 'attribute', ie, are:
> >>
> >>$fh is true;
> >>
> >> and
> >>
> >>$fh.true(1);
>
Richard Proctor <[EMAIL PROTECTED]> writes:
> On Fri 18 May, Damian Conway wrote:
> >
> > Ed wrote:
> >
> >
> >> Can 'undef' valued thingys have properties
> >
> > Yes.
> >
> >> and functions?
> >
> > No.
> >
>
> Why not?
You can always set a property on a function referenc
On 5/18/01 9:23 PM, Damian Conway wrote:
> print %{(+$fh).prop};# All the value's properties
...and my question is: why is the %{...} there? Doesn't .prop return a
hash? Looks like it here:
> print keys $foo.prop; # prints "NumberHeard"
> print values $foo.prop; # prints
Ed asked:
> > print %{(+$fh).prop};# All the value's properties
> >
>
> um.. I'm not the greatest fan of this syntax.. what's the '+' for?
As I explained at the end of the "re: properties" message, it's to evaluate
$fh, so we get the hash of properties belonging the value in
>> So... why the *$#$ is it getting into the loop?
>>
>> There has to be a method to print out the *contents* of $fh, not
>> just the values.
>
> print $fh.true; # Just the truth
>
> print %{(+$fh).prop}; # All the value's properties
>
um.. I'm not the greatest f
Schwern wrote:
> Let me see if I understand this...
>
> $Foo is true;
>
> # Meanwhile, in another part of the city...
>
> $Foo = 0;
> print "My spider sense is tingling" if $Foo;
>
> Does that print or not?
Not. The run-time property is set on the *value* i
Ed said:
> No, because you can say:
>print "$fh";
> and find out exactly what is going on.
>
> In the case with
> undef $fh;
> $fh is true.
>
> if ($fh) { print "HERE!!!\n"; }
>
> print "$fh";
>
> you get nada, right?
Right.
> So... why t
Jarkko Hietaniemi writes:
: Maybe I missed it... but what is the relationship of (Perl 5) attributes
: and Perl 6 properties?
:
: my $answer : constant = 42;
: my $answer is constant = 42;
:
: my sub ... dang, no lexical subs, but can we please have them
: in Perl6? :-)
Bart wrote:
> >While I understand how "0 but true" is a cute hack that is destined to
> >be replaced by a truth property, I fail to realize how it's useful to
> >have a value that's true no matter what value you assign to it later.
>
> I thought the "truth" property was attached t
On Fri, 18 May 2001 23:26:53 +0200, Trond Michelsen wrote:
>While I understand how "0 but true" is a cute hack that is destined to
>be replaced by a truth property, I fail to realize how it's useful to
>have a value that's true no matter what value you assign to it later.
I thought the "truth" p
Maybe I missed it... but what is the relationship of (Perl 5) attributes
and Perl 6 properties?
my $answer : constant = 42;
my $answer is constant = 42;
my sub ... dang, no lexical subs, but can we please have them
in Perl6? :-)
sub terfuge : loc
I've seen uses for compile-time properties on variables, and run-time
properties on values, but I've not yet seen any decent use for run-time
properties on variables. So I'd be inclined to disallow properties on
lvalues unless they're in a "my" or "our".
Offhand, I do kinda like the notion of di
On Fri, May 18, 2001 at 01:34:55PM -0700, Nathan Wiger wrote:
> Dammit, I got the example exactly backwards. Try this:
>>$Foo is true;
>>$Foo = 0;
>>print "Stuff" if $Foo; # *WOULD* print - "is" assigns a
>> # permanent "true" property
Sorry to ju
At 01:34 PM 05-18-2001 -0700, Nathan Wiger wrote:
>Dammit, I got the example exactly backwards. Try this:
>
> >$Foo is true;
> >$Foo = 0;
> >print "Stuff" if $Foo; # *WOULD* print - "is" assigns a
> > # permanent "true" property
> >
> >$Foo as
On Fri, 18 May 2001, Nathan Wiger wrote:
> Maybe there are two different features being conflated here. First, we
> have "is", which is really for assigning permanent properties:
>my $PI is constant = '3.1415927';
> So, those make sense, and we'd want them to remain through assignment.
>
Dammit, I got the example exactly backwards. Try this:
>$Foo is true;
>$Foo = 0;
>print "Stuff" if $Foo; # *WOULD* print - "is" assigns a
> # permanent "true" property
>
>$Foo as true = "";
>$Foo = 0;
>print "Stuff" if $Foo; # *
* Michael G Schwern <[EMAIL PROTECTED]> [05/18/2001 12:32]:
> Let me see if I understand this...
>
> $Foo is true;
>
> # Meanwhile, in another part of the city...
>
> $Foo = 0;
> print "My spider sense is tingling" if $Foo;
>
> Does that print or not?
Maybe there are two different fea
Let me see if I understand this...
$Foo is true;
# Meanwhile, in another part of the city...
$Foo = 0;
print "My spider sense is tingling" if $Foo;
Does that print or not?
I can see the need for wanting to disassociate truth from value (I've
wanted it myself) but if $Foo remains true
> I don't see that at all. We're simply providing one more
> way for a value to be true, and one more way for it to be false.
> You might as well argue that the following is "action-at-a-distance":
>
> undef $fh;
>
> $fh = "0 but true";
>
> ... 1200 lines later...
>
>
[EMAIL PROTECTED] writes:
:> Also, what's the difference between a 'property' and an
:> 'attribute', ie, are:
:>
:>$fh is true;
:>
:> and
:>
:>$fh.true(1);
:>
:> synonyms?
:
: No. The former means:
:
: "Set the true property to 1 and r
On Fri, May 18, 2001 at 08:31:21AM -0500, Jarkko Hietaniemi wrote:
> On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
> >
> > --- Damian Conway <[EMAIL PROTECTED]> wrote:
> >
> > > It's probably just a matter of coding what you actually mean.
> > > In Perl 5 and 6 your version
On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
>
> --- Damian Conway <[EMAIL PROTECTED]> wrote:
>
> > It's probably just a matter of coding what you actually mean.
> > In Perl 5 and 6 your version means "if $fh is true in *any*
> > possible way...", whereas you seem to want
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> It's probably just a matter of coding what you actually mean.
> In Perl 5 and 6 your version means "if $fh is true in *any*
> possible way...", whereas you seem to want "if $fh is defined",
> which is:
Hmm. I can easily see this producing incomp
On Fri, May 18, 2001 at 03:01:38PM +1000, Damian Conway wrote:
>> Also, what's the difference between a 'property' and an
>> 'attribute', ie, are:
>>
>>$fh is true;
>>
>> and
>>
>>$fh.true(1);
>>
>> synonyms?
>
> No. The former means:
>
>
On Fri 18 May, Damian Conway wrote:
>
> Ed wrote:
>
>
>> Can 'undef' valued thingys have properties
>
> Yes.
>
>> and functions?
>
> No.
>
Why not?
Richard
--
[EMAIL PROTECTED]
Ed wrote:
> Any ideas on how to handle this with the 'is' keyword? I was
> reading the slashdot comments to Exegesis II, and this seemed to be
> the one issue that had merit. A couple of the posters bemoaned the
> fact that they were debugging PL/I about 25 years ago, and had code
36 matches
Mail list logo
