Role Method Conflicts and Disambiguation
Rob Kinyon wrote: > > 1. choose one of a set of available methods to call its own. > > 2. create a version of its own. > > 3. pass the buck. > > #1 and #2 are identical. Stevan and I have always viewed #1 as a > special case of #2. If you want to choose a method to call, then > create a method of your own and have it wrap the one you want to call. > > The benefit here is that you can do more than just pick a method. > Let's say that you have a conflict and the correct behavior is to do > them all, but in a certain way. Or, maybe the correct behavior is to > provide a limited API over one version. > > Maybe, there'll be some sugar to allow #1 to be its own syntax, but it > should be viewed as a #2. You're right. But this obscures the point that I was trying to make: we need to decide what set of methods are available when disambiguating. Is the DOESA list public or private? Should the role be able to look up any public method that any of its ancestors have, or should it be restricted to just the methods that its parent roles have? Given the flattened nature of composition, I feel that the latter is more appropriate. -- Jonathan "Dataweaver" Lang
Re: Role Method Conflicts and Disambiguation
> 1. choose one of a set of available methods to call its own. > 2. create a version of its own. > 3. pass the buck. #1 and #2 are identical. Stevan and I have always viewed #1 as a special case of #2. If you want to choose a method to call, then create a method of your own and have it wrap the one you want to call. The benefit here is that you can do more than just pick a method. Let's say that you have a conflict and the correct behavior is to do them all, but in a certain way. Or, maybe the correct behavior is to provide a limited API over one version. Maybe, there'll be some sugar to allow #1 to be its own syntax, but it should be viewed as a #2. Rob
Devel::Cover not DWIMming on upgraded Perl -- but problem solved
When I began to write this posting, it was to get an answer to a question. But I figured out a workaround halfway through, so now I'm posting an answer. I have happily been using Devel::Cover for more than a year on Perl 5.8.4 on Darwin (Mac OS X 10.3). Recently I upgraded to Perl 5.8.7. Tonight I went to use Devel::Cover (v0.55, as previously) for the first time since that Perl upgrade. At first, it no longer DWIMmed. Specifically: 1. When I ran 'make test HARNESS_PERL_SWITCHES=MDevel::Cover', I got this message: t/01_test.. This version of Devel::Cover was built with Perl version 5.008004. It is now being run with Perl version 5.008007. Attempting to make adjustments, but you may find that some of your modules do not have coverage data collected. You may need to alter the +-inc, +-ignore and +-select options. t/01_test..ok I'd never had to set these options before; previously, D::C just worked. Also, D::C took much longer to run. 2. I was testing coverage of a new module I'm developing called File::Save::Home. When I called 'cover', I got a report on this module, but also on every core module as well: [snip] -- -- -- -- -- -- -- File stmt bran condsubpod time total -- -- -- -- -- -- -- ...perl5/5.8.7/AutoLoader.pm0.00.00.00.00.0 n/a0.0 ...l/lib/perl5/5.8.7/Carp.pm0.00.00.00.00.0 n/a0.0 ...erl5/5.8.7/Digest/base.pm0.00.0n/a0.00.0 n/a0.0 ...b/perl5/5.8.7/Exporter.pm 50.0 57.1 44.7 33.30.0 0.3 44.8 ...5/5.8.7/Exporter/Heavy.pm 10.48.8 12.5 11.10.0 0.19.8 ...l5/5.8.7/File/Basename.pm 28.2 25.87.7 50.0 100.0 0.1 27.8 [snip] 8.7/warnings/register.pm 100.0 50.0n/a 100.00.0 0.1 89.5 blib/lib/File/Save/Home.pm 77.1 44.4n/a 100.0 100.0 0.3 73.4 Total 10.86.24.3 12.3 14.0 100.09.0 -- -- -- -- -- -- -- Writing HTML output to /Users/jimk/work/fsh/File-Save-Home/cover_db/coverage.html ... done. This problem of excessive output is the same one I typically experience using D::C (v0.47, I believe) on Windows. This is much more output than I want or need. I hypothesized that if I were to upgrade to a new version of D::C, it would be compiled against Perl 5.8.7 and these problems might go away. But 'cpan' did nothing because it detected that I was using the most recent version of D::C. So I downloaded the latest version of Devel::Cover from CPAN and installed it manually. (I did call 'make install UNINSTALL=1'.) This solved the problem. The message described above went away, and 'cover' reported only the results for the module under development. Jim Keenan
Re: Role Method Conflicts and Disambiguation
On 11/1/05, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> In the third case, I'd be inclined to say that passing the buck is
> equivalent to creating an undefined version of your own - that is, not
> addressing a conflict involving method x is equivalent to saying
> "method x ($arg) { ... }". IOW, a class that does a role that passed
> the buck is faced with an "undefined method" complaint if it doesn't
> do something about it, not an "unresolved conflict" complaint.
Well, I think that the two are pretty much the same thing. I mean,
you have to do the same thing to fix it: define your own version.
Given that, it's probably best to call it "unresolved conflict", so
people don't stare at the role they are including and its definition
of the method and yell at the compiler "IT'S RIGHT THERE!". It's just
an error message issue.
Luke
Re: Role Method Conflicts and Disambiguation
Yuval Kogman wrote:
> Stevan Little wrote:
> > If we allow the class to decide if things break or not, then we
> > potentially allow for the system to be in a very unstable state. A
> > method conflict means that neither method gets consumed, and at
> > that point we have a gapping hole in our class.
>
> And compilation will not finish unless the class plugs the hole...
>
> role a;
> role b;
> role c does a does b;
> class d does c;
>
> If there is a conflict at c, it might be a conflict that c knows how
> to resolve, or it might be a conflict that c's documentation says
> the user has to decide on, depending on what they prefer.
>
> What I'm saying is that the hole in c can be consumed by d, and if
> it isn't plugged in either c or d, you get an error.
True enough; but it needn't be true that d have the same tools
available to resolve the conflicts that c has.
There are three ways that a role can deal with a conflict:
1. choose one of a set of available methods to call its own.
2. create a version of its own.
3. pass the buck.
In the first case, the question is how we define the set of available
methods: do we make the full hierarchy of ancestors available to the
role, or do we say that only the immediate parents are available?
Another way to put this would be: should the "DOESA" list be treated
as public or private? (My preference: the "DOESA" list should be
private. You don't lose any capabilities by doing so, other than the
capability to access stuff not explicitly declared - a capability that
roles don't need, and probably shouldn't have.) If "DOESA" is
private, then d won't have access to anything from a or b without
explicitly including them in its own DOESA list. This seems to be
restrictive, and it is - but only in the same way that making an
attribute private is restrictive.
The second case is pretty straightforward.
In the third case, I'd be inclined to say that passing the buck is
equivalent to creating an undefined version of your own - that is, not
addressing a conflict involving method x is equivalent to saying
"method x ($arg) { ... }". IOW, a class that does a role that passed
the buck is faced with an "undefined method" complaint if it doesn't
do something about it, not an "unresolved conflict" complaint.
--
Jonathan "Dataweaver" Lang
Re: Apache-Test and Devel::Cover
> Nice work, Geoff :) > > A few issues: > > 1) > > % make testcover > Cannot run testcover action unless Devel::Cover is installed > > and after installing Devel::Cover it still gives the same error, since > it's hardcoded in Makefile.PL. May be adding a check and suggesting to > rebuild Makefile if Devel::Cover is now installed? ok. > > 2) at the end of run it gives: > > All tests successful, 1 test skipped. > Files=7, Tests=22, 140 wallclock secs (134.28 cusr + 5.51 csys = 139.79 > CPU) > server localhost:8529 shutdown > make[1]: Leaving directory `/home/stas/apache.org/Apache-Test' > make: cover: Command not found > make: [testcover] Error 127 (ignored) > > I don't use a standard perl, so 'cover' is not in the path. So it should > probably do which(cover) and run it only then? Also could check the > directory perl lives and add that to PATH, since that's where 'cover' > lives if not installed global-wise. I don't use a standard perl either, so cover is one of those things I need to add to my path. really, I'm not sure how much I want to run through hoops for people wrt stuff like this - if you're a developer and you care about coverage you have Devel::Cover (and its components) installed and ready for use, otherwise you don't. almost nobody will be running testcover who doesn't have things installed properly, so I'm not sure it makes too much sense to go poking around looking for stuff. > > 3) > > I do get segfaults and they are quite inconsistent. Even on > Apache-Test's test suite. Of course this probably has nothing to do with > your work, since have happened before as well. I wonder whether > Devel::Cover is just as unstable under plain perl. under plain perl it works out very nicely. I think something about the embedded perl environment is causing problems. actually, until a recent version (0.48 IIRC) it didn't work under mod_perl at all. my own personal experience wrt mod_perl is that it seems to work ok with mp1. the mp2 + Devel::Cover combination behaves very erratically, but I have better luck with unthreaded perls and prefork than threaded perls (and horrible results with worker, if it works at all which I don't think it does). but we're getting closer each time, and paul has been outstanding creating D::C at all, so there's not much to complain about :) --Geoff
PGE problem with non-greedy quantifiers
On a grammar that worked in a recent version of PGE, I'm now getting
an error when I try to construct the grammar. The error disappears
when I eliminate all non-greedy quantifiers from the grammar (though,
of course, the constructed grammar parses the text incorrectly with
greedy quantifiers).
This is the error:
p6rule parse error: Error in closure quantifier
current instr.: 'PGE::P6Rule :: parse_error' pc 7074 (compilers/pge/
PGE/Exp.pir:663)
called from Sub 'PGE::P6Rule :: parse_quant' pc 6516 (compilers/pge/
PGE/Exp.pir:663)
called from Sub 'PGE::OPTable :: parse' pc 1412 (compilers/pge/PGE/
Exp.pir:113)
called from Sub 'PGE::Rule :: p6rule' pc 7093 (compilers/pge/PGE/
Exp.pir:663)
called from Sub 'PGE :: p6rule' pc 7151 (compilers/pge/PGE/Exp.pir:663)
called from Sub 'LAG::Parser :: _load' pc 50 (PGE.pir:30)
called from Sub '_main' pc 3 (PGE.pir:22)
The error is thrown from the "parse_quant" subroutine on line 226 of
PGE/P6Rule.pir (under the label "err_closure"), but I'm not sure
whether it's jumping to the "err_closure" label from line 196, 199,
211, or 217 of that file.
The grammar I'm working with is:
http://svn.lohutok.net/nam/trunk/parrot/modules/Language/
AttributeGrammar/lib/LAG/Parser.pir
And the test script I'm loading it from is:
http://svn.lohutok.net/nam/trunk/parrot/modules/Language/
AttributeGrammar/testparse.pir
One example rule with the problem:
p6rule('\( \s* (.*?) \s* \)\s*', classname, 'parenlist')
This rule parses fine if I delete the "?".
Also, the README file in compilers/pge needs to be updated to reflect
the fact that the "dump" method is gone (replaced by dumper.imc).
Allison
[perl #37578] [TODO] PIR - simple register allocation
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #37578] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37578 > >From a discussion earlier today on #irc... It would be nice if the PIR compiler had a way to use a very basic register allocation algorithm for .subs that use only a small number of registers. As I understand the current state of things, the PIR compiler performs a fairly complex analysis of a sub's control flow in order to make optimal use of registers in the sub. For long subs with lots of branches and control structures, this analysis can take a very long time... and may be unnecessary if the sub is using only a small number of named and temporary registers. If the number of named and temporary registers in a sub is small (for suitably values of "small"), the compiler can avoid the control flow analysis altogether by simply allocating registers for each .local, .param, or temporary register encountered and leaving those fixed for the life of the .sub. As a real-world instance of this, the PIR-code subroutines produced by PGE have the potential to become very long and contain a large number of control-flow statements, but use a maximum of 10 pmc, 9 int, and 4 string registers for the entire sub. (In the long run PGE may emit code using something other than PIR, but this is what we're doing for now.) The PIR compiler could be set to automatically detect the number of register used in a sub and then decide the register allocation method to use. Or, to simplify implementation, perhaps the choice of register allocation could be provided as an :option of some sort in the .sub line. I don't know enough about the PIR compiler internals to make this happen myself, which is why I'm submitting this as a TODO ticket (at Leo's request). Thanks, Pm
[perl #37577] [PATCH] Fix a couple of minor niggles (-1 -> uint, K&R prototype)
# New Ticket Created by Nick Glencross
# Please include the string: [perl #37577]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37577 >
This patch fixes two classes of issue.
* Don't assign -1 to an unsigned variable; use ~0U instead as it
makes it clear that the value is intended to be out-of-band (g++
warned about this, and C compilers will increasingly)
* Change a K&R prototype in a config test
Regards,
Nick
Index: src/debug.c
===
--- src/debug.c (revision 9682)
+++ src/debug.c (working copy)
@@ -225,7 +225,7 @@
/* Nonempty and did not start with a letter */
if (c == 0)
-c = -1;
+c = ~0U;
*cmdP = c;
Index: src/string_primitives.c
===
--- src/string_primitives.c (revision 9682)
+++ src/string_primitives.c (working copy)
@@ -351,7 +351,7 @@
Parrot_char_digit_value(Interp *interpreter, UINTVAL character)>
Returns the decimal digit value of the specified character if it is a decimal
-digit character. If not, then -1 is returned.
+digit character. If not, then ~0U is returned.
Note that as currently written, C can
correctly return the decimal digit value of characters for which
@@ -369,7 +369,7 @@
#else
if ((character >= 0x30) || (character <= 0x39))
return character - 0x30;
-return -1;
+return ~0U;
#endif
}
Index: src/inter_create.c
===
--- src/inter_create.c (revision 9682)
+++ src/inter_create.c (working copy)
@@ -125,7 +125,7 @@
create_initial_context(interpreter);
interpreter->resume_flag = RESUME_INITIAL;
/* main is called as a Sub too - this will get depth 0 then */
-CONTEXT(interpreter->ctx)->recursion_depth = -1;
+CONTEXT(interpreter->ctx)->recursion_depth = ~0U;
interpreter->recursion_limit = 1000;
/* Must initialize flags here so the GC_DEBUG stuff is available before
Index: src/pmc_freeze.c
===
--- src/pmc_freeze.c(revision 9682)
+++ src/pmc_freeze.c(working copy)
@@ -1051,7 +1051,7 @@
id += arena->total_objects;
}
internal_exception(1, "Couldn't find PMC in arenas");
-return -1;
+return ~0U;
}
#else
@@ -1089,7 +1089,7 @@
}
internal_exception(1, "Couldn't find PMC in arenas");
-return -1;
+return ~0U;
}
#endif
Index: config/auto/alignptrs/test_c.in
===
--- config/auto/alignptrs/test_c.in (revision 9682)
+++ config/auto/alignptrs/test_c.in (working copy)
@@ -10,7 +10,7 @@
#include
/* Try to catch bus errors */
#ifdef SIGBUS
-void bletch(s) int s; { exit(1); }
+void bletch(int s) { exit(1); }
#endif
int main(int argc, char **argv) {
Re: Heredocs in function calls?
On Tue, Nov 01, 2005 at 11:48:34AM +, Nicholas Clark wrote: > On Tue, Nov 01, 2005 at 01:45:10AM -0600, Patrick R. Michaud wrote: > > > but I'm not a fan of writing the $S0 variables -- they seem to distract > > the code. I may just go with something like > > > > code .="lastpos = length target" > > code .="gpad = new PerlArray" > > code .="rcache = new PerlHash" > > code .="captscope = mob" > > emit(code, "bsr %s", label) > > > > which at least changes the first four to be parrot ops instead > > of function calls for each. > > If this is the code that you're generating, what stops your code generator > from doing the concatenation itself, and generating an "unreadably" long > line? Hmmm, I'm not sure I understand the question here, but since my original example was incorrect (missing newlines) I'll try again... I could do .local pmc code code = new String ... code .="lastpos = length target\n" code .="gpad = new PerlArray\n" code .="rcache = new PerlHash\n" code .="captscope = mob\n" emit(code, "bsr %s", label) Lines like the above are written directly into PGE itself (in PGE/Exp.pir), are the lines that do the generating (as opposed to being code that is generated...). Writing all of those \n's is a bit of a pain to type, but I guess I can do so at some point. Or maybe I'll just go with a string+heredoc syntax for long sequences of code, and leave the individual emit calls for shorter ones. Thanks, Pm
Apache-Test and Devel::Cover
hi all :) I just commited a patch to Apache-Test in svn that removes all the additional work involved with getting Devel::Cover to work for server side tests. now a simple 'make testcover' should be all you need to do to get coverage results from code within handler() subroutines - no more adding modperl_extra.pl entries or other associated foo. so, for the few here interested in this kind of thing, I'd like to hear people's test results for completeness sake. on my own system (which is slowly dying), I get random core dumps and Devel::Cover failures both in the way I used to do it and the way it works now, so in that sense things work out "the same." but if other people who used to have stuff working now have increased problems I'd love to hear about it. but hopefully all this patch does is lower the barrier to getting coverage in the apache world. for those not terribly svn savvy, you can get Apache-Test from svn like so $ svn checkout \ > http://svn.apache.org/repos/asf/perl/Apache-Test/trunk Apache-Test thanks, and enjoy. --Geoff
Re: First (developers) Release of Test::Shlomif::Harness
Hi Michael! Thanks for your commentary. On Monday 10 October 2005 23:27, Michael G Schwern wrote: > On Mon, Oct 10, 2005 at 10:53:34PM +0200, Shlomi Fish wrote: > > Let me know what you think. > > $ perl -Ilib -wle 'use Test::Shlomif::Harness::Obj; > Test::Shlomif::Harness::Obj->new->runtests(test_files => [EMAIL PROTECTED])' > t/*.t > Can't use an undefined value as an ARRAY reference at > lib/Test/Shlomif/Harness/Obj.pm line 715. > > runtests() is not doing anything with its arguments and neither is > _run_all_tests() so $self->test_files is undefined. It was a documentation problem. The current syntax is: my $tester = Test::Shlomif::Harness::Obj->new( 'test_files' => [EMAIL PROTECTED], ); $tester->runtests(); > In fact, there's a > few places where you code waffles between getting information from the > object and from its arguments. _leader_width, for example, gets its > test_files from its arguments even though it should be available on the > object. Yes, I initially thought it might be a good idea to make it able to calculate the width of other test file collections except its own. But since it's a private method (that has a leading underscore), then I guess I can avoid it. > > Moving along, here's what happens on a simple test failure. > > $ perl -Ilib -wle 'use Test::Shlomif::Harness::Obj; $t = > Test::Shlomif::Harness::Obj->new; $t->test_files([EMAIL PROTECTED]); > $t->runtests()' > t/fail.t t/failNOK 1 # Failed test in t/fail.t at line 4. > # Looks like you failed 1 test of 1. > t/faildubious > Test returned status 1 (wstat 256, 0x100) > DIED. > Undefined format "STDOUT" called at lib/Test/Shlomif/Harness/Obj.pm line > 842. > > It appears all that nasty format code that we hate in Test::Harness has > gone missing yet _fail_other() still tries to use it. > Fixed now. I first restored the formats, then gradually refactored the code to eliminate them. Available now as: http://download.berlios.de/web-cpan/Test-Shlomif-Harness-0.0100_03.tar.gz > > The way you've broken down the nattier bits of Test::Harness, such as > _show_results(), into digestable functions has value. > I'd like to see > that sort of thing as patches to Test::Harness rather than in a fork. Well, I started with Test::Harness and gradually revamped it. The problem is that some aspects of the T::H interface suck, and I had to change the interface in a non-backwards-compatible way. Thanks again. Regards, Shlomi Fish > Also using an object *internally* makes sense. Cleans up having to pass > %tot and %test around all over. An external object interface will require > a lot more thought. > > > -- > Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern > Ahh email, my old friend. Do you know that revenge is a dish that is best > served cold? And it is very cold on the Internet! -- - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: "All tests successful" considered harmful
chromatic <[EMAIL PROTECTED]> writes: > On Thu, 2005-10-27 at 10:26 -0700, jerry gay wrote: > >> we're missing some parts of a testing framework. we don't have the >> ability to write test files in PIR, so we're dependent on a perl >> install for testing. perl's a great language for writing tests anyway, >> and right now we're dependent on perl for parrot's configure and build >> as well. that said, breaking this dependency will make parrot just a >> bit closer to standing on its own. > > We have a Test::Builder port in PIR. I will move up my plan to port > Parrot::Test to use it. Somewhere I have the beginnings of an xUnit style 'parrotunit' testing framework, but that was written ages ago, so I'd need to start it again, but it wasn't that hard to implement. -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/
Re: Heredocs in function calls?
On Tue, Nov 01, 2005 at 01:45:10AM -0600, Patrick R. Michaud wrote: > but I'm not a fan of writing the $S0 variables -- they seem to distract > the code. I may just go with something like > > code .="lastpos = length target" > code .="gpad = new PerlArray" > code .="rcache = new PerlHash" > code .="captscope = mob" > emit(code, "bsr %s", label) > > which at least changes the first four to be parrot ops instead > of function calls for each. > > Any other thoughts or suggestions? If this is the code that you're generating, what stops your code generator from doing the concatenation itself, and generating an "unreadably" long line? Nicholas Clark
Heredocs in function calls?
Out of curiosity, might there be any convenient way to support heredoc parameters in PIR function calls? (I suspect the answer is "no", but thought I'd ask just in case.) Currently PGE builds code to be compiled by emitting a sequence of function calls, each call appends another line of output to a string pmc. Of course, each of these calls takes some amount of overhead, and it might be nice if instead of writing emit(code, "lastpos = length target") emit(code, "gpad = new PerlArray") emit(code, "rcache = new PerlHash") emit(code, "captscope = mob") emit(code, "bsr %s", label) one could instead write: emit(code, <<"CODE", label) lastpos = length target gpad = new PerlArray rcache = new PerlHash captscope = mob bsr %s CODE thus converting the five emit statements into one. Yes, I know I can do $S0 = <<"CODE" ... CODE emit(code, $S0, label) but I'm not a fan of writing the $S0 variables -- they seem to distract the code. I may just go with something like code .="lastpos = length target" code .="gpad = new PerlArray" code .="rcache = new PerlHash" code .="captscope = mob" emit(code, "bsr %s", label) which at least changes the first four to be parrot ops instead of function calls for each. Any other thoughts or suggestions? Pm
PGE improvements and changes
I just wanted to send a quick note to perl6-internals and perl6-compiler that I've just checked in some major changes to the PGE internals (r9681). Last week we added a shift-reduce operator precedence parser, this version uses that parser to parse perl 6 rules, which should improve the parsing speed a fair bit. It also simplifies the code somewhat. On the other hand, I haven't migrated all of the various optimizations across yet, so the compiled routines will probably run slightly slower, but when those come across things ought to improve again. (I'm still looking for people to do some benchmarking, if there are any takers!) And although I ran the various test suites and a few other tests, there are certainly some things that don't work the same as before. Let me know about them and we'll get them fixed right away. This version adds a that can be used to parse a valid Perl 6 rule. (As one might expect, matching something against returns the parse tree as a Match object.) This version also allows grammars to define custom rules to be used in place of the default rule used for whitespace metacharacters. And the :words modifier now works along with the :w modifier. There are quite a number of other changes in this version or that will appear in the next couple of days, so I'll send a followup email with more details soon. Until then, questions, comments, patches, and tests are greatly appreciated! Pm
Re: Role Method Conflicts and Disambiguation
On Fri, Oct 28, 2005 at 14:19:46 -0400, Stevan Little wrote:
> Yuval,
>
> On Oct 28, 2005, at 10:59 AM, Yuval Kogman wrote:
> >On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
> >>Now, at this point we have a method conflict in suspension since
> >>(according to A/S-12) method conflicts do
> >>not throw an error until a role is composed into a class. This means that
> >>when I do this:
> >>class MyClass does FooBar {}
> >>an exception is thrown. Unless of course MyClass has a &foo method, which
> >>will disambiguate the conflict.
> >>My question then is, can FooBar (the role) disambiguate the &foo conflict?
> >IMHO yes, but it doesn't have too. It should be able to leave it to
> >the class to decide.
>
> If we allow the class to decide if things break or not, then we
> potentially allow for the system to be in a very unstable state. A
> method conflict means that neither method gets consumed, and at
> that point we have a gapping hole in our class.
And compilation will not finish unless the class plugs the hole...
role a;
role b;
role c does a does b;
class d does c;
If there is a conflict at c, it might be a conflict that c knows how
to resolve, or it might be a conflict that c's documentation says
the user has to decide on, depending on what they prefer.
What I'm saying is that the hole in c can be consumed by d, and if
it isn't plugged in either c or d, you get an error.
I think it's useful from a role perspective, because that way you
can let the user decide on some conflicts.
While I can't think of an example, I don't think there is much risk
- this doesn't take away functionality. The only issue is that you
can compile a role with a conflict and it doesn't complain till you
actually use the role (this should be taken care of by writing the
simplest of tests for your role). It does open doors for higher
complexity composition. Especially if you have a deep hierarchy of
role consumption:
a b c d
\ / \ /
e f
\- g -/
(role g does e does f, e does a, does b...)
Let's say that a and b conflict at 2 points. E can resolve one of
them, and leave the other one for g to decide.
Perhaps methods in f are used to resolve e with dynamic dispatch:
role g does e does f {
method conflicts_in_a_and_b ($arg) {
given .method_from_role_f($arg) {
when Condition { .a::conflicts_in_a_and_b($arg)
}
defualt { .b::conflicts_in_a_and_b($arg) }
}
}
}
This is, IMHO legitimate use.
The only restriction should be that when runtime begins no class (or
anything that can be instantiated) is allowed to still have a
conflict.;
> >>In the end, we will have probably looked inside every method defined in
> >>Foo, Bar, FooBar and Baz in order
> >>to properly write MyClass2. IMHO, this is sort of defeating the
> >>usefulness of roles at this point.
> >I disagree - you have to know what a role is actually giving you to
> >exploit it. Too much black boxing makes your programming language
> >seem like a Kafka story.
>
> Why? does it introduce bugs? ;-P
If you can't see at all into the code you use you eventually run
into problems like the "shlemiel the painter" algorithm for C
strings (google to find refs for that, too long to explain here).
Frequently when using library code whose documentation is not
perfect (and in opensource almost no documentation is ever perfect)
I have a great privilige - search.cpan.org has a one click path to
seeing the source code of any module i'm considering to install.
This allows me to see how something works, estimate how hard it will
be to extend it if the need should arise, assess the quality of the
code, and make sure I understood things correctly.
This spirit of openness should be maintained. You don't have to take
apart a role and recompose it and what not, breaking encapsulation.
But you should be able to fudge it slightly, because the author of
the role might not be getting paid to fix it to your needs, and you
may have to get slightly hackish.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!
pgpcm9H3z1CWi.pgp
Description: PGP signature
