RE: Properties and "0 but true".
> That's not how I see it. The filehandle is naturally true if
> it succeeds. It's the undef value that wants to have more
> information. In fact, you could view $! as a poor-man's
> way of extracting the error that was attached to the last
> undef.
Hmm. Thus?
sub fuu()
{
my $retval is error("Unknown error") = open("file.ext");
$retval is error($!) unless $retval;
return $retval;
}
sub bahr()
{
my $result = fuu(); # $results gets properties from $foo::retval
if ($result) { blah(); }
else { print $result.error(), "\n"; }
}
Now, what about magic properties? If we have const, volatile,
memoizable, etc, what are the rules for when those get replaced?
my $PI is constant = 3;
my $new_pi = $PI; # Is $NEW_PI constant?
my $C = $PI * $RADIUS * 2; # Is $C constant?
# Would $C be constant if $RADIUS was?
sub pi() is memoizable { return $PI; }
Can I say <<'THIS',
my $subref is memoizable = \π
THIS
and declare a ref to memoizable subs? Will the compiler warn on this
basis? Or will the subs only be memoizable if called via subref?
And why can't I dynamically declare function properties? If I'm writing
a reporting application, and I successfully get an exclusive lock on
the db, then let me improve the performance of my application.
=Austin
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
RE: Properties and "0 but true".
> David Grove writes: > : > That's not how I see it. The filehandle is naturally true if it > : > succeeds. It's the undef value that wants to have more information. > : > In fact, you could view $! as a poor-man's way of extracting the error > : > that was attached to the last undef. > : > : If I were wealthy enough in time and patience to forego poor-man's error > : handling for exceptions and verbosity I'd be programming in C++ > with PCRE. > > Thank you. I think... > > I hope you weren't reading my remark to say that $! is going away, Naw, I just cringe when I hear "exception" and "perl" in the same sentence. Heretofore they have been violently adamant if not oxymoronic antitheses. p
Re: Properties and "0 but true".
David Grove writes: : > That's not how I see it. The filehandle is naturally true if it : > succeeds. It's the undef value that wants to have more information. : > In fact, you could view $! as a poor-man's way of extracting the error : > that was attached to the last undef. : : If I were wealthy enough in time and patience to forego poor-man's error : handling for exceptions and verbosity I'd be programming in C++ with PCRE. Thank you. I think... I hope you weren't reading my remark to say that $! is going away, because it's not. But $! might well *mean* what I said in Perl 6. Larry
RE: Properties and "0 but true".
> That's not how I see it. The filehandle is naturally true if it > succeeds. It's the undef value that wants to have more information. > In fact, you could view $! as a poor-man's way of extracting the error > that was attached to the last undef. If I were wealthy enough in time and patience to forego poor-man's error handling for exceptions and verbosity I'd be programming in C++ with PCRE. David T. Grove Blue Square Group [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Properties and "0 but true".
[EMAIL PROTECTED] writes:
: I guess a good rule would be, "Use return values consistently. If you
: have to return data, then use the true property to return status. If
: you can't use :true, then use :result."
By and large, it's best if the data itself is properly oriented so that
there's little need for a "true" property. Most of the time, true
values are more interesting than false values, so it generally works
out that way. The main exceptions are, er, exceptions.
So I don't actually see the "true" property being used all that much,
except in the places you currently would see "0 but true". I think the
status will generally be returned as the actual argument, and extra
info attached as a property:
return undef is error("Gorkulator borked");
That is, it's returning the exception that it *would* have thrown if
use Fatal (or whatever) had been in effect.
Now the really interesting thing is that, further on in the program, we
now know not only that the value is undefined, but we know *why* it's
undefined, and we could add that into any warnings about the use of
the undefined value, or perhaps transmogrify such a warning into a
fatal at that point.
Now that's action at a distance, but of a more delightful kind.
: my $fh = open(fname) or die "Argh!"; # uses :true
That's not how I see it. The filehandle is naturally true if it
succeeds. It's the undef value that wants to have more information.
In fact, you could view $! as a poor-man's way of extracting the error
that was attached to the last undef.
An object like $fh should define its bool method to be true as long
as it's a valid way to represent whatever it is that it's trying to
represent. (Or equivalently, the object should inherit such a method.)
Larry
Re: Properties and "0 but true".
--- Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> Yes... if you are using only the "true" property. But assume func()
> can attach either "true" or "false" to its return value (and in the
> latter case, also the "what_went_wrong" property to indicate the
> cause,
> $retval.what_went_wrong("Gorkulator borked.").)
I can live with that, provided that it's made clear what's happening.
Which is why I suggested a coding convention for this kind of thing.
Perhaps simply acknowledging that all INT objects will use primarily
their true property instead of their value to handle logical branching.
(As opposed to int objects, which will set no properties...or do I have
that backwards?)
> I understand your worry but if you are concerned about "more features
> equals less maintainability" you have obviously chosen the wrong
> language, be it Perl 5 or Perl 6. No, I'm rather serious. Perl has
> been, is, will be, a pragmatic language that borrows with gusto, and
> as a result it has a horde of features.
My angst is not "more features equals less maintainability". It's
"secret handshakes cause paranoia". I don't object to the new features.
But I want the new features to live in the light of day. I can easily
envision the following conversation:
Geek: It took three days, but I tracked down the bug in my program,
sir. It turns out that there's a feature of perl6 that says that when
this other module sets the property, it causes <...> and that was
taking precedence over my return(1); statement.
Boss: AWK!
So long as the perl6 culture makes clear what the "suggested" role of
these things is (and Damian's exegesis is a great thing,
clarification-wise) there should be no problem. But the point about
disconnecting properties and values, and action at a distance, is a
valid one.
I guess a good rule would be, "Use return values consistently. If you
have to return data, then use the true property to return status. If
you can't use :true, then use :result."
Thus:
if (databases_are_equal(dba, dbb)) {...} # uses value
my $fh = open(fname) or die "Argh!"; # uses :true
if ($retval = func(@args)) { ... }# uses :true
if (($retval = func(@args):result.type() <
CatastrophicEventThreateningTheContinuedExistenceOfLifeOnThisPlanet) {
... }# uses too many characters :-)
=Austin
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
Re: Properties and "0 but true".
> The statement I read was "true in any possible way", which implies that
> if $retval had a "true" property, the result of func would be
> irrelevant, since if func gave 0, "any possible way" would see the
> "$retval is true" property and take the "it worked" route.
>
> Thus, this code:
>
> my $retval is true;
>
> if ($retval = func(@args))
> {
> # it worked...
> }
> else
> {
> # nope...
> print $retval.what_went_wrong, "\n";
> }
Yes... if you are using only the "true" property. But assume func()
can attach either "true" or "false" to its return value (and in the
latter case, also the "what_went_wrong" property to indicate the cause,
$retval.what_went_wrong("Gorkulator borked.").)
> I don't mind the presence of these potentially horribly confusing
> thingys. After all, thanks to this list I'll be on the right side of
> the learning curve. However, I don't think that "Poo, poo." is the
> correct answer to "How about maintainability?" on anybody's multiple
> choice exam.
I understand your worry but if you are concerned about "more features
equals less maintainability" you have obviously chosen the wrong
language, be it Perl 5 or Perl 6. No, I'm rather serious. Perl has
been, is, will be, a pragmatic language that borrows with gusto, and
as a result it has a horde of features.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: Properties and "0 but true".
--- Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
> > Hmm. I can easily see this producing incomprehensible code when
> spread
> > across large systems. To wit, those developers used to "0 means
> false"
>
> Any feature is incomprehensible if one is not used to it. Pointers
> in C are incomprehensible if one has never met the concept before.
>
> As far as I understand one rationale behind the "false (in Perl 5
> terms)
> but true (in Perl 6 terms)" is that you can write code like this
>
> if ($retval = func(@args)) {
> # it worked ...
> } else {
> # it didn't ...
> # but we still can dig out more information
> # about the result ...
> print $retval.what_went_wrong, "\n";
> }
The statement I read was "true in any possible way", which implies that
if $retval had a "true" property, the result of func would be
irrelevant, since if func gave 0, "any possible way" would see the
"$retval is true" property and take the "it worked" route.
Thus, this code:
my $retval is true;
if ($retval = func(@args))
{
# it worked...
}
else
{
# nope...
print $retval.what_went_wrong, "\n";
}
would execute the "it worked" case for all values of func(@args), which
to me seems to be asking for trouble.
Of course, if the scalar result can't have associated properties ...
Or, if the properties of a scalar are reset on assignment (cringe) ...
Perhaps
> > semantics seeings a scalar that they just know has a 0 in it and
> > wondering why the branch isn't doing what they know it should.
>
> Free your mind-- detach the truth of a scalar from its '0 or "" or
> undef'
> nature.
New from O'Reilly's offshore division?
"Perl CookBook, 4th edition. Crack pipe and 6 rocks included!"
I don't mind the presence of these potentially horribly confusing
thingys. After all, thanks to this list I'll be on the right side of
the learning curve. However, I don't think that "Poo, poo." is the
correct answer to "How about maintainability?" on anybody's multiple
choice exam.
=Austin
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
