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 'fee
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 Dange
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)
>
>
>
- 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
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,
Larry Wall wrote:
> Jonathan Lang wrote:
> : Larry Wall wrote:
> : > Jonathan Lang wrote:
> Also, there will be access to the list of call candidates for SUPER::
> (and presumably ROLE::) such that the class's method can get explicit
> control of which super/role method or methods get called. So
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
> so
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;
: >
: >
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 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 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 current
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 comp
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?
: >
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 alter
[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, whic
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 o
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
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.
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 base
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 C
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.
Yo
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 t
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 speed
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 Per
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 progr
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
On Tuesday, December 16, 2003, at 03:00 PM, Luke Palmer wrote:
But Perl hinges on laziness, doesn't it? Eh, I trust that Perl 6 will
make it easy to figure that out in most cases. I was coming from the
perspective that 90% of my projects don't need speed; but I can say no
such thing on account of
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 prog
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
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
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. -
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 shor
finally by default? None for me; thanks, though.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
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
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 we
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
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
>
Jonathan Lang writes:
> Larry Wall wrote:
> > Well, nothing much really supercedes the class. Even traits have
> > to be requested by the class, and if you have an entirely different
> > metaclass, it's probably declared with a different keyword than
> > C. (But sure, multiple traits will have to
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 to
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 w
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
> pol
According to Larry Wall:
> Actually, I think making people declare what they want to extend
> might actually provide a nice little safety mechanism for what can
> be modified by the eval and what can't.
Well, I don't know about such 'safety' ... seems like a bone in a pond
to me ... but as a means
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
:
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 C and its various wrappers, when can th
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
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 C and its various wrappers, when can the program
be said to be fully parsed? <- anticipating "Mu"
--
Chip Salzenbe
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 sy
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 anticipat
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) st
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 (c
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 effec
> -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
> 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?
> : >
> :
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
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 C.
:
: Did I miss something with IS and OF?
:
: That is, I think:
:
: C means storage type, while C means trait or clas
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 C.
:
: The smalltalk paper you mentionned which talked about roles (under
: the name of traits) sai
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 { ... }
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 C.
Maybe "applied with"?
: - trait
: A compile time sticky note to be placed
>
> A role can also supply one or more attributes.
>
> : inheritance (and maybe some other stuff, too). Used with C.
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 roles?
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 i
> -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 be
> -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
> -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
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 con
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
>
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 C.
- property
An out-of-band stic
66 matches
Mail list logo
