The Perl 6 Summary for the week ending 20031214
It looks like things are starting to slow down slightly as we run up to
Christmas, but the quality of discussion remains high. We'll start with
the usual trawl through perl6-internals.
Testing for null
Dan ruled on last week's discu
The Perl 6 Summarizer <[EMAIL PROTECTED]> writes:
> Vocabulary
> If you're even vaguely interested in the workings of Perl 6's object
> system, you need to read the referenced post.
>
> Luke Palmer, worrying about people using Object related vocabulary in
> subtly inconsistent way
Piers Cawley writes:
> The Perl 6 Summarizer <[EMAIL PROTECTED]> writes:
> > Vocabulary
> > If you're even vaguely interested in the workings of Perl 6's object
> > system, you need to read the referenced post.
> >
> > Luke Palmer, worrying about people using Object related vocabulary
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
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
>
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 we
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 shor
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
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
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
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
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 progr
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
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
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
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: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
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
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.
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
Luke Palmer <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
>> The Perl 6 Summarizer <[EMAIL PROTECTED]> writes:
>> >
>> > http://groups.google.com/[EMAIL PROTECTED]
>>
>> This should, of course, read:
>>
>> http://groups.google.com/[EMAIL PROTECTED]
>
> Or even:
>
> http://groups.google.c
26 matches
Mail list logo
