> > Err. There are only two things: compile-time variable properties and
> > run-time value properties. Attributes are a Perl 5 construct that we're
> > renaming because the name conflicts with the OO term for object data.
>
> So,
>
> $a is true
>
> and
>
> $
> Err. There are only two things: compile-time variable properties and
> run-time value properties. Attributes are a Perl 5 construct that we're
> renaming because the name conflicts with the OO term for object data.
So,
$a is true
and
$a.true = 1
are synonyms, right?
if not, then there are
Scott wrote:
> Would you also advocate separate declarative syntax for variable
> properties and value properties? That's where I think much confusion
> will be.
That's covered in my new proposal too.
Damian
Dave Storrs wrote:
> Second: I'm afraid that even after all this discussion and puzzling over
> this table for a bit, I'm still a bit baffled by this stuff. Perhaps I'm
> just slow, but let's assume for the sake of argument that I'm not the only
> one still scratching his head. C
On Mon, May 21, 2001 at 12:47:15PM -0700, Dave Storrs wrote:
> On Mon, 21 May 2001, Jonathan Scott Duff wrote:
> > Would you also advocate separate declarative syntax for variable
> > properties and value properties? That's where I think much confusion
> > will be.
>
> Yes, I would. What
Scott Duff wrote:
> > $bar is Open;
> > $bar is Open("from 5pm");
> > $bar{soom} is Open("from 5pm");
> > "bar" is Open("from 5pm");
> > 1 is Open("from 5pm");
> >
> > Note that in the first three of the above cases, it's the I > vari
On Mon, May 21, 2001 at 08:04:58AM -0500, Jarkko Hietaniemi wrote:
> All this talk about slices reminds me of this:
>
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-10/msg00024.html
>
> Although in this thread the idea was more in the way of an internal
> implementation (e.g. to
On Mon, 21 May 2001, Jonathan Scott Duff wrote:
> On Mon, May 21, 2001 at 10:01:28AM -0700, Dave Storrs wrote:
>
> Would you also advocate separate declarative syntax for variable
> properties and value properties? That's where I think much confusion
> will be.
Yes, I would. What th
* Jonathan Scott Duff <[EMAIL PROTECTED]> [05/21/2001 09:39]:
>
> If anything, all variables should have a "value" property that evaluates
> to its, well, value and only that property would be considered in
> conditionals. Then these would be equivalent:
>
> print keys (+$foo).prop;
>
On Mon, May 21, 2001 at 10:01:28AM -0700, Dave Storrs wrote:
> First of all, thanks for putting this table together; this is good way to
> clear all the up.
You're welcome.
> Could we revist the idea of alternate syntax to disambiguate between
> value and variable cases? Perhaps now that we've f
On Mon, May 21, 2001 at 08:57:45AM +0100, Graham Barr wrote:
> On Sun, May 20, 2001 at 01:24:29PM +0100, Simon Cozens wrote:
> > On Sun, May 20, 2001 at 12:46:35AM -0500, Jonathan Scott Duff wrote:
> > > my $a is true = 0; # variable property
> > > my $a = 0 is true;
1) It looks like properties proposed will introduce an inconsistency in
naming conventions. In OO-Perl programmers are advised to use leading
lowercase for object methods and leading uppercase for class methods.
Properties are lowercase for built-ins and uppercase for user-defined. Don't
we need t
On Mon, 21 May 2001, Jonathan Scott Duff wrote:
> So, if I have a Dog $spot, here's a little table where a 1 in the M
> column means $spot has a bark method that says 'woof', 1 in the V column
> means $spot has a bark variable (compile-time) property that says 'arf'
> and a 1 in the A column me
On Sat, May 19, 2001 at 11:30:40AM +1000, Damian Conway wrote:
> I obviously didn't do an adequate job the first time.
I don't know about that, but the universe of Perl 6 properties is
looking clearer to me now and I thank you for it.
> Here, the C property is being set I in $result and that
> a
Damian Conway <[EMAIL PROTECTED]> wrote
>> > >my $a is true = 0; # variable property
>> > >my $a = 0 is true; # variable property
>> > >my ($a) = 0 is true;# value property
>> >
>> > Wow. Totally ETOOCONFUSING.
>
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Mon, May 21, 2001 at 08:57:45AM +0100, Graham Barr wrote:
> > So far all I can think of for variable properties are actually compile time
> > properties like constant etc.
> > So I am left wondering how much of an issue this really will be ?
>
> The
Graham wrote:
> > >my $a is true = 0; # variable property
> > >my $a = 0 is true; # variable property
> > >my ($a) = 0 is true;# value property
> >
> > Wow. Totally ETOOCONFUSING.
>
> That has been exactly my thou
On Mon, May 21, 2001 at 08:57:45AM +0100, Graham Barr wrote:
> So far all I can think of for variable properties are actually compile time
> properties like constant etc.
> So I am left wondering how much of an issue this really will be ?
The beautiful and the horrible thing about Perl is that th
Peter wrote:
> >$ref =
> > sub{my%k;@k{@{+pop}}=\(@_);splice@_,$_,!$k{$_}for reverse
> > 0..@_;\@_}->(@A,\@I);
>
> Oh, well, if I'd known it was *that* succinct...
>
> But... that *does* involve copying; the original poster was talking
> about huge arrays where copyin
On Sun, May 20, 2001 at 06:19:35PM -0400, Uri Guttman wrote:
> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>
>
> DC> return undef Because($borked);
>
> hmm, that is poor code as returning a real undef will break in a list
> context.
I always balk when I see someone say th
On Sun, May 20, 2001 at 01:24:29PM +0100, Simon Cozens wrote:
> On Sun, May 20, 2001 at 12:46:35AM -0500, Jonathan Scott Duff wrote:
> > my $a is true = 0; # variable property
> > my $a = 0 is true; # variable property
> > my ($a) = 0 is true;# val
21 matches
Mail list logo
