Matthew Hodgson wrote:
These rules are all fair enough - but they are then ambiguous for
$::Foo. Is that the leaf name variable Foo in your current (innermost)
namespace?
It is not ambiguous if the sigil rules that expression. I assume
that the parameters of a sub are definining innermost
On Thu, Jul 07, 2005 at 08:32:47AM -0500, Jones Robert TTMS Contractor wrote:
When I go to the donation page and attempt to make a donation, the
drop-down box does not give DBI as a valid recipient. Is it possible
several people may not have donated as they noticed the same results, or
On 7/20/05, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
brentdax Is there a Perl 6 tail call syntax,
One suggestion was a tweak of `can`'s definition: instead of returning
a reference to the method, it returns one with the invocant already
curried into it. Thus, the above becomes
chromatic wrote:
On Tue, 2005-07-19 at 18:47 +0200, TSa (Thomas Sandlaß) wrote:
I strongly agree. They should share the same namespace. Since
code objects constitute types they also share this namespace.
This means that any two lines of
class Foo {...}
roleFoo {...}
sub Foo {...}
On Thu, 21 Jul 2005, TSa (Thomas Sandlaß) wrote:
Matthew Hodgson wrote:
I guess $::('Foo') was a bad example - $Foo=Foo; $::($Foo) would have
been better at illustrating my point - which was that if $::($Foo)
searches outwards through namespace for a variable whose name is held in
$Foo, then
chromatic wrote:
Why would a class not also define a type?
It does. A class is an instance generator. So all instances
share the same property of 'beeing instanciated from SomeClass'.
This can be used to type them. Question is where this type is
placed in the type lattice and how it compares
Larry said:
So I guess I agree that .tailcall is probably just a bad synonym for return.
But is there any other case where we need an explicit tail call with goto?
And about a way to curry a method with its receiver to a sub, is there
a shorthand?
Thanks,
Adriano.
HaloO Matthew,
you wrote:
I wasn't getting hung up on whether $::($varname) should somehow be
cached to avoid a dynamic lookup based on the current value of $varname
every time. And I assume that if $*Main::foo hadn't been created,
assigning to $::($varname) would create it as expected
On 7/20/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Hi,
# Perl 5
my %hash = (a = 1, b = 2, a = 3);
warn $hash{a}; # 3
But I vaguely remember having seen...:
# Perl 6
my %hash = (a = 1, b = 2, a = 3);
say %hasha;# 1
Can somebody confirm this?
Yes.
TSa (Thomas Sandlaß) wrote:
Here your expectations might be disappointed, sorry.
The non-symbolic form $*Main::foo = 'bar' creates code that
makes sure that the lhs results in a proper scalar container.
The symbolic form might not be so nice and return undef!
Then undef = 'bar' of course let's
On 7/21/05, Larry Wall [EMAIL PROTECTED] wrote:
Have at it...
The only thing I immediately don't like is the use of the normal identifier
character _ to indicate the specialness of a particular variable (or
attribute or whatever we're calling them these days). IMO, a _ should
just be a _ no
Larry Wall wrote:
has $x; # private rw, no accessors, not virtual, name lexically scoped
has $_x;# private rw, rw _x accessor, not virtual, name class scoped
Even if I come across as intellectually handicapped but could
someone help me over this mental bridge: What is the
On Thursday 21 July 2005 12:48 pm, Larry Wall wrote:
* Don't need to topicalize self any more.
* .foo can (again) always be the topic without warnings.
Thank you.
Do the following exist then:
has @x; # private, lexically scoped
has @_x; # private, class scoped, rw _x accessor
On Thu, Jul 21, 2005 at 02:29:33PM -0600, Paul Seamons wrote:
: On Thursday 21 July 2005 12:48 pm, Larry Wall wrote:
: * Don't need to topicalize self any more.
:
: * .foo can (again) always be the topic without warnings.
:
: Thank you.
:
: Do the following exist then:
:
:has @x;
Larry,
This means that Roles are now first-class-ish things. Meaning they
cannot just simply be composed into classes since now we have to keep a
table of elements which are private to a Role.
I personally don't like this, I think it brings us back to Mix-ins and
(possibly) looses some of
On Thu, Jul 21, 2005 at 05:15:34PM -0400, Stevan Little wrote:
: Larry,
:
: This means that Roles are now first-class-ish things. Meaning they
: cannot just simply be composed into classes since now we have to keep a
: table of elements which are private to a Role.
Well, we've kinda been
On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
: On 7/21/05, Larry Wall [EMAIL PROTECTED] wrote:
: Have at it...
:
: The only thing I immediately don't like is the use of the normal identifier
: character _ to indicate the specialness of a particular variable (or
: attribute or
Larry Wall wrote:
: Do the following exist then:
:has @x; # private, lexically scoped
[...]
:has %y; # private, lexically scoped
[...]
Yes, the sigil is fairly orthogonal to all this, hopefully.
Yes, for isn't the sigil just a compact form of saying does Hash or
does Array ? (as
18 matches
Mail list logo
