> >STRINGIFY would have my vote. "It's a string!!!". A string is a very
> >specific subtype of scalar.
>
> How about TO_STRING? Little less geeky.
AS_STRING. It doesn't convert, it translate.
Or just STRING. It's a verb to, you know ;-)
> How would this play with overload.pm? What if that also specifies a
> stringify routine? Which one should win?
Operator overloading is scheduled to be revamped.
It might well be that, rather than specifying q{""}, q{0+}, and q{bool},
we have:
package MyClass;
sub STRING {...}
sub NUMBER {...}
sub BOOLEAN {...}
Hmmmm. Maybe even:
sub op+ {...}
sub op* {...}
sub op<=> {...}
#etc.
Shades of C++! ;-)
Damian
PS: This would tie in very nicely with my forthcoming multimethods proposal.
- RFC 49 (v1) Objects should have builtin string SCALA Perl6 RFC Librarian
- Re: RFC 49 (v1) Objects should have builtin strin... Peter Scott
- Re: RFC 49 (v1) Objects should have builtin s... Spider Boardman
- Re: RFC 49 (v1) Objects should have built... Nathan Wiger
- Re: RFC 49 (v1) Objects should have b... Bart Lateur
- Re: RFC 49 (v1) Objects should h... Peter Scott
- Re: RFC 49 (v1) Objects should have built... Damian Conway
- Re: RFC 49 (v1) Objects should have b... Nathan Wiger
- Overloading && || Nick Ing-Simmons
- Re: Overloading && || Peter Scott
- Re: Overloading && |... Nick Ing-Simmons
- Re: Overloading &&am... Peter Scott
- Re: Overloading && || Damian Conway
- Re: Overloading && || Damian Conway
- Re: Overloading && || Peter Scott
- Re: Overloading && || Dan Sugalski
- Re: Overloading && |... Nick Ing-Simmons
