At 2:21 PM -0800 12/20/03, Larry Wall wrote:
On Sat, Dec 20, 2003 at 12:41:10PM -0800, Jonathan Lang wrote:
: So what happens if more than one of the candidates is tagged as the
: default? The same thing as if none of them was? This could happen if
: both Predator and Pet have declared their
On Sat, Dec 20, 2003 at 12:41:10PM -0800, Jonathan Lang wrote:
: So what happens if more than one of the candidates is tagged as the
: default? The same thing as if none of them was? This could happen if
: both Predator and Pet have declared their 'feed' methods as the default.
Could blow up,
- Original Message -
From: Jonathan Lang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, December 20, 2003 3:41 PM
Subject: [perl] Re: Object Order of Precedence (Was: Vocabulary)
Larry Wall wrote:
If DangerousPet doesn't define a feed method at all, then we might
dispatch
Joe Gottman writes:
- Original Message -
From: Jonathan Lang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, December 20, 2003 3:41 PM
Subject: [perl] Re: Object Order of Precedence (Was: Vocabulary)
Larry Wall wrote:
If DangerousPet doesn't define a feed method
Luke Palmer wrote:
Joe Gottman writes:
- Original Message -
From: Jonathan Lang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, December 20, 2003 3:41 PM
Subject: [perl] Re: Object Order of Precedence (Was: Vocabulary)
Larry Wall wrote:
If DangerousPet doesn't define a feed
On Mon, Dec 15, 2003 at 07:02:53PM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: Jonathan Lang wrote:
: : Let's see if I've got this straight:
: :
: : role methods supercede inherited methods;
:
: But can defer via SUPER::
:
: : class methods supercede role methods;
:
: But can
Larry Wall writes:
But if you say something like:
class DangerousPet does Pet does Predator {
multi method feed ($x) {...}
}
then DangerousPet::feed is called only when multimethod dispatch
would have thrown an exception. Alternately, multi's will probably have
some way
On Dec 16, 2003, at 10:20 PM, Rafael Garcia-Suarez wrote:
There's a need (more or less) for special blocks that can be run at the
end of the compilation phase of any arbitrary compilation unit.
This would be especially useful in an environment such as mod_perl,
where CHECK and INIT blocks
On Dec 17, 2003, at 1:39 AM, Simon Cozens wrote:
The desire to optimize the hell out of Perl 6 is a good one, but surely
you optimize when there is a problem, not when before. Is there a
problem
with the speed you're getting from Perl 6 at the moment?
Yes, it's taking too long to be released!
On Wed, Dec 17, 2003 at 06:20:22AM -, Rafael Garcia-Suarez wrote:
: Larry Wall wrote in perl.perl6.language :
: On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote:
: : When you say CHECK time, do you mean there'll be a CHECK phase for
: : code that gets required at run time?
:
:
Larry Wall [EMAIL PROTECTED] writes:
On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote:
: When you say CHECK time, do you mean there'll be a CHECK phase for
: code that gets required at run time?
Dunno about that. When I say CHECK time I'm primarily referring
to the end of the
[EMAIL PROTECTED] (Michael Lazzaro) writes:
Well, just for clarification; in my anecdotal case (server-side web
applications), the speed I actually need is as much as I can get,
and all the time. Every N cycles I save represents an increase in
peak traffic capabilities per server, which is,
Michael Lazzaro wrote:
I don't think so; we're just talking about whether you can extend a
class at _runtime_, not _compiletime_. Whether or not Perl can have
some degree of confidence that, once a program is compiled, it won't
have to assume the worst-case possibility of runtime
On Wed, Dec 17, 2003 at 06:20:22AM -, Rafael Garcia-Suarez wrote:
: Larry Wall wrote in perl.perl6.language :
: On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote:
: : When you say CHECK time, do you mean there'll be a CHECK phase for
: : code that gets required at run time?
:
:
On Tue, Dec 16, 2003 at 06:55:56PM -0500, Gordon Henriksen wrote:
: Michael Lazzaro wrote:
:
: I don't think so; we're just talking about whether you can extend a
: class at _runtime_, not _compiletime_. Whether or not Perl can have
: some degree of confidence that, once a program is
Michael Lazzaro writes:
On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote:
But the agreement could be implied by silence. If, by the time the
entire program is parsed, nobody has said they want to extend an
interface, then the interface can be considered closed. In other
words,
On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote:
: Michael Lazzaro writes:
:
: On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote:
: But the agreement could be implied by silence. If, by the time the
: entire program is parsed, nobody has said they want to extend an
:
On Tuesday, December 16, 2003, at 09:07 AM, Larry Wall wrote:
Seriously, I hope we can provide a framework in which you can screw
around to your heart's content while modules are being compiled,
and to a lesser extent after compilation. But we'll never get to a
programming-in-the-large model if
On Tue, 2003-12-16 at 12:06, Michael Lazzaro wrote:
My own first instinct would be that the run-time extensibility of a
particular interface/class would simply be a trait attached to that
class... by default, classes don't get it.
That doesn't sound very dynamic.
At the post-OSCON design
finally by default? None for me; thanks, though.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
On Tue, Dec 16, 2003 at 12:06:46PM -0800, Michael Lazzaro wrote:
As far as users of your class being able to specify that they want
something runtime-extensible, when your original module didn't call for
it, I don't see that as a problem, if they can just add the trait to
your class shortly
According to Jonathan Scott Duff:
Those classes that are closed can be opened at run-time and the
user pays the penalty then when they try to modify the class [...]
The optimization that can be reversed is not the true optimization.
--
Chip Salzenberg - a.k.a. -
Chip Salzenberg writes:
According to Jonathan Scott Duff:
Those classes that are closed can be opened at run-time and the
user pays the penalty then when they try to modify the class [...]
The optimization that can be reversed is not the true optimization.
While poetic and concise, I
Larry Wall writes:
On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote:
: Michael Lazzaro writes:
:
: On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote:
: But the agreement could be implied by silence. If, by the time the
: entire program is parsed, nobody has said
On Tuesday, December 16, 2003, at 12:20 PM, Gordon Henriksen wrote:
finally by default? None for me; thanks, though.
I don't think so; we're just talking about whether you can extend a
class at _runtime_, not _compiletime_. Whether or not Perl can have
some degree of confidence that, once a
According to Michael Lazzaro:
As someone who has 90% of their projects relying very critically on
speed
... an anecdote ...
and who has had to battle a number of clients' IT departments
over the years in defense of said speed compared to other popular
languages which, out of spite, I
Larry Wall [EMAIL PROTECTED] writes:
On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote:
: Michael Lazzaro writes:
:
: On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote:
: But the agreement could be implied by silence. If, by the time the
: entire program is parsed,
Michael Lazzaro [EMAIL PROTECTED] writes:
On Tuesday, December 16, 2003, at 12:20 PM, Gordon Henriksen wrote:
finally by default? None for me; thanks, though.
I don't think so; we're just talking about whether you can extend a
class at _runtime_, not _compiletime_. Whether or not Perl can
On Tuesday, December 16, 2003, at 04:01 PM, Chip Salzenberg wrote:
According to Michael Lazzaro:
As someone who has 90% of their projects relying very critically on
speed
... an anecdote ...
Yes.
and who has had to battle a number of clients' IT departments
over the years in defense of said
On Wed, Dec 17, 2003 at 12:15:04AM +, Piers Cawley wrote:
There's still a hell of a lot of stuff you can do with 'cached'
optimization that can be thrown away if anything changes. What the
'final' type declarations would do is allow the compiler to throw away
the unoptimized paths and the
According to Michael Lazzaro:
On Tuesday, December 16, 2003, at 04:01 PM, Chip Salzenberg wrote:
... an anecdote ...
... and a public relations issue.
Let us not confuse them.
I'm not sure I understand which part of that is in conflict.
Speed is for users. PR is for non-users.
You want
On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote:
: When you say CHECK time, do you mean there'll be a CHECK phase for
: code that gets required at run time?
Dunno about that. When I say CHECK time I'm primarily referring
to the end of the main compilation. Perl 5 appears to ignore
On Tuesday, December 16, 2003, at 05:36 PM, Chip Salzenberg wrote:
Speed is for users. PR is for non-users.
You want speed? OK, we can talk about the actual speed you actually
need based on your actual usage patterns. But from a design
perspective you're a collection of anecote, not a user
Michael Lazzaro writes:
I agree, it is frequently the case that the question of speed is made
critical by people who most assuredly do not need it. But they still
decide that way, and I have found that asserting to them that speed is
not important has been... well, less than effective. I
Larry Wall wrote in perl.perl6.language :
On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote:
: When you say CHECK time, do you mean there'll be a CHECK phase for
: code that gets required at run time?
Dunno about that. When I say CHECK time I'm primarily referring
to the end of
On Sun, Dec 14, 2003 at 06:14:42PM -0800, Larry Wall wrote:
On Sun, Dec 14, 2003 at 03:16:16AM -0600, Jonathan Scott Duff wrote:
[ my ramblings about a mechanism for role methods to supercede class
methods elided ]
I think there's a simple way to solve this: If you're changing the
policy
Larry Wall wrote:
Jonathan Lang wrote:
: Let's see if I've got this straight:
:
: role methods supercede inherited methods;
But can defer via SUPER::
: class methods supercede role methods;
But can defer via ROLE:: or some such.
Check, and check. Of course, SUPER:: works well in
On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote:
But the agreement could be implied by silence. If, by the time the
entire program is parsed, nobody has said they want to extend an
interface, then the interface can be considered closed. In other
words, if you think you *might* want
On Sat, Dec 13, 2003 at 01:44:34PM -0800, Larry Wall wrote:
On Sat, Dec 13, 2003 at 12:50:50PM -0500, Austin Hastings wrote:
: It seems to me there's an argument both ways --
:
: 1. Code written in the absence of a role won't anticipate the role and
: therefore won't take (unknowable) steps
Jonathan Scott Duff [EMAIL PROTECTED] writes:
On Sat, Dec 13, 2003 at 01:44:34PM -0800, Larry Wall wrote:
On Sat, Dec 13, 2003 at 12:50:50PM -0500, Austin Hastings wrote:
: It seems to me there's an argument both ways --
:
: 1. Code written in the absence of a role won't anticipate the role
On Sun, Dec 14, 2003 at 03:16:16AM -0600, Jonathan Scott Duff wrote:
: So, if we follow the rules in the Traits paper, a role may have no
: semantic effect if the object's class already provides the necessary
: methods. To *guarantee* that a role will modify an object's behavior,
: we need some
According to Larry Wall:
If, by the time the entire program is parsed, nobody has said they
want to extend an interface, then the interface can be considered
closed.
What with Ceval STRING and its various wrappers, when can the program
be said to be fully parsed? - anticipating Mu
--
Chip
Larry Wall wrote:
I think the class is still the final arbiter of what its objects
are--there is no other entity that holds all the reins. If a class
chooses to include a role, and that role violates the normal rules of
roles, the class is still responsible for that (or else you need some
On Sun, Dec 14, 2003 at 11:17:25PM -0500, Chip Salzenberg wrote:
: According to Larry Wall:
: If, by the time the entire program is parsed, nobody has said they
: want to extend an interface, then the interface can be considered
: closed.
:
: What with Ceval STRING and its various wrappers,
On Sun, Dec 14, 2003 at 09:05:37PM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: I think the class is still the final arbiter of what its objects
: are--there is no other entity that holds all the reins. If a class
: chooses to include a role, and that role violates the normal rules of
:
From: Larry Wall [mailto:[EMAIL PROTECTED]
On Fri, Dec 12, 2003 at 04:27:59PM -0500, Austin Hastings wrote:
: -Original Message-
: From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
: I think I'm getting it but I'm not sure. Does something like this
: work?
:
:my role
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 8:30 PM
On Fri, Dec 12, 2003 at 05:17:37PM -0500, Austin Hastings wrote:
: Good. I like the mixin being available at either time. This
makes properties
: a lot more useful since I can
On Sat, Dec 13, 2003 at 12:07:40PM -0500, Austin Hastings wrote:
: From: Larry Wall [mailto:[EMAIL PROTECTED]
: The behavior probably doesn't expire unless you've cloned the object
: and the clone expires. However, if a role goes out of its lexical
: scope, it can't be named, so it's
On Sat, Dec 13, 2003 at 12:50:50PM -0500, Austin Hastings wrote:
: -Original Message-
: From: Larry Wall [mailto:[EMAIL PROTECTED]
: Sent: Friday, December 12, 2003 8:30 PM
:
: On Fri, Dec 12, 2003 at 05:17:37PM -0500, Austin Hastings wrote:
: : I presume that the linear order
So I'm seeing a lot of inconsistent OO-vocabulary around here, and it
makes things pretty hard to understand.
So here's how Perl 6 is using said inconsistent terms, AFAIK:
- attribute
A concrete data member of a class. Used with Chas.
- property
An out-of-band sticky note
On Fri, Dec 12, 2003 at 04:23:02AM -0700, Luke Palmer wrote:
So I'm seeing a lot of inconsistent OO-vocabulary around here, and it
makes things pretty hard to understand.
So here's how Perl 6 is using said inconsistent terms, AFAIK:
- attribute
A concrete data member of a class
On Fri, Dec 12, 2003 at 04:23:02AM -0700, Luke Palmer wrote:
: So I'm seeing a lot of inconsistent OO-vocabulary around here, and it
: makes things pretty hard to understand.
Agreed.
: So here's how Perl 6 is using said inconsistent terms, AFAIK:
:
: - attribute
: A concrete data
It was Friday, December 12, 2003 when Luke Palmer took the soap box, saying:
: So I'm seeing a lot of inconsistent OO-vocabulary around here, and it
: makes things pretty hard to understand.
Awesome. I've taken your original, plus comments so far and created
perlvocab.pod. Lets give it a couple
-Original Message-
From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 11:13 AM
To: Luke Palmer
Cc: Language List
Subject: Re: Vocabulary
On Fri, Dec 12, 2003 at 04:23:02AM -0700, Luke Palmer wrote:
So I'm seeing a lot of inconsistent OO
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 6:23 AM
So I'm seeing a lot of inconsistent OO-vocabulary around here, and it
makes things pretty hard to understand.
So here's how Perl 6 is using said inconsistent terms, AFAIK
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 12:17 PM
: - role
: A collection of methods to be incorporated into a class sans
A role can also supply one or more attributes.
So a role can constrain values and add behavior
A role can also supply one or more attributes.
: inheritance (and maybe some other stuff, too). Used with Cdoes.
The smalltalk paper you mentionned which talked about roles (under
the name of traits) said that roles were stateless.
What are the consequences of using stateful
At 9:16 AM -0800 12/12/03, Larry Wall wrote:
On Fri, Dec 12, 2003 at 04:23:02AM -0700, Luke Palmer wrote:
: - property
: An out-of-band sticky note to be placed on a single object.
: Used with Cbut.
Maybe applied with?
: - trait
: A compile time sticky note to be
On Fri, Dec 12, 2003 at 04:27:59PM -0500, Austin Hastings wrote:
: -Original Message-
: From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
: I think I'm getting it but I'm not sure. Does something like this
: work?
:
: my role Teach { ... }
: my role Operate { ... }
:
On Fri, Dec 12, 2003 at 07:12:40PM +0100, Stéphane Payrard wrote:
:
: A role can also supply one or more attributes.
:
: : inheritance (and maybe some other stuff, too). Used with Cdoes.
:
: The smalltalk paper you mentionned which talked about roles (under
: the name of traits)
On Fri, Dec 12, 2003 at 04:31:32PM -0500, Austin Hastings wrote:
: - trait
:A compile time sticky note to be placed on a wide variety
: of things. Used with Cis.
:
: Did I miss something with IS and OF?
:
: That is, I think:
:
: Cis means storage type, while Cof means trait or
On Fri, Dec 12, 2003 at 05:17:37PM -0500, Austin Hastings wrote:
: -Original Message-
: From: Larry Wall [mailto:[EMAIL PROTECTED]
: Sent: Friday, December 12, 2003 12:17 PM
:
: : - role
: : A collection of methods to be incorporated into a class sans
:
: A role can also
62 matches
Mail list logo
