RE: Class::FakeAttributes -- Opinions Wanted
Title: RE: Class::FakeAttributes -- Opinions Wanted
* Orton, Yves [EMAIL PROTECTED] [2003-11-03 17:27]:
Thats because the apporach you are comparing it to is flawed.
foreach (@{$self-{foo}||[]}) { ... }
is the correct way to spell that I think.
Actually, no. See below.
If the 'foo' attribute hasn't been set to anything, then you
want an empty list to iterate over. With version C, that's
what you get.
No. If $self-{foo} is undef you get an error with version C.
You're forgetting autovivification. If $self-{foo} is undef it
is coerced into a appropriate reftype.
Gah. It seems you are correct. The rules for when autovivification happens are a little byzantine I think.
IMO this usage is a single level FETCH and not a STORE or a multilevel FETCH and as such should NOT autovivify. In fact the behaviour is inconsistant. Sometimes it autovivifies, sometimes not.
Consider:
D:\perl -e use strict; use warnings; my $x; if (@{$x}) { print}
Can't use an undefined value as an ARRAY reference at -e line 1.
D:\perl -e use strict; use warnings; my $x; for (@{$x}) { print}
D:\perl -e use strict; use warnings; my $x; for (@{undef()}) { print}
Can't use an undefined value as an ARRAY reference at -e line 1.
D:\perl -e use strict; use warnings; sub u { undef } my $x; for (@{u()}) { print}
Can't use an undefined value as an ARRAY reference at -e line 1.
So you cant just assume that for (@{EXPR}) {...} is going to be ok if EXPR resolves to undef. If EXPR is a function call return then it isnt safe.
Anyway, this is all just after the fact explanations that I am providing out of embarrasment.
:-)
Nah, just make the get_ autopopulate an undef attribute on
fetch. That way its not done unless is actually being used by
external code.
Yes, but what with? You can't know whether the attempt to access
an undef attribute is inside an array deref, a hash deref,
outside any deref contexts at all, or wherever. That's why I
proposed having a get_attr_with_default.
Ahah. Yeah good point...
Well, to be clear: I don't like the idea.
Because just as you said, having a good ::InsideOut would kill
*all* birds with one stone - what this module does and what
several others as well do (modules like the one that ties the
hash and prepends the package name on all accesses to a
traditional hashref $self - I can't remember what it's called).
On the other hand, we _don't_ have ::InsideOut so being
pragmatic, I'm saying that maybe it's not a bad idea to have this
in the meantime..
Well, maybe there are ways around the problems mentioned before. I think there are. Im just not sure yet.
Yves
RE: Class::FakeAttributes -- Opinions Wanted
Title: RE: Class::FakeAttributes -- Opinions Wanted
$ perl -Mstrict -wle 'my $f = { }; my @a = @{ $f-{foo} }'
Can't use an undefined value as an ARRAY reference at -e line 1.
Exactly my point. Stick that _expression_ in a for loop however...
D:\perl -Mstrict -wle my $f = { }; my @a=map {$_} @{ $f-{foo} }
D:\perl -Mstrict -wle my $f = { }; for (@{ $f-{foo} }) {print}
Re: Class::FakeAttributes -- Opinions Wanted
* Orton, Yves [EMAIL PROTECTED] [2003-11-06 19:41]: Well, maybe there are ways around the problems mentioned before. I think there are. Im just not sure yet. Yves Definitely. I have ideas for some of them. I just have more important work to do for the time being.. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
FAIL AFS-Command-1.3 darwin 6.8
While I applaud the effort to automate testing of new releases posted to CPAN, this is adding absolutely no vlaue in this case. I am not looking forward to getting one of these for every platform someone decided to test this on. This particular module can NOT be tested automatically, without some manual configuration. The tests can not automatically determine the configuration of your AFs infrastructure; you have to tell me. Therefore, everytime I post this module, these tests are going to fail. The same is going to be true for DBD::Sybase, or any of the RDBMS modules which need to be configured with a data server, and/or database name. Is there a mechanism for telling the automated CPAN testing to skip this module? I do NOT want to hack the code to make the test skipped by default, because then unsuspecting administrators who install the module without reading my documentation will be give a false positive. I would prefer to have the tests fail by default, but I don't want all these emails telling me something I already know. This distribution has been tested as part of the cpan-testers effort to test as many new uploads to CPAN as possible. See http://testers.cpan.org/ Please cc any replies to [EMAIL PROTECTED] to keep other test volunteers informed and to prevent any duplicate effort. -- This is an error report generated automatically by CPANPLUS, version 0.045. Below is the error stack during 'make test': PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/00vos_basic..Use of uninitialized value in pattern match (m//) at t/00vos_basic.t line 27. Error running vos help. Unable to configure AFS::Command::VOS at t/00vos_basic.t line 113 Unsupported vos operation 'create' at t/00vos_basic.t line 113 Unable to obtain arguments for AFS::Command::VOS-create at t/00vos_basic.t line 113 Use of uninitialized value in concatenation (.) or string at t/00vos_basic.t line 125. Unable to create volume 'afscmd.24617' on server 'server1:/vicepa'in cell 'your.cell.name' Errors from vos command: The following temporary volumes were created, and may be left over: afscmd.24617 dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 3-75 Failed 73/75 tests, 2.67% okay t/01vos_dumprestoreUse of uninitialized value in pattern match (m//) at t/01vos_dumprestore.t line 27. Error running vos help. Unable to configure AFS::Command::VOS at t/01vos_dumprestore.t line 119 Unsupported vos operation 'create' at t/01vos_dumprestore.t line 119 Unable to obtain arguments for AFS::Command::VOS-create at t/01vos_dumprestore.t line 119 Use of uninitialized value in concatenation (.) or string at t/01vos_dumprestore.t line 132. Unable to create volume 'afscmd.24619' on server 'server1:/vicepa'in cell 'your.cell.name' Errors from vos command: dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 3-19 Failed 17/19 tests, 10.53% okay t/02vos_volserver..Use of uninitialized value in pattern match (m//) at t/02vos_volserver.t line 27. Error running vos help. Unable to configure AFS::Command::VOS at t/02vos_volserver.t line 106 Unsupported vos operation 'listpart' at t/02vos_volserver.t line 106 Unable to obtain arguments for AFS::Command::VOS-listpart at t/02vos_volserver.t line 106 Use of uninitialized value in concatenation (.) or string at t/02vos_volserver.t line 116. Unable to query partinfo on server 'server1', in cell 'your.cell.name': dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 3-21 Failed 19/21 tests, 9.52% okay t/10bos_basic..Use of uninitialized value in pattern match (m//) at t/10bos_basic.t line 26. Error running bos help. Unable to configure AFS::Command::BOS at t/10bos_basic.t line 73 Unsupported bos operation 'getdate' at t/10bos_basic.t line 73 Unable to obtain arguments for AFS::Command::BOS-getdate at t/10bos_basic.t line 73 Use of uninitialized value in concatenation (.) or string at t/10bos_basic.t line 84. Unable to getdate for bosserver: dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 3-48 Failed 46/48 tests, 4.17% okay t/20fs_basic...Use of uninitialized value in pattern match (m//) at t/20fs_basic.t line 26. Error running fs help. Unable to configure AFS::Command::FS at t/20fs_basic.t line 77 Unsupported fs operation 'checkservers' at t/20fs_basic.t line 77 Unable to obtain arguments for AFS::Command::FS-checkservers at t/20fs_basic.t line 77 Use of uninitialized value in concatenation (.) or string at t/20fs_basic.t line 83. Unable to call checkservers: dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 3-124 Failed 122/124 tests, 1.61% okay t/30pts_basic..Use of uninitialized value in pattern match (m//) at t/30pts_basic.t line 26. Error running pts help. Unable to configure
Re: FAIL AFS-Command-1.3 darwin 6.8
On Thu, Nov 06, 2003 at 10:17:45AM -0500, [EMAIL PROTECTED] wrote: This particular module can NOT be tested automatically, without some manual configuration. The tests can not automatically determine the configuration of your AFs infrastructure; you have to tell me. Therefore, everytime I post this module, these tests are going to fail. The same is going to be true for DBD::Sybase, or any of the RDBMS modules which need to be configured with a data server, and/or database name. Is there a mechanism for telling the automated CPAN testing to skip this module? I do NOT want to hack the code to make the test skipped by default, because then unsuspecting administrators who install the module without reading my documentation will be give a false positive. You may be interested in how the DBD::Pg test suite works. As you point out, it does need a bit configuration for the tests to run. (In this case, setting a single environment variable usually works). If the environment variable isn't present the tests are skipped. Recently some of the configuration has been automated by using App::Info. The specific module used in this case is here: http://search.cpan.org/~dwheeler/App-Info-0.24/lib/App/Info/RDBMS/PostgreSQL.pm Perhaps a helper module like this could simplify the needed configuration in your case as well. Mark
Re: FAIL AFS-Command-1.3 darwin 6.8
On 11/6/2003 10:17 AM, [EMAIL PROTECTED] wrote: While I applaud the effort to automate testing of new releases posted to CPAN, this is adding absolutely no vlaue in this case. I am not looking forward to getting one of these for every platform someone decided to test this on. This particular module can NOT be tested automatically, without some manual configuration. The tests can not automatically determine the configuration of your AFs infrastructure; you have to tell me. Therefore, everytime I post this module, these tests are going to fail. The same is going to be true for DBD::Sybase, or any of the RDBMS modules which need to be configured with a data server, and/or database name. Is there a mechanism for telling the automated CPAN testing to skip this module? I do NOT want to hack the code to make the test skipped by default, because then unsuspecting administrators who install the module without reading my documentation will be give a false positive. I would prefer to have the tests fail by default, but I don't want all these emails telling me something I already know. Sounds like a job for META.yml. It would seem to be the best place to list things like: Is the module specific to a certain platform(s)? Does testing require manual intervention? Does install require manual intervention? Does the module have external dependencies? Randy. -- A little learning is a dang'rous thing; Drink deep, or taste not the Pierian spring; There shallow draughts intoxicate the brain; And drinking largely sobers us again. - Alexander Pope
