etting the value to the enum
value that means "nope". For example, there isn't a "true" property,
per se. There's a Boolean role/property with a boolean attribute that
can have the value either true or false. When you say "but true",
it first makes sure that
correctly, adding a role at runtime using but
> : won't override any methods defined by the class itself (but it
> : will override inherited methods). But then if I create a class
> : that has its own method of saying whether it's true or not, does
> : that mean that
[EMAIL PROTECTED] (Larry Wall) writes:
> is classof($x)
Ouch. $x's class isn't a property or trait of it?
> class AnonClass is classof($x) does FooBar { }.bless($x, foobar => bar)
I don't understand what the bit at the end is doing. This is calling .bless
on the overriden method? And I'm not
Larry Wall wrote:
> Maybe there's an intermediate syntactic form like:
>
> $x but subclass MyClass does FooBar[bar] { }
IMHO, C should be defined as generating a singleton class that
derives from the variable's class and composes a specified role - but not
neccessarily a I role. How about de
On Fri, Dec 19, 2003 at 12:24:29PM -0700, Luke Palmer wrote:
: Abhijit A. Mahabal writes:
: > On Fri, 19 Dec 2003, Larry Wall wrote:
: >
: > > On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote:
: > > : Of course, when I do:
: > > :
: > >
Abhijit A. Mahabal writes:
> On Fri, 19 Dec 2003, Larry Wall wrote:
>
> > On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote:
> > : Of course, when I do:
> > :
> > : my $x = 0 but (true|false);
> > :
> > : then what happens?
> >
>
On Fri, 19 Dec 2003, Larry Wall wrote:
> On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote:
> : Of course, when I do:
> :
> : my $x = 0 but (true|false);
> :
> : then what happens?
>
> That's the problem with making them methods. Any such operational
On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote:
: Of course, when I do:
:
: my $x = 0 but (true|false);
:
: then what happens?
That's the problem with making them methods. Any such operational
definition is going to get you in trouble. I think I like them better
as
ide any methods
: defined by the class itself (but it will override inherited methods). But then
: if I create a class that has its own method of saying whether it's true or not,
: does that mean that "but true" and "but false" won't do anything to it?
:
;
> >
> > ...
> >
> >
> > then somewhere in a function
> >
> > return Complex::new(0,0) but true;
>
> Alternatively, think of the "simple" properties not as C
> specifications, but as method overrides.
>
> In this case, we're d
ded to a class cannot conflict (per the paper and $Larry), but
traits added at run-time would be a different category. Larry said
something about dynamic derivation of a singleton class, etc.
> But then if I create a class that has its own method of saying
> whether it's true or not,
methods). But then
if I create a class that has its own method of saying whether it's true or not,
does that mean that "but true" and "but false" won't do anything to it?
class Complex {
has $.real;
has $.imag;
...
#Actually, how do we define this?
method asB
> 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 err
> 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
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 wealt
> 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 t
h,
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*
--- 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("Gork
> 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
> 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 t
--
John Porter
21 matches
Mail list logo
