On Thu, Aug 09, 2001 at 03:37:42AM +1000, Damian Conway wrote:
> Scott wrote:
>> What happens to C within stand-alone C statements? Do
>> C statements never stand alone?
>
> That's correct. I'd expect:
>
> die "Ungoverned 'when' statement (where's the 'given'???)"
That's weird.
> My personal preference would be for all such properties (traits?) to be
> reserved across all types - eg using 'prompt' on a hash gives a
> compile/run time error. This allows the compiler to catch certain types
> of typo and thinko, and also allows us to expand in future - eg when
Scott wrote:
> Hmm. C seems to be synonymous with C (almost)
>
>when ($foo) { ... } # Does this mean if ($_ eq $foo)?
> if ($foo) { ... }
A C is an whose "other half" is specified by a surrounding C.
> However ...
>
> > A C within a C's block causes
On Wed, Aug 08, 2001 at 08:25:57AM +1000, Damian Conway wrote:
>> More questions regarding the new 'given when' construct.
>> [ LABEL: ] given ( expr_1 ) {
>>[ when expr_2 : block ...]
>>expr_n [;]
>> }
>
> Not required. It's:
>
> [
Damian Conway <[EMAIL PROTECTED]> wrote:
>> There are a number of properties "built into" Perl 6. Nearly all of these
>> properties don't make sense across the board - eg, a scalar won't have a
>> dimension, a hash won't prompt, etc.
>>
>> So given the two different sets that y
> # >my $foo is const = 0 is true;
> # >
> # > $foo has the property const, while the value 0 in $foo has
> # > the property true.
> #
> # So, if I do
> #
> # my $foo is constant = new Counter(0);
> # $foo->increment # OK
>
> I think so.
Yep. Except the prop
Dan suggested:
> The syntax for variable and value properties are going to be different, I
> think, I just can't remember what it's going to be. (I think the colon's
> involved, but isn't it always?)
I think you're now channelling my de specula, not Larry's de jure. :-)
In A2, Larry
> More questions regarding the new 'given when' construct.
More answers (modulo Larry :-)
> 1) Is a 'when' clause required? Is it:
>
> [ LABEL: ] given ( expr_1 ) {
>when expr_2 : block
>[ when expr_3 : block ...]
>expr_n [;]
>
> Damian,
> You mentioned in E2 that the chomped property relies on the insep
> property of the filehandle (formerly $/). Can I extrapolate that
>$.
>$,
>$\
>$|
> will also be properties on filehandles? (How about
>$"
> for arrays?)
It's not
> There are a number of properties "built into" Perl 6. Nearly all of these
> properties don't make sense across the board - eg, a scalar won't have a
> dimension, a hash won't prompt, etc.
>
> So given the two different sets that you must consider (variable versus
> value, and
On Thursday 02 August 2001 10:38 pm, Edward Peschko wrote:
> Statement: $bar isnt my_prop;
>
> This makes $bar keep all of its properties, removing my_prop;
No. This gives $bar the negation of my_prop, whatever it may be. It may be
its removal, it may be something else.
> Anyways, just a clar
On Thursday 02 August 2001 08:47 pm, Dan Sugalski wrote:
> At 06:57 PM 8/2/2001 -0400, Bryan C. Warnock wrote:
> >Here's how I'm documenting it. Corrections requested.
> >
> >Properties are by Perl thingy. (scalar, array, hash, reference, blessed
> >reference?, file handle, etc)
>
> I think they
Arrgh. lets try this again (for examples)
Statement: $bar = $foo is my_prop = 0 is some_prop;
This makes $foo have 'my_prop' and 'some_prop' with the value 0 - and $bar have
'my_prop' and 'some_prop' with the value 0.
Statement: $bar = 0;
This makes $bar have no properties with the value 0 (i
On Friday 03 August 2001 04:09 pm, Brent Dax wrote:
> # %foo is constant = (a=>1, b=>$foo);
> #
> # are only the keys contant; or both the keys and values.
>
> Keys and values, I imagine.
>
> # i.e. which of these is illegal
> #
> # %foo{c} = 1; # error
> # %foo{a} = 2; # probably error, but it wo
> I think they're supposed to be both by perl thingie and by value. So:
>
>my $foo is const = 0 is true;
>
> $foo has the property const, while the value 0 in $foo has
> the property true.
So, if I do
my $foo is constant = new Counter(0);
$foo->increment # OK
my $bar = new Counter(0) is
Here's how I'm documenting it. Corrections requested.
Properties are by Perl thingy. (scalar, array, hash, reference, blessed
reference?, file handle, etc)
That allows different things to be 'foo', for the appropriate definition of
'foo'.
---
Second thought:
Scribbling Servant
At 07:28 PM 8/2/2001 -0700, Edward Peschko wrote:
> > Now that you've got me thinking about it, that brings up some interesting
> > questions.
> >
> > $bar = $foo is my_prop = 0 is some_prop;
> > ($bar = $foo is my_prop) = 0 is some_prop;
> > $bar = ($foo is my_prop) = 0 is some_prop;
>
>This is w
If I've got a set of matching properties, do I get to build hotels on my
hashes?
There are a number of properties "built into" Perl 6. Nearly all of these
properties don't make sense across the board - eg, a scalar won't have a
dimension, a hash won't prompt, etc.
So given the two different
18 matches
Mail list logo
