On 12/10/2005, at 3:33 PM, Luke Palmer wrote:
On 10/11/05, Alfie John [EMAIL PROTECTED] wrote:
Does Perl6 support multiline comments?
Yes, in the form of pod blocks.
=begin comment
=end comment
They nest, too.
Luke
But does that then break my lovely formatted pod like it does in
On 12/10/2005, at 4:18 PM, Mark A. Biggar wrote:
Alfie John wrote:
Hi (),
This is probably a stupid question, but I can't find anything
from google:
Does Perl6 support multiline comments?
Briefly, No and kind of.
Standard Perl 6 comments are just like those in Perl 5. A '#'
starts
On 10/12/05, Alfie John [EMAIL PROTECTED] wrote:
On 12/10/2005, at 3:33 PM, Luke Palmer wrote:
=begin comment
=end comment
But does that then break my lovely formatted pod like it does in Perl5?
Try this:
% cat dosomething.pl
=head1 TITLE
Thingy - do something
=head1 DESCRIPTION
=over
On Tue, Oct 11, 2005 at 06:10:41PM -0400, Stevan Little wrote:
I would like to propose that class methods do not get inherited along
normal class lines.
You mean, make them *not methods?* Because it's not a method unless it
has an invocant, as far as I'm concerned. (Method implies
Stevan Little [EMAIL PROTECTED] writes:
Hello all.
I would like to propose that class methods do not get inherited along
normal class lines.
I think that inheriting class methods will, in many cases, not DWIM.
This is largely because your are inheriting behavior, and not state
(since
Alfie John skribis 2005-10-12 15:28 (+1000):
Does Perl6 support multiline comments?
All incarnations of Perl have allowed us to begin multiple subsequent
lines with the comment glyph '#'. I am sure Perl 6 will not break this
tradition.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
Gordon,
On Oct 11, 2005, at 9:10 PM, Gordon Henriksen wrote:
On Tue, Oct 11, 2005 at 06:10:41PM -0400, Stevan Little wrote:
I would like to propose that class methods do not get inherited along
normal class lines.
You mean, make them *not methods?* Because it's not a method unless it
has an
Piers,
On Oct 12, 2005, at 5:22 AM, Piers Cawley wrote:
We definitely have two instances of A since, B.isa(::A). We also have
a fragile implementation of count.
:)
Sorry, I purposefully made it a kludge as that is usually the way the
example is shown in most tutorials about class methods.
Gordon,
It just occurred to me that the system shown below could be re-
written to do away with class methods entirely.
class Host {
my $.plugInClass;
}
role PlugIn {
method initWithHost (Host $h:) { ... }
}
role FeatureA {}
role FeatureB {}
role FeatureC {}
class AB {
does
Larry,
On Oct 11, 2005, at 8:47 PM, Larry Wall wrote:
On Tue, Oct 11, 2005 at 06:10:41PM -0400, Stevan Little wrote:
: Hello all.
:
: I would like to propose that class methods do not get inherited
along
: normal class lines.
I think most class methods should be written as submethods
Gordon,
On Oct 12, 2005, at 10:48 AM, Gordon Henriksen wrote:
Actually, I wondered why you didn't suggest this earlier. :) I
figured you were a step ahead of me: What if I want more than a
boolean out of my class method?
Then you put the class methods back in :)
But then your Objective-C
Gordon,
On Oct 12, 2005, at 11:04 AM, Gordon Henriksen wrote:
On Oct 12, 2005, at 09:41, Stevan Little wrote:
If you use the BUILD submethod, then you never need to worry about
a that, everything is initialized for you by BUILDALL. Now, if you
want to have a constructor which accepts
--- Piers Cawley [EMAIL PROTECTED] wrote:
How about:
my method SCALAR::attributes($self:) { $$self }
my method HASH::attributes(%self:) { %self.kv }
my method ARRAY::attributes(@self:) { [EMAIL PROTECTED] }
method _attributes($attrs) {
my @attributes = $attrs.attributes
Hi,
TSa wrote:
Ingo Blechschmidt wrote:
Exactly. I'd like to add that, under the proposal, you always know
what things are passed how, only by looking for a *.
foo $var;# always positionally, even if $var isa Pair
foo *$pair; # always named
But where is the name? Is it
On Oct 12, 2005, at 09:41, Stevan Little wrote:
If you use the BUILD submethod, then you never need to worry about
a that, everything is initialized for you by BUILDALL. Now, if you
want to have a constructor which accepts positional arguments
rather than named pairs (as the default does),
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
Okay, I seriously have to see an example of a submethod in use. BUILD
etc. don't count. Why? Because:
class Foo {
method BUILD () { say foo }
}
class Bar is Foo {
submethod BUILD () { say bar }
}
class Baz is Bar { }
Foo.new; # foo
Bar.new; #
Actually, I wondered why you didn't suggest this earlier. :) I
figured you were a step ahead of me: What if I want more than a
boolean out of my class method?
On Oct 12, 2005, at 10:27, Stevan Little wrote:
Gordon,
It just occurred to me that the system shown below could be re-
written
Luke wrote:
Okay, I seriously have to see an example of a submethod in use.
class Driver::Qualified {
method drive {
print Brrrm brrrm!
}
}
class Driver::Disqualified is Driver {
submethod drive {
die .name(), not allowed to drive
On Thu, Oct 13, 2005 at 05:42:31 +1000, Damian Conway wrote:
Luke wrote:
Okay, I seriously have to see an example of a submethod in use.
class Driver::Qualified {
method drive {
print Brrrm brrrm!
}
}
class Driver::Disqualified is Driver
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.
Hi all,
Is it intentional that S09 lists unboxed complex types, but equivalent
Boxed types are missing from the Types section in S06?
Sam.
On 10/12/05, chromatic [EMAIL PROTECTED] wrote:
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
On Thu, Oct 13, 2005 at 09:43:15AM +1300, Sam Vilain wrote:
: Hi all,
:
: Is it intentional that S09 lists unboxed complex types, but equivalent
: Boxed types are missing from the Types section in S06?
Nope.
Larry
Larry Wall wrote:
On Thu, Oct 13, 2005 at 09:43:15AM +1300, Sam Vilain wrote:
: Hi all,
:
: Is it intentional that S09 lists unboxed complex types, but equivalent
: Boxed types are missing from the Types section in S06?
Nope.
As it's a trivial omission, I went ahead and changed S06.pod
On 10/12/05, Rob Kinyon [EMAIL PROTECTED] wrote:
Plus, I can't imagine that a reverser for Parrot code is going to be that
hard to
write.
Disassembling register machine code is significantly more difficult
than disassembling stack machine code.
That said, if the level of introspective
It was just kind of a pain because you
had to put a =cut after the =end, and because you had to put
paragraph spaces between everything. We're getting rid of both of
those restrictions.
Excellent! That's what was really bugging me. I'm really glad that is
changing :)
Thanks,
Alfie
Stevan Little [EMAIL PROTECTED] wrote:
I would like to propose that class methods do not get inherited along
normal class lines.
I think you're not thinking about many major usage cases for class methods.
For one example, look at my Cipher suite. (It's in Pugs's ext/Cipher
directory.) The
All -
I'm partly to blame for this thread because I put the idea into
Steve's head that class methods being inheritable may be dogma and not
a useful thing. Mea culpa.
That said, I want to put forward a possible reason why you would
want class methods to be inheritable - to provide pure
Brent,
On Oct 11, 2005, at 8:17 PM, Brent 'Dax' Royal-Gordon wrote:
Stevan Little [EMAIL PROTECTED] wrote:
I would like to propose that class methods do not get inherited along
normal class lines.
I think you're not thinking about many major usage cases for class
methods.
Actually I
30 matches
Mail list logo
