> >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