Re: Perl6 Test Suite
Hi, drakej wrote: I am looking to work on the test suite as part of the GSoC program. I have a couple of questions, though, if somebody could help me out: The ideas page (http://www.perlfoundation.org/perl5/index.cgi?gsoc_2010_projects) spoke of the IO section needing quite a bit more work, is this referring to S32 - IO, or I/O in general? To I/O in general. The TODO file in t/spec specified implementing tests for the filetest (:o, :R, :W, :X, etc.) methods. Could clues to that implementation be found in similar tests being used for Perl 5? Yes; in the Perl 5 source tree there are for example t/op/filetest.t t/op/stat.t t/io/*.t The S32-IO documents contain a huge amount of roles, which is probably way over-engineered, and is likely to change. On the other hand we are pretty sure that the open() function as shown in http://perlcabal.org/syn/S32/IO.html#IO will likely stay that way (or very similar). (Don't let that discourage you - Larry and I can tell you which parts we consider facts and which parts are speculations, so it should be easy to avoid testing things that are likely to go away). So if you consider writing up a gsoc proposal for IO testing, please focus more on the straight forward features (like file tests, open(), note(), printf() etc.) and less on the engineered part of S32::IO. It might also be wise to chose a second topic - 11 weeks writing tests for IO only might be boring, and I don't know if the specification already has enough firm facts for 11 weeks worth of tests. Cheers, Moritz
Perl6 Test Suite
Hello, I am looking to work on the test suite as part of the GSoC program. I have a couple of questions, though, if somebody could help me out: The ideas page (http://www.perlfoundation.org/perl5/index.cgi?gsoc_2010_projects) spoke of the IO section needing quite a bit more work, is this referring to S32 - IO, or I/O in general? The TODO file in t/spec specified implementing tests for the filetest (:o, :R, :W, :X, etc.) methods. Could clues to that implementation be found in similar tests being used for Perl 5? (I've poked around a bit on the pugs repository to see what is there but have not gotten a good look at Perl 5's tests yet.) Thanks for the help. Matthew
Re: You never have privacy from your children in Perl 6
Carl (), Moritz (), Carl (), Moritz (): masak um, so 'protected' is when the deriving classes can see the attribute? jonalv yup masak that's what 'private' means in Perl 6. That's wrong. Perl 6's private is like Java's private - subclasses can't see it. It's just Rakudo being leaky at the moment, not a fallacy of the Perl 6 language. (Yes, we have failing tests for this; no, we don't run them at the moment). That is indeed reassuring. Thank you. ...So, how come Perl 6 doesn't have a 'protected' access level? :) Exactly for the reasons you brought up against 'protected' as a default: in encourages people to inherit from a class just to bypass some of the public API. Yes, but 'protected' can still be useful in some delimited situations. I wasn't asking why it isn't the default -- I was wondering why it isn't there at all. The conversation we had on IRC (http://irclog.perlgeek.de/perl6/2010-03-23#i_2144261) seems to indicate that 'protected' can be emulated with the 'trusts' keyword... but that doesn't have any explicit support from the spec, and the 'trusts' keyword hasn't been realized in any Perl 6 implementation so far. // Carl
Re: You never have privacy from your children in Perl 6
Carl Mäsak wrote: Carl (), Moritz (), Carl (), Moritz (): masak um, so 'protected' is when the deriving classes can see the attribute? jonalv yup masak that's what 'private' means in Perl 6. That's wrong. Perl 6's private is like Java's private - subclasses can't see it. It's just Rakudo being leaky at the moment, not a fallacy of the Perl 6 language. (Yes, we have failing tests for this; no, we don't run them at the moment). That is indeed reassuring. Thank you. ...So, how come Perl 6 doesn't have a 'protected' access level? :) Exactly for the reasons you brought up against 'protected' as a default: in encourages people to inherit from a class just to bypass some of the public API. Yes, but 'protected' can still be useful in some delimited situations. I wasn't asking why it isn't the default -- I was wondering why it isn't there at all. The conversation we had on IRC (http://irclog.perlgeek.de/perl6/2010-03-23#i_2144261) seems to indicate that 'protected' can be emulated with the 'trusts' keyword... but that doesn't have any explicit support from the spec, and the 'trusts' keyword hasn't been realized in any Perl 6 implementation so far. I seem to recall that Pugs did support 'trusts' a few years ago, and that I used it. But I could be wrong. -- Darren Duncan
Re: You never have privacy from your children in Perl 6
Carl (), Darren ():
[...] and the
'trusts' keyword hasn't been realized in any Perl 6 implementation so
far.
I seem to recall that Pugs did support 'trusts' a few years ago, and that I
used it. But I could be wrong. -- Darren Duncan
I stand corrected. A quick search through the Pugs sources shows that
Pugs at least parses the 'trusts' declaration.
I didn't get it to trust me, though:
masak pugs: class A { has $!foo }; class B { trusts A; method bar(A
$a) { say $a!foo } }; B.new.bar(A.new(:bar(42)))
p6eval pugs: OUTPUT«»
Either it bitrotted or I'm using it wrong.
// Carl
Re: You never have privacy from your children in Perl 6
Carl Mäsak wrote:
Carl (), Darren ():
[...] and the
'trusts' keyword hasn't been realized in any Perl 6 implementation so
far.
I seem to recall that Pugs did support 'trusts' a few years ago, and that I
used it. But I could be wrong. -- Darren Duncan
I stand corrected. A quick search through the Pugs sources shows that
Pugs at least parses the 'trusts' declaration.
I didn't get it to trust me, though:
masak pugs: class A { has $!foo }; class B { trusts A; method bar(A
$a) { say $a!foo } }; B.new.bar(A.new(:bar(42)))
p6eval pugs: OUTPUT«»
Either it bitrotted or I'm using it wrong.
You're using it wrong. You need to put 'trusts B;' in A in order for B to see
A's privates. I hope it is obvious why this is the case. -- Darren Duncan
