On Wed, Jun 06, 2001 at 07:21:19PM -0500, David L. Nicol wrote:
> No, this datum is already known by defined() and exists() all I
> am suggesting is a name for the Perl API name for it.
Sorry, I didn't read your original post thoroughly enough; yes,
one for defined and exists would be feasible,
On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
> Damian Conway wrote:
> > $ref.{a}can be $ref{a}
> which can also be
> $ref.a
Dereferencing a hashref is the same as accessing a property?
I hope not.
--
Did you know that 1 barn yard atmosphere = 9.
Damian Conway wrote:
> I very much doubt Perl is going to become significantly more statically
> analyzable in general. Though static determinacy is obviously a
> desirable thing, there are plenty of other B&D
Bondage and Discipline?
> languages that offer it
> in abundance. And the dynamic pow
On Tue, 5 Jun 2001, Michael G Schwern wrote:
> On Tue, Jun 05, 2001 at 01:34:35PM -0700, Daniel S. Wilkerson wrote:
> > I cannot imagine running an enterprise critical application
>
> As a complete digression, can we please strike the term "enterprise"
> from the English lexicon? Completely r
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to an undeclared Foun.
>
> it is already detectable. from perldoc perlref:
Perhaps for perl 5, but, aiui, Damian confirmed
that my thi
David L. Nicol wrote:
> it isn't currently in 5.6.1's
>
> bool
> Perl_hv_exists(pTHX_ HV *hv, const char *key, U32 klen)
>
> function (contrary to what John Porter said)
Huh? What did I say?::
--
John Porter
On Thu, Jun 07, 2001 at 01:17:45AM +0100, Simon Cozens wrote:
> On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote:
> > Can someone post a few ? I am open to what are the pros/cons
> > but right now my mind is thinking " Whats the benefit of making
> > $a=(1,2,3); be the same as $a=[1,2,3
Me wrote:
>
> Question 1:
>
> Afaict, even with use strict at its most strict, perl 6
> can't (in practice) complain, at compile time, if
>
> $foo.Foun
>
> refers to an undeclared Foun.
>
> Right?
it is already detectable. from perldoc perlref:
Perl will raise an except
Me wrote:
> I.Found your notion of a "sealed off namespace"
> intriguing. I have no idea what it meant just yet;
> I'm going to go read and think about it now.
I'll pitch some syntax:
# prevent modification to %reflexive:: like so:
package reflexive is closed;
# allow i
Me wrote:
>
> > [strict typing]
> >
> > Not a negative, but realize that many people find it
> > of less value than the annoyances it brings with it
> > (myself included)
>
> Michael, I don't know which is more impressive; the
> fact that use of a strictly typed language implies that
> a copy of
Damian Conway wrote:
> $ref.{a}can be $ref{a}
which can also be
$ref.a
can it not?
Graham Barr <[EMAIL PROTECTED]>:
>On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
>> [EMAIL PROTECTED] writes:
>> :> What should $foo = (1,2,3) do now? Should it be the same as what
>> :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC
does what
>> :> $foo =
Simon Cozens wrote:
> Please don't try defending "it" or "$^d" in terms of efficiency;
> any variable that Perl has to keep track of magically takes a
> performance hit. Remember $`, $', and $&?
No, this datum is already known by defined() and exists() all I
am suggesting is a name for the Perl
On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote:
> Can someone post a few ? I am open to what are the pros/cons
> but right now my mind is thinking " Whats the benefit of making
> $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something
> different, ie what it does in perl5"
On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> :> What should $foo = (1,2,3) do now? Should it be the same as what
> :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
> :> $foo = \@INC; does now.) Putting it another
[EMAIL PROTECTED] writes:
:> What should $foo = (1,2,3) do now? Should it be the same as what
:> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
:> $foo = \@INC; does now.) Putting it another way: does a list in scalar
:> context turn into a reference, or
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote:
> But it's not as *convenient* as "unadorned" interpolation.
Disagree. "Adorning" a piece of syntax reminds the programmer that
something out of the ordinary is happening. It's a mental speed limit
sign - a traffic light, if you like
> > But it's not as *convenient* as "unadorned" interpolation.
>
> Sometimes convenient has to give way
Here we differ. I think the frequency of the
/$var.ident(whatever)/
pattern is likely to be low enough that method interpolation is a
better use for the syntax.
> > Exp
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote:
>> But with the above you still have abiguity, for example what does this do
>>
>> $bar =~ /$foo.colour($xyz)/;
>
> "Looks like a method call with parens, so *is* a method call with parens."
>
>
>> I may
> But with the above you still have abiguity, for example what does this do
>
> $bar =~ /$foo.colour($xyz)/;
"Looks like a method call with parens, so *is* a method call with parens."
> I may be remembering about interpolation into strings as "$file.ext" is
> going t
On Thu, Jun 07, 2001 at 07:43:55AM +1000, Damian Conway wrote:
>
>> >> So, to match $foo's colour against $bar, I'd say
>> >>
>> >> $bar =~ /$foo.colour/;
>> >
>> > No, you need the sub call parens as well:
>> >
>> > $bar =~ /$foo.colour()/;
> >> So, to match $foo's colour against $bar, I'd say
> >>
> >> $bar =~ /$foo.colour/;
> >
> > No, you need the sub call parens as well:
> >
> > $bar =~ /$foo.colour()/;
>
> Hm, I thought Larry said you would need to use $() to interpolate
On Thu, Jun 07, 2001 at 06:37:26AM +1000, Damian Conway wrote:
>
>> So, to match $foo's colour against $bar, I'd say
>>
>> $bar =~ /$foo.colour/;
>
> No, you need the sub call parens as well:
>
> $bar =~ /$foo.colour()/;
Hm, I thought Larry said you would need to use
> So, to match $foo's colour against $bar, I'd say
>
> $bar =~ /$foo.colour/;
No, you need the sub call parens as well:
$bar =~ /$foo.colour()/;
> Great, but how do I match $foo followed by any character followed by the
> literal "colour"?
$bar =~ /
Thanks *very* much for your answers; I still have a lot of work left
to do, it seems. But I'm still a little confused:
On Thu, Jun 07, 2001 at 06:08:23AM +1000, Damian Conway wrote:
>> Should properties interpolate in regular expressions? (and/or strings)
> Do you mean property look-ups via t
> Should properties interpolate in regular expressions? (and/or strings)
Do you mean property look-ups via the pseudo-method syntax?
In that case, yes they should
> I don't suppose they should, because we don't expect subroutines to.
> (if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we ne
On Wed, Jun 06, 2001 at 02:20:25PM -0500, David L. Nicol wrote:
> this is a confusing hack that might not save any cycles.
Please don't try defending "it" or "$^d" in terms of efficiency;
any variable that Perl has to keep track of magically takes a
performance hit. Remember $`, $', and $&?
--
Since this thread made it into this week's Official Perl6 Summary,
here goes a defense of C as a shorthand for the thing that last
had C or C queried of it.
It (by which I mean C, isn't this fun) would be a side-effect of
non-autovivifying queries. It allows redundant descents into arbitrarily
> [strict typing]
>
> Not a negative, but realize that many people find it
> of less value than the annoyances it brings with it
> (myself included)
Michael, I don't know which is more impressive; the
fact that use of a strictly typed language implies that
a copy of you would land on the poor un
On Wed, Jun 06, 2001 at 04:30:56PM +0100, Simon Cozens wrote:
> print $a->{test2};
Oh, hrm. Shouldn't it be $a{test2}? That works too, at any rate.
Does that mean that arrow between variable and subscript is optional,
or should this be some kind of error? Or should it mean something else
alt
I've been working on, uh, let's call it a "Perl 6 emulator" recently,
and I've come unstuck about a few things.
I'm sure I'll think of some more questions, but here we go for now:
Should properties interpolate in regular expressions? (and/or strings) I
don't suppose they should, because we don't
Michael G Schwern wrote:
> It will have to go for strict classes. @ISA will have to be locked.
"strict classes"?
> my $meth = "foo";
> $obj->$meth(); # $obj->foo();
>
> This definately can't work if $obj is of a class which is strongly
> typed.
"strongly typed class"?
> This can
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Consider the following... Foo is a poster-child for a strict class.
> Everything is predeclared and typed. Its entire hierarchy is rock
> solid. Someone uses Foo in their script and calls Foo->bar. They
> also use Bar, a module you installed a lon
"Daniel S. Wilkerson" <[EMAIL PROTECTED]> writes:
> Michael G Schwern wrote:
> > No subroutine refs. No dynamic inheritance. No autoloading. No
> > dynamic method calls. No symbol table manipulation. No eval. No
> > automatic method generation. (That's off the top of my head).
>
> You don'
34 matches
Mail list logo
