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
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 file
Trey Harris wrote:
One thing that occurs to me: following this contract or promise
analogy, what does C... mean in a role or class?
Unless I've missed somewhere in the Synopses that explicates C...
differently in this context, yada-yada-yada is just code that complains
bitterly (by calling
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
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
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
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 a
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
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's
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 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-later
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,
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 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]
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
HaloO,
Trey Harris wrote:
I would hate for Perl 6 to start using CAny or CWhatever 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
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
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, above)
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:
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
Executive summary:
I suggest a signature prototype that all multis defined in or exported
to the current namespace must match (they match if the proto would allow
the same argument list as the multi, though the multi may be more
specific). Prototypes are exportable. Documentation tie-ins are
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
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
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
25 matches
Mail list logo
