--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> On Thursday, March 13, 2003, at 01:05 PM, Austin Hastings wrote:
> > More to the point:
> >
> > type sigfunc is interrupt is reentrant;
> >
> > sub sig_ign() is sigfunc {...}
> > sub sig_kill() is sigfunc {...}
> > sub sig_intr() is sigfunc {...}
>
> This is WAGging based on A6, but I guess I see things like this as
> being implemented by making subs that inherit from subs:
>
> class sigfunc is sub (...default signature...) is interrupt is
> reentrant;
>
> sub sig_ign(...alternate signature...) is sigfunc {...}
> sub sig_kill is sigfunc {...}
> sub sig_intr is sigfunc {...}
>
> sigfunc sig_foo {...} # could you also say it like this, I
> wonder?
>
> Since C<sub> is itself a class, you can subclass it.
You are a bad, evil man for reminding me of this. I have yet to
brainvomit about stack-streams. (I have found an interesting analogy
between subs/blocks and streaming video compression, but it is too
large to fit in the margin :-)
> And since A6 indicates that the signature, traits, and even
> implementing body are just properties of a given C<sub> "object",
> you should be able to override them individually if you want, for
> example, an alternate signature. At least, I'm hoping something
> like that works -- there's a lot of guessing there.
Which reminds me that sigfuncs aren't is reentrant. They're but
reentrant.
my sub &foo = &sig_kill; # &foo is "but interrupt reentrant", too.
Which points in the direction of "sticky value traits", and "sticky
value traits" is a synonym for "class".
So you're right -- this case is a class extension. But then the
question becomes "how easy is it to override a class like this"?
> sub sig_kill is sigfunc {...}
> sub sig_intr is sigfunc {...}
>
> sigfunc sig_foo {...} # could you also say it like this, I
> wonder?
Well, no. That's going to look like a function returning a sigfunc.
Obviously we're walking on an edge-case. (Lucky for me that you're Mr.
Edge-Case, eh?)
> > type null but defined but false;
> >
> > ...
> > return undef but null;
>
> Hmm... I'm not entirely sure how that works for runtime properties...
>
> but what about
>
> class null is void but defined but false;
>
> return undef but null;
>
> Would something like that that be OK? Essentially using 'void' as a
> marker that you're defining a (heh) classless class? I'd really like
> to avoid making a separate keyword for combining traits, I'd love for
> it to just use the normal class inheritance mechanisms.
Cool if you can get it. But I want to be able to handle all sorts of
trait-contexts:
my macro sucks() is parsed(/<null>/) { "is slurpificatious" }
class foo_arg is rw is copy is coerced is optional;
sub foo( $v is foo_arg, @x is foo_arg sucks) {...}
=Austin
