On Wed, 02 Oct 2002 04:12:44 -0700, Michael G Schwern wrote:
I like the class Vehicle is interface as a shorthand for declaring every
method of a class to be an interface.
Perhaps associating a property with a class can be shorthand for associating
that property with every method of the
On Sat, 12 Oct 2002 08:43:46 -0700, Larry Wall wrote:
On Sat, 12 Oct 2002, Graham Barr wrote:
: Or even something like
:
: use Acme[1.0];
Hmm. Looks kinda like a subscript, which could be sliced to give an
acceptable version range:
use Acme[1;0..];
Might it be possible to say
On Tue, 29 Oct 2002 14:19:59 -0800, Paul Johnson wrote:
So I would like to see able to tag arbitrary information onto just about
everything, including files, packages, classes, subroutines, blocks, control
structures, statements, lines, expressions, variables and whatever else I've
forgotten
On Tue, 05 Nov 2002 23:18:01 -0800, Allison Randal wrote:
If you really want to be involved where the rubber meets the road -- where the
abstract design gets tested and every last detail must be fleshed out -- you
might contribute to Parrot. It has a good many of the features of the first 5
On Fri, 06 Dec 2002 14:16:43 +, Brad Hughes wrote:
In any case, the choice of default base index is less important for Perl than
for other languages given how seldom arrays in Perl are accessed by index as
opposed to manipulated by push, pop, for $x (@array) loops and such.
I slice a lot
On Tue, 07 Jan 2003 12:21:48 +0100, Rafael Garcia-Suarez wrote:
Delegation has drawbacks compared to inheritance : you can't use
a object that delegates to class Foo where an instance of Foo is
expected.
That sounds more like a problem with the polymorphism implementation than an
argument
On Fri, 10 Jan 2003 14:12:12 +, Thom Boyer wrote:
'Course, then I've gotta explain why
$x = 7 ~ 63;
doesn't evaluate to 9
Surely because you haven't yet overloaded gozinta for the Number class!
-- c
On Fri, 14 Mar 2003 10:46:31 +, Larry Wall wrote:
If you say
$foo.isa(Even)
it doesn't just check to see if $foo is a member of class Int, but it also
checks the constraints on type Even, and returns false unless $foo is an even
integer.
We could still call Even a class if we
On Tue, 18 Mar 2003 20:43:00 +, Luke Palmer wrote:
Damian wrote:
caller :{.label eq 'MAINLOOP};
Errr what is that odd and disturbing notation? I don't recall ever seeing
that.
It's vaguely sinister. Must be the moustache operator.
-- c
On Saturday, July 19, 2003, at 04:25 AM, Luke Palmer wrote:
In Objective-C:
id untyped = somefunction();
idFoo typed = otherfunction();
If you send a message to Ctyped which isn't in the CFoo protocol
definition, you get warnings. Depending on the implementation, that
assignment might
On Thursday, July 24, 2003, at 08:49 AM, David Wheeler wrote:
On Wednesday, July 23, 2003, at 05:57 PM, chromatic wrote:
The first is a deeper question -- besides inheritance, there's
delegation, aggregation, and reimplementation (think mock objects)
that can make two classes have equivalent
On Thursday, July 24, 2003, at 11:17 AM, Austin Hastings wrote:
No, I think Java interfaces are a kluge to get around copying a
broken type system and the lack of multiple inheritance.
Multiple Inheritance != Protocols | Interfaces
I quite agree, but I've done enough Java to know that if they
On Thursday, July 24, 2003, at 05:28 PM, Benjamin Goldberg wrote:
If this were Java, the way to do this would be to define a Thingie
interface, and then an (archetypical) ThingieObject class... any time
that we want to actually *create* Thingies, we would use new
ThingieObject, but everywhere
On Mon, 2003-09-15 at 17:39, [EMAIL PROTECTED] wrote:
The easy-to-optimise case should be the easy-to-type case; otherwise a lot
of optimisation that should be possible isn't because the programmers are
too inexperienced/lazy/confused to put the closed tags in.
The thinking at the last design
On Thursday, September 18, 2003, at 07:49 AM, Austin Hastings wrote:
Sounds like a potential keyword, or perhaps a ubiquitous method, or
both. But how to differentiate sealed under optimization versus
sealed under inheritance?
I don't understand the question.
The point is not for module authors
On Thursday, September 18, 2003, at 12:33 PM, Gordon Henriksen wrote:
Ah, shouldn't optimization be automatic? Much preferrable to provide
opt-out optimizations instead of opt-in optimizations.
No. That's why I tend to opt-out of writing in C and opt-in to writing
Perl.
Perl (all versions) and
On Fri, 2003-11-14 at 22:23, Rod Adams wrote:
(If there are others working in the shadows back there, please make
yourselves heard.)
Allison Randal, Dan Sugalski, Hugo van der Sanden, and I usually help
out.
Can apocalypses be something more along the line of scratches on the wall,
that
On Thu, 2003-12-11 at 18:15, Jonathan Lang wrote:
Based on the source material pointed to as your inspiration for roles, I'm
a little confused as to how roles and classes could be unified. From what
I read in the source material, a key point of a role (well, they weren't
actually calling it
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 Tue, 2004-01-06 at 22:26, Austin Hastings wrote:
So on the grand balance of utility, what are the metrics that traits are
supposed to help improve?
Two big ones:
- naming collections of behavior that are too fine-grained to fit into
classes cleanly
- enabling finer-grained
On Wed, 2004-01-07 at 00:43, Jonathan Lang wrote:
Maybe as an alternative to
role Stringify {must stringify();}
sub print_it (Stringify $thingie) {print $thingie.stringify();}
you might be able to say
sub print_it ($thingie must stringify()) {print $thingie.stringify();}
On Thu, 2004-01-08 at 16:24, Jonathan Lang wrote:
In this example, there's no difference between the Dog and Tree roles;
however, this would almost certainly not be the case most of the time - at
the very least, a class with a Dog role would have @.legs, while a class
with the Tree role would
On Thu, 2004-02-12 at 05:52, Aaron Sherman wrote:
Perhaps I'm slow, but I don't see the difference between a trait and a
Java interface other than the fact that traits appear to be more of a
run-time construct.
The easy answer is that interfaces completely suck while traits don't.
:)
On Thu, 2004-02-12 at 11:49, Larry Wall wrote:
What I'm currently thinking about is a does predicate that tells you
if an object/class does a particular role completely. If you pull
part of a role into a class, it returns false, because it doesn't do
the complete role. However, if you use
On Fri, 2004-02-13 at 11:02, Aaron Sherman wrote:
On Thu, 2004-02-12 at 14:03, chromatic wrote:
The easy answer is that interfaces completely suck while traits don't.
:)
Ok, so what you're saying is that they're solving for exactly the same
thing, but you don't like the Java
On Sun, 2004-02-22 at 11:34, stevan little wrote:
One thing that I noticed was that the authors seem to not intend
Traits to be thought of as being like Classes. As a matter of fact
they distinguish Traits from Classes in their Trait Language
(contained in the above paper). So the idea of
On Thu, 2004-02-26 at 11:50, Mark J. Reed wrote:
Cool! But now I'm a little confused - what happened to Apocalypses 8
through 11? :)
They were:
- 8, References
- 9, Data Structures
- 10, Packages
- 11, Modules
Since 12, Objects is more important (and covers
On Thu, 2004-02-26 at 13:42, Simon Cozens wrote:
[EMAIL PROTECTED] (Larry Wall) writes:
It's the coherence that I can't delegate, and if I tried to, we would
certainly end up with Second System Syndrome Done Wrong, instead of Done
Right.
You know, it's statements like this that make it
On Thu, 2004-02-26 at 09:31, Aaron Sherman wrote:
And in it Apocalypse #26 was mentioned. Above, Larry mentions #11. At
first the rate of 1 apolcalypse per month seemed to support the idea
that Perl 6 would be defined within the next couple of years. However,
trending shows that this function
On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
Well, okay, not a boolean. More like a troolean.
Unless it's a falselean.
-- c
On Wed, 2004-04-14 at 12:24, Juerd wrote:
chromatic skribis 2004-04-14 12:07 (-0700):
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
How do you request a hash slice with backticks?
You don't. There are %foofoo bar and %foo{'foo', 'bar'} already
On Thu, 2004-04-15 at 12:27, Scott Walters wrote:
Without commenting on the rest of the proposal, please allow me to clear
up one point:
* Rather than eliciting public comment on %hash`foo (and indeed %hashfoo)
the proposal is being rejected out of hand
This whole thread *is* public comment.
On Thu, 2004-04-15 at 13:37, Larry Wall wrote:
Well, I, for one, think chromatic was right on the money.
No matter how right my thoughts might have been, my tone *was* rude and
that's not right. Apologies to Scott.
-- c
Perl.com has just made A12 available:
http://www.perl.com/pub/a/2004/04/16/a12.html
Warning -- 20 pages, the first of which is a table of contents.
Enjoy,
-- c
On Wed, 2004-04-21 at 04:19, Buddha Buck wrote:
From one C6PAN module:
role Dog {
has $.collar;
...
}
From a third C6PAN module:
class PoliceDog does Dog does LawEnforcementOfficer { ... }
role LawEnforcementOfficer {
method arrest { ... }
has $.collar;# for
On Fri, 2004-04-23 at 21:44, Jonathan Lang wrote:
OK: I'm planning on creating a widget which must not make use of any of
the indicator functionality of the HList; I don't just want to not use the
functionality - I want to have its use forbidden (letting the optimizer go
ahead and toss out
Remember, the non-controversial decisions in A12 and the other
Apocalypses, Exegeses, and Synopses are prime fodder to add to the P6
Stories wiki at http://p6stories.kwiki.org/.
Good stories and, even better, small test cases with code and expected
output make the Perl 6 compiler suite *much*
On Thu, 2004-05-06 at 10:39, Aaron Sherman wrote:
The simple case is:
sub foo(X $i is rw) {...}
class X {...}
class Y {...}
my Y $var = 'something';
foo($var);
In this case, something kind of interesting has to happen.
Either the signature checking has
On Thu, 2004-05-06 at 11:24, Dan Sugalski wrote:
Well... sort of, but only because you've defined that for perl 6
classes automatically do themselves--you've conflated inheritance and
interface. Which is fine, except that it falls down in the face of
objects from classes that don't do
On Thu, 2004-05-06 at 13:27, Austin Hastings wrote:
I think we had this discussion a year or two ago, and Damian was opposed to
the notion that providing the correct methods was equivalent to providing
the interface or belonging to the class.
His reasoning involved Dog and Tree both sharing
On Thu, 2004-05-06 at 13:47, Austin Hastings wrote:
Then in your example:
The class 'Eh' does A but does not inherit, did you mean:
class Eh {
method A1
method A2
method A3
}
Yes.
I had thought that Cdoes CLASS (class implicitly= role) had been
rejected.
I don't remember in
On Mon, 2004-05-17 at 13:35, Pedro Larroy wrote:
Would it be a good idea to make ==, and other numeric comparators polymorphic
so they can be used also for string comparisons?
How does the compiler know which is which?
Is 10 a string? Is it a number? Is 10base-T a string? Is it a
number?
On Mon, 2004-05-17 at 13:51, Pedro Larroy wrote:
I thought perl internally would know. At least in perl5 it has to know
somehow, since you can $var++ when is numeric and also when it's a
string, and behaves different in each case.
True. Perl 5 scalars do keep track of the context in which
On Wed, 2004-06-30 at 18:18, Alexey Trofimenko wrote:
P.P.S. do we have a way to imply void context on function inside
expression, something like Cscalar, C+, C~, C? do?
Sort of a 'meh' operator?
I wonder (idly) in which circumstances the context determinator couldn't
determinate void
On Tue, 2004-07-20 at 19:35, Luke Palmer wrote:
The New Way (tm) to do that would probably be sticking a role onto the
array object with which you're dealing:
my @foo does separator('//') = (1,2,3,4,5);
say [EMAIL PROTECTED]; # 1//2//3//4//5
Shh, no one's let slip the idea of
On Mon, 2004-07-19 at 14:04, David Storrs wrote:
Second, I would suggest that it NOT go in a library...this is
reasonably serious under-the-hood magic and should be integrated into
the core for efficiency.
You must have amazingly fast hard drives.
-- c
On Tue, 2004-08-17 at 12:54, Larry Wall wrote:
But we'll just have to shoot anyone who makes a wisecrack like:
use parens :lisp;
Surely that should have its own pragma:
use parenths;
-- c
On Fri, 2004-08-20 at 14:26, Austin Hastings wrote:
Dan Hursh wrote:
generalimpose scalarimpose list
-----
D$foo.eat$foo.bite$foo.gobble
N$foo.look$foo.peek$foo.peruse
hmm, I don't like eat
On Sat, 2004-09-04 at 18:44, John Siracusa wrote:
Without commenting on the issue of single-file bundling...
To bring it home, I think packaging and distribution is important enough to
warrant a standard, core-supported implementation.
I think the specially structured dir of files and its
On Wed, 2004-09-15 at 12:47, Larry Wall wrote:
Grammar roles?
It seems sensible, having said Here's a better method of type checking
and code re-use and Here's a generalization of pattern matching to
make it more like programming.
Not doing it would be like making closures that can't write to
On Wed, 2004-09-22 at 10:49, Luke Palmer wrote:
Let me come right round to my point about perl being open source.
Someone has to do the work somewhere, and making it standard or core
doesn't change that. It just means that it'll take longer.
It also means that there's a possibility that the
On Wed, 2004-11-03 at 20:08, Milscvaer wrote:
First, Perl ought to allow bytecode, already compiled,
to be loaded via a bytecode equivelant to eval(), if
this cannot be done already.
Please read through the design documents:
http://dev.perl.org/perl6/
Many of these ideas have come
On Sun, 2004-12-19 at 20:25 -0600, Rod Adams wrote:
One of the other reasons in favor of the idea was aesthetic.
# stuff which declares $x, $z, and $q
$x = 4;
my $y = 7;
$z = 12;
my $r = 4543;
$q = 121;
compared to:
# stuff which declares $x, $z, and $q
$x = 4;
$y = 7;
$z =
On Tue, 2005-02-15 at 14:26 -0600, Rod Adams wrote:
The obvious statement I expect to here is Perl's always had Arrays
and Hashes. While I'm not sure if they were there for Perl 1.0 (I
started w/ Perl 4.xx)
They were.
So I'm interested in hearing what pushes Arrays and Hashes over the edge
On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
And what of .c#?
It's an alias for .java.
-- c
On Fri, 2005-03-04 at 21:12 +0100, Thomas Sandlaß wrote:
The roles themself beeing the least member of these classes---uninstanciable
pure
behaviour. The intersection type/role AB is multiple inheritance (or is that
roling?):
I don't understand the question (I don't recognize the words lubs
On Mon, 2005-03-07 at 19:40 -0800, Larry Wall wrote:
On Mon, Mar 07, 2005 at 05:56:12PM -0800, David Storrs wrote:
: Actually, I guess they would have to be...can you apply a role to a
: bare type?
:
: my int does SelectOutputFile; # I would expect this to fail
: my Int does
On Tue, 2005-03-08 at 17:39 -0800, Larry Wall wrote:
On Tue, Mar 08, 2005 at 03:23:14PM -0800, chromatic wrote:
: I could make the argument that it should be possible to decorate an
: object with a role. If that means generating a new anonymous class just
: to have a vtable to munge, so
Forwarded...
On Sat, 2005-03-26 at 12:05 +1100, Andrew Savige wrote:
Please note that I am not an expert on any of this, I was just
wondering whether we are going to clean up the old p5 library
interfaces as part of the move to p6. Or must we support the
old p5 library interfaces for
On Wed, 2005-03-30 at 14:29 -0500, Aaron Sherman wrote:
What I do not think should be allowed (and I may be contradicting Larry
here, which I realize is taking my life in my hands ;) is violating the
compile-time view of the static type tree. That is, you can load an
object foo at run-time,
On Wed, 2005-03-30 at 15:27 -0500, Aaron Sherman wrote:
Like I said, if you allow run-time munging of the type interfaces, then
you can't tell if this is valid or invalid:
my X $a;
$a.m(1);
you have to allow it always, regardless of the definition of X. In fact,
you can
On Thu, 2005-03-31 at 13:11 -0500, Aaron Sherman wrote:
I can't answer most of these well. However...
One additional wrinkle is that *anyone* is allowed to declare a
class non-cooperative (open or non-final) during *any* part of the
compilation
... even after it is declared final?
I
On Fri, 2005-04-15 at 11:21 -0500, Patrick R. Michaud wrote:
On Fri, Apr 15, 2005 at 09:17:13AM -0700, Larry Wall wrote:
Maybe we could define an ok operator that suppresses only the
*first* warning produced by its argument(s). Then if you get multiple
warnings, you at least get some
On Fri, 2005-04-15 at 23:52 +0200, Juerd wrote:
Well, after failure it can be cwd() but false without breaking any real
code, because normally, you'd never if (cwd) { ... }, simply because
there's ALWAYS a cwd.
Not always -- try removing a directory that's the pwd of another
process.
-- c
On Wed, 2005-03-30 at 18:35 -0500, Aaron Sherman wrote:
When the Perl 6 compiler sees:
my X $a;
$a.m(1);
What should it do?
Options:
* Accept the method call regardless of the definition of X
* Accept the method call if it matches the signature from X
On Mon, 2005-06-13 at 17:07 +0200, Ingo Blechschmidt wrote:
# No problem:
my $data = BEGIN {
my $fh = open some_file err...;
=$fh;
};
# Problem;
my $fh = BEGIN { open some_file err... };
# Compile-time filehandle leaked into runtime!
say =$fh;
Perhaps I'm being
On Sun, 2005-06-19 at 02:11 +0200, Juerd wrote:
Why exactly is the slash not acceptable for you? Almost everyone has
said they like it.
I find it ugly enough that I plan to name my invocants explicitly.
-- c
On Mon, 2005-06-20 at 12:11 +0200, Juerd wrote:
I think there exists an even simpler way to avoid any mess involved.
Instead of letting AUTOLOAD receive and pass on arguments, and instead
of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its
thing, and then have *perl* call
On Mon, 2005-06-20 at 16:37 -0600, Luke Palmer wrote:
On 6/20/05, chromatic [EMAIL PROTECTED] wrote:
Who says AUTOLOAD will always either call a loaded sub or fail?
Uh, what else can it do? It doesn't have to load a sub to return a
code reference.
I think:
class NullObject
{
sub
On Tue, 2005-06-21 at 13:35 +, Luke Palmer wrote:
I think people are being pretty closed-minded about closures.
I'm pretty closed-minded about writing code that does nothing to prevent
the language from doing the wrong thing by default. I already have a
fantastic way to write code that
there a two character
combination somewhere?
Poster 6: Shouldn't that be a module somewhere?
Poster 7: Shouldn't that be a macro?
chromatic: It's ugly. I'll never use it.
Damian: Good. That's the point.
chromatic: That was a straight line.
-- c
On Mon, 2005-07-11 at 15:16 +0200, Ingo Blechschmidt wrote:
Bar.new.isa(Object);# true
Bar.new.isa(Class); # false
Bar.new.isa(Foo); # true
Bar.new.isa(Bar); # true
I'd like to go on a tangent to suggest that anyone who uses .isa() in
actual real code ought to be
On Mon, 2005-07-11 at 17:47 -0400, Stevan Little wrote:
I actually agree with you on that. But I would like to clarify it to
say that:
Foo.isa(Bar) # Foo.meta.isa(Bar) || Foo.meta.does(Bar)
... meaning that the .isa() which is supposed to be aliased into the
class from .meta is
On Wed, 2005-07-13 at 17:33 -0400, David Storrs wrote:
What is a type besides a named blob of methods
and, possibly, data?
A label that says how the data is stored internally. For example,
compare Int and int. The former is a type and a blob of methods
and not necessarily
A12 and S12 describe introspection on objects and classes. The
metaclass instance has the method getmethods() which returns method
descriptors. The design specifies several traits queryable through
these descriptors.
Methods (and subroutines) can take other traits, such as is lvalue or
even
On Sat, 2005-07-23 at 20:41 -0700, Brent 'Dax' Royal-Gordon wrote:
Piers Cawley [EMAIL PROTECTED] wrote:
It seems to me, that the way to get at all the instances of a class is to
ask
the Garbage Collector to do the heavy lifting for us, and ideally I'd like
to
see this exposed at
On Sat, 2005-07-30 at 14:56 +0300, Gaal Yahas wrote:
(This introduces a potential semipredicate problem when looking at the
return value of a printed 0 or while not using fatal, but the
code can use a defined guard.)
I don't know if returning the printed string is the right approach, but
On Wed, 2005-08-17 at 23:43 -0500, Dave Rolsky wrote:
But I'd really like to get this stuff done at compile time wherever
possible. If I write this:
validate( credit_card_number: $number );
it should blow up at compile time, right?
Does that depend on how closed you want Perl 6 to
On Thu, 2005-09-08 at 14:59 -0700, Greg Woodhouse wrote:
I agree that simply using terms like this means indentation grammars
are problematic -- or does it? One thing that bothers me is that
*people* don't seem to have a great deal of difficulty with them. Why
not?
People can parse
On Mon, 2005-09-19 at 13:01 +0200, TSa wrote:
Why shouldn't there be a lvalue traversal that
in the end makes
($x, $y) = \($a, $b);
actually mean
$x = \$a; $y = \$b;
Does this not go from one sequence point (evaluate the rhs sufficiently,
then perform the lvalue assignments) to
On Wed, 2005-10-05 at 16:26 +0200, TSa wrote:
I recently wrote a Perl 6 design TODO, which was surprizingly small,
which enumerated the things to be done before I considered the design
of Perl 6 to be finished. Larry replied with a couple more items.
The type system is not on this list,
On Fri, 2005-10-07 at 12:49 +0200, Juerd wrote:
Ashley Winters skribis 2005-10-06 19:30 (-0700):
my Array $a = 97; # dies eventually, but when?
Runtime -- cannot coerce Int value to Array
It is fully determinable at compile time. 97 will never be compatible
with Array, so I see
On Fri, 2005-10-07 at 15:22 -0600, Luke Palmer wrote:
On 10/7/05, chromatic [EMAIL PROTECTED] wrote:\
If I added a multisub for Array assignment so that assigning an integer
value set the length of the array, would 97 be compatible with Array?
You're not allowed to overload assignment
On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote:
No, you can't overload assignment at runtime because you can't
overload assigment at any time, so says the language spec (well, not
any formal spec; so says Larry as far as I remember).
I'm wearing my just a programmer, not a denizen of
On Wed, 2005-10-12 at 12:00 -0400, Stevan Little wrote:
Usefulness aside, why do Roles and Classes need to be seperate
beasts? In the current meta-model prototype, the role system is laid
atop the class system so that the following is true:
Class is an instance of Class
Role is an
On Wed, 2005-10-12 at 21:50 +0200, Yuval Kogman wrote:
This has even more implications with closed classes to which you
don't have source level access, and if this can happen it will
happen - i'm pretty sure that some commercial database vendors would
release closed source DBDs, for example.
On Fri, 2005-10-14 at 02:18 +0200, Yuval Kogman wrote:
On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote:
Closed classes should not exist.
At least, they should only exist if the person *running* Perl 6 wants
them to exist -- never if merely the class writer wants to close them
On Thu, 2005-10-13 at 18:36 -0700, Chip Salzenberg wrote:
On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote:
I just don't want people who merely write a module or class to be
able to prevent people who actually use that module or class from
using, extending, or poking around
On Sat, 2005-10-15 at 12:45 -0500, Bryan Burgers wrote:
What I find exciting about parrot is that (it sounds like to me)
you'll be able to run a perl6 file anywhere that has parrot, much like
Java. I think what Markus is getting at is for there to be a way to
display graphics through parrot
On Tue, 2005-10-18 at 10:16 -0400, Stevan Little wrote:
On Oct 18, 2005, at 6:56 AM, Miroslav Silovic wrote:
Uhm. I'm not sure either. :) The way I read Larry's mail,
multimethods use .isa operator to detect whether $foo belongs to
Foo. And for every class, Foo.isa(Foo) is true (this
On Thu, 2005-10-20 at 10:32 -0500, Steve Peters wrote:
The idea of punishing programmers who choose to use certain operating system
or locales just doesn't seem right to me.
Haven't they already acclimated to the punishment of those operating
systems already?
-- c
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote:
I would prefer to use roles as they're closed by default, leaving
class to be my powertool, if I need the power.
I don't understand this desire; can you explain your reasoning?
(NB: closed here, as I use it, still *does not* correspond to
On Wed, 2005-10-26 at 19:22 -0600, Luke Palmer wrote:
But we find that many programmers make decisions that trade
readability and extensibility for an extra 1% of speed, even when they
are writing a command-line frontend to MPlayer[1]. If those people
are module writers, then we have a bunch
On Wed, 2005-10-26 at 14:52 -0400, Uri Guttman wrote:
LW == Larry Wall [EMAIL PROTECTED] writes:
LW One wants to coin a word like Qlass. Unfortunately qlass is
LW too easy to misread as glass. Oy veh, I'm getting notions of
LW the qlass is half empty for a partially instantiated
On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote:
Plus, the argument is a straw man. Instead of:
class Some::Class is also {
}
you would do:
class My::Version {
does Some::Class;
}
Problem solved.
Don't forget the fun of modifying all existing uses of
On Thu, 2005-10-20 at 17:12 -0700, Nate Wiger wrote:
If Perl 6 is going to be successful, this means it must change the
fewest key things with the most benefits.
I think there's an assumption here that not only do I not hold but I do
not even understand.
Suppose that I am a game developer
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the
On Thu, 2005-11-17 at 05:31 +0100, Daniel Brockman wrote:
This is a very valid concern, but the problem will not arise
unless people start mixing these two styles --- something
which is very obviously not a good idea.
That doesn't mean that people will avoid it, by accident or on purpose.
On Thu, 2005-11-17 at 07:27 +0100, Daniel Brockman wrote:
Yet you have the choice of where to put your braces, even
though the braces don't lend themselves to different tasks
depending on whether you put them on a new line or not.
You *don't* have the choice to use different types of braces,
1 - 100 of 193 matches
Mail list logo
