HaloO,
Larry Wall wrote:
Basically, all types do Package whenever they need an associated
namespace.
Great! This is how I imagined things to be. And the reason why
the :: sigil is also the separator of namespaces.
And most of the Package role is simply:
method postfix:<::> () { return
On 9/29/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
And here I thought you were a responsible, law-abiding citizen... :P
And so it begins.
I daresay there will be no shortage of jokes among P6ers about "does Hash" ...
--
Mark J. Reed <[EMAIL PROTECTED]>
Larry Wall wrote:
but only if self.HOW does Hash.
And here I thought you were a responsible, law-abiding citizen... :P
--
Jonathan "Dataweaver" Lang
On Fri, Sep 29, 2006 at 01:24:12PM -0700, Larry Wall wrote:
: method postfix:<::> () { return %.HOW.packagehash }
Urque.
Actually, that'd have to be %($.HOW.packagehash) or $.HOW.packagehash.{},
since what I wrote there would mean %(self.HOW).packagehash instead, which
might work accidentally
On Fri, Sep 29, 2006 at 02:05:06PM -0400, Mark J. Reed wrote:
: On 9/29/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
: >Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
: >uses 'module' to refer to 'a perl 5-or-earlier module', and uses
: >'package' to refer to the perl 6-or-lat
Mark J. Reed wrote:
Jonathan Lang wrote:
> Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
> uses 'module' to refer to 'a perl 5-or-earlier module', and uses
> 'package' to refer to the perl 6-or-later equivalent.
Other way around. "package" is Perl 5, because that's the P5
On 9/29/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
uses 'module' to refer to 'a perl 5-or-earlier module', and uses
'package' to refer to the perl 6-or-later equivalent.
Other way around. "package" is Perl 5, because that'
On Fri, Sep 29, 2006 at 12:35:43AM -0700, Trey Harris wrote:
: If you define a BUILD in a role, will it be called when an object of a
: class that does the role is instantiated, as part of the .new BUILD walk?
Yes. That is mentioned in A12, even if S12 didn't make it explicit.
At least S12:531 i
Aaron Sherman wrote:
In the RFC, I was trying to develop a method by which a module could
assert a stricture (consider this part of "use strict" in Perl 6 if you
will) that would constrain the CALLER of that module (as well as the
module itself, of course) to a particular signature template for
Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
uses 'module' to refer to 'a perl 5-or-earlier module', and uses
'package' to refer to the perl 6-or-later equivalent.
Aaron Sherman wrote:
Details:
Larry has said that programming by contract is one of the many paradigms
that
In a message dated Fri, 29 Sep 2006, Aaron Sherman writes:
First the high-level point: I'm dropping the RFC, because, as TimToady
pointed out on IRC, we're not quite far enough down the line to see the
breadth or certainty of the need yet.
Yes, but I don't think the conversation should stop.
In a message dated Thu, 28 Sep 2006, Jonathan Lang writes:
while roles can be abstract, classes and packages should not be.
Really? I think I need to let that sink in and percolate a bit.
I'm rather fond of creating abstract superclasses to factor out common
object-management code. I have m
Jonathan Lang wrote:
I hope not. My understanding is that '{ ... }' is supposed to
represent the notion of abstract routines: if you compose a role that
has such routines into a class or package, I'd expect the package to
complain bitterly if any such routines are left with yada-yadas as
their c
In a message dated Thu, 28 Sep 2006, Aaron Sherman writes:
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate fil
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
> POD).
That's a fi
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
> POD).
That's a fine thing to want to do
Jonathan Lang wrote:
Aaron Sherman wrote:
TSa wrote:
> Miroslav Silovic wrote:
>> package Foo does FooMultiPrototypes {
>> ...
>> }
>
> I like this idea because it makes roles the central bearer of type
> information.
Type information is secondary to the proposal, but I'll run with what
you sai
Aaron Sherman wrote:
TSa wrote:
> Miroslav Silovic wrote:
>> package Foo does FooMultiPrototypes {
>> ...
>> }
>
> I like this idea because it makes roles the central bearer of type
> information.
Type information is secondary to the proposal, but I'll run with what
you said.
This (the example,
TSa wrote:
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe
that declarative requirements should go on roles. And then packages
could do them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the
HaloO,
Trey Harris wrote:
I would hate for Perl 6 to start using C or C in the
sort of ways that many languages abuse "Object" to get around the
restrictions of their type systems. I think that, as a rule, any
prototype encompassing all variants of a multi should not only
specify types big e
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe that
declarative requirements should go on roles. And then packages could do
them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bea
Aaron Sherman wrote:
I certainly hope not, as I agree with you! That's not the goal at all,
and in fact if that were a side effect, I would not want this to be
implemented. The idea of having types AT ALL for protos was something
that I threw in because it seemed to make sense at the end. The re
Trey Harris wrote:
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes:
Any thoughts?
I'm still thinking about the practical implications of this... but
what immediately occurs to me:
The point of multiple, as opposed to single, dispatch (well, one of
the points, and the only point t
Minor nitpick:
Any types used will constrain multis to explicitly matching those types
or compatible types, so:
our Int proto max(Seq @seq, *%adverbs) {...}
Would not allow for a max multi that returned a string (probably not a
good idea).
IIRC, perl 6 doesn't pay attention to the le
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes:
Any thoughts?
I'm still thinking about the practical implications of this... but what
immediately occurs to me:
The point of multiple, as opposed to single, dispatch (well, one of the
points, and the only point that matters when we'
25 matches
Mail list logo
