[I'm not on the notify list, dunno if this group-reply will cause an error]
On Tue, Feb 07, 2006 at 02:36:01PM +0100, Michael Haardt wrote:
I am asking for a generic way to solve the problem.
try {
notify "sms:NaN";
}
catch {
}
Yes, that's a can of worms and possibly not a good idea at all, but I
see a need for _some_ generic solution and that's all I can think of
right now.
Yes it would be nice to have a way of testing capabilities that didn't
introduce a new verb for each capability to be tested. One naive
thought is to have a side-effect of "require" set a variable within a
"require" namespace, but I don't really like that: it would only be
available if variables were present, and it would also not address the
problem of using a method that is specified by a variable.
Another would be to introduce some new style of "require" ("xrequire")
that:
- accepted only a single string (not a string-list);
- could have a side-effect that could be tested;
- could be used anywhere, even after other non-require commands;
- could require notify methods, a la the way that comparators are required;
- enabled the capability if the require is satisfied, but
- did not cause the script to fail if the 'require' wasn't satisfied.
if xrequire "refuse" {
do one thing...;
} else {
do another thing;
}
The form of the "notify-" capability could be specified to include either
just a method name (in which case only the availability of the method would
be tested) or a complete URI (in which case the availability of the method
AND the syntax of the URI could be tested):
if xrequire "mailto:mem(_at_)geezer(_dot_)org" {
notify "mailto:mem(_at_)geezer(_dot_)org";
}
I don't know how reasonable any of this is, I'm just scattering some
thoughts. Although this is more the way I've felt that require should
have been made to operate anyway, perhaps with a :fail option:
xrequire :fail "refuse";
Yet another approach would be to add a :nofail option to "require" and
have another command to test the results of "require"s later.
require :nofail "refuse";
if available "refuse" { ... }
but again, that doesn't address the use of variable methods.
BTW I also agree that the ":method" tag is superflous and would prefer
to see the method as a positional argument. An empty string could indicate
the site-default method, or one could even use "default:" .
-mm-
BTW what happened to the ":attributes" thing? Did this get shot down?