yada yada yada in regex
what is the equivalent convention for yadayadayada in regex. Cuz ...
is alread meaningful in regex. Should I use <...> or {...} ?
Should the first be predefined?
I want something that is a placeholder that parses but fails if
someone pastes it. In other words the equivalent of
a sub yada yada yada
--
cognominal stef
Foo.HOW.metamethod vs Foo.^metamethod
Hi,
When implementing prototype OO, the HOW for objects with different
behaviours will be shared. This issue is not new, but before we thought
that it would be possible to solve that by forcing $foo.HOW to be a
proxy object that would rewrite the call putting $foo as the invocant.
Me and nothingmuch, during PPW in Braga, got more into that issue, and
we came to the realisation that this is not really possible, as it might
be actually desirable to have a real meta object, storing
meta-information that would be part of that metaobject implementation.
The HOW might be implementing some kind of RPC, for instance, and that
way, it might need to store some meta-meta-information, like the address
of the RPC endpoint. This makes the idea of the proxy object inviable
because the user might need to talk to the HOW as a real object.
That way,
$foo.^can('bar') cannot be the same as $foo.HOW.can('bar'), because the
first has both $foo and $foo.HOW implied, while, in the last, $foo
cannot be taken from anywhere.
Therefore I suggest making $foo.^method format the only way to get
metamethods related to this object, while $foo.HOW would have a
behaviour which would be implementation dependent (at least until it's
standartized)
SMOP will have $foo.^can('bar') actually translated to
$foo.HOW.can($foo, 'bar'), which will keep $foo.HOW as the invocant, and
prepend the referring object as the first positional argument (following
the example of the sub-dispatch fallback).
In that case, we might either:
1) remove all references of $foo.HOW.can('bar') and say that this is
implementation specific (since Class-based OO can implement it that way)
2) Assume the capture-translation and define that
$foo.HOW.can($foo,'bar') keeps the $how as the invocant and must receive
the referring object as first argument.
daniel
Re: yada yada yada in regex
Sáb, 2008-06-07 às 16:01 +0200, Stéphane Payrard escreveu:
> what is the equivalent convention for yadayadayada in regex. Cuz ...
> is alread meaningful in regex. Should I use <...> or {...} ?
> Should the first be predefined?
If I understand correctly, {...} should already be parsed as a yada yada
yada closure, since ... is 'like' a statement.
I might be missing something, but <...> would be a rule with the '...'
name which, I think, is parseable, and could even be implemented
daniel
clarification on samecase() and samebase()
Hi all, Auzon has written a few tests for the samecase() and samebase() (S29), which raised a question: For both the :samecase and there :samebase regex modifier (S05) there is a "dumb" and a "smart" version. S29 is silent about which it refers to. Should both have a second, optional argument which specifies the operation mode? Or are they both "dump", and the regex engine does the mapping from smart to dump itself? Anyway, S29 needs clarification. BTW the naming seems inconsistent to me: same*case* preserves *case*, but same*base* preserves *accents* -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Fatal/autodie exception hierarchies for Perl 5
On Sun, Jun 1, 2008 at 7:31 PM, Paul Fenwick <[EMAIL PROTECTED]> wrote:
> Currently, when testing exceptions from autodie, we can use:
>
>given ($@) {
>when (undef) { say "No errors here" }
>when ('open') { say "Open died" }
>when (':file') { say "Some sort of file error" }
>when (':io') { say "Some other error" }
>when (':CORE') { say "Some other CORE error" }
>when (':USER') { say "A non-CORE error" }
>when (':all') { say "Any autodie exception at all." }
>default{ say "Not an autodie exception." }
>}
If you're going to write that into some documentation, I wish you'd
make default say that it's exception suicide.
given( my $_ = $@ ) {
...
default { say '$@ committed suicide' }
}
Semi-recently at work I found that a few buggy exception objects in
the global $@ were clearing themselves out of $@ as a side effect of
examining them for truth. It's quite annoying and mysterious when it
happens.
Josh
Re: Fatal/autodie exception hierarchies for Perl 5
G'day Josh / p5p / p6l,
given ($@) {
# [snip]
default{ say "Not an autodie exception." }
}
If you're going to write that into some documentation, I wish you'd
make default say that it's exception suicide.
The documentation clearly needs to make clear what that default means,
because it's certainly not exception suicide. The exceptions thrown from
autodie bind smart-match (used in given/when) to a 'does/has_role' style
check. The ':all' test (which may change its name) checks against a
meta-role shared by all autodie exceptions. If something doesn't match
that, then it wasn't an exception from autodie. It could have been an
exception from something else, or even a plain string exception.
Semi-recently at work I found that a few buggy exception objects in
the global $@ were clearing themselves out of $@ as a side effect of
examining them for truth. It's quite annoying and mysterious when it
happens.
Yes, I've seen this sort of behaviour too, and I'm being particularly
mindful to make sure it doesn't happen with the code in autodie. I've
marked myself down a TODO item to make sure there's a big barrage of tests
to ensure that $@ still contains what we expect at the end of each exception
handling block.
Cheerio,
Paul
--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia| Fax: +61 3 9354 2681
