On Thu, Jan 17, 2008 at 10:56:12PM -0600, Patrick R. Michaud wrote:
: On Thu, Jan 17, 2008 at 01:18:32PM -0800, [EMAIL PROTECTED] wrote:
: > +=item *
: > +
: > +The definition of C<.true> for the most ancestral type (that is, the
: > +C<Object> type) is equivalent to C<.defined>.
:
: Would we normally consider prefix:<?> to be defined in terms of
: C<.true>, or vice versa? Is there a prefix:<true>, or is C<true>
: treated like an 'is export' trait on '.true' method?
There's a sense in which those are all just aliases for the same
operation, and a sense in which the .true method is more basic.
The sense in which it is more basic is that the object is in charge
of single dispatch, but it is not in charge of multiple dispatch.
And all operators and function calls are considered multiple dispatch,
hence they do not "belong" to the object. As for whether the
ordinary export mechanism handles it, I'm not sure. S03 defines both
prefix:<?> and prefix:<true> at different precedence levels than an
ordinary true() function would work, and we don't have a mechanism
under "is export" for giving multiple names, let alone different
precedence levels. So to a first approximation, prefix:<?> and
prefix:<true> are defined separately and just call into .true.
Another ramification of the single/multiple dispatch distinction is
that if you call $obj.true on an object created in a foreign language,
it probably calls the .true as defined by the other language. Perl is agnostic
about what happens behind .HOW is another way of saying it, and foreign
objects are allowed to have their own idea of .HOW to call methods.
But if you say "true $obj" you are calling Perl's true operator, which
might default to .true, or it might not, if you've given a different
multi defininition of prefix:<true> for that foreign type. So Perl's
$a + $b is guaranteed to keep numeric semantics even when calling two
objects in a language that uses '+' for concatenation. However,
$a.'+'($b) is going to try to call the '+' method on $a in the foreign
language, and is likely to do concatenation if calling into a language
that abuses overloading that way.
: Is there also a C<.not> method?
While we could force people to write things like
(not $obj.foo).bar
it seems like it could be useful when the general data flow is
left-to-right in a series of method calls:
$obj.foo.not.bar
And I don't see how it can hurt much. And
$obj.foo.prefix:<not>.bar
seems a bit tortuous, even if it ends up having the same effect.
Though it's not quite the same, since the prefix presumably forces
a multiple dispatch to Perl's idea of notiness, while a direct .not
method would rely on the the object's notion of notiness. This is
probably a good distinction for cross-language programming.
So I think Object should define a default .not that is defined in
terms of .true. If a Perl class wants to override that, it's
probably because it has a more efficient .not test, and wants to
define .true in terms of .not instead.
Larry
