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