2000-08-28-18:47:06 Tom Christiansen:
> It strikes me as a bit reminiscent of (one reason) why Larry
> didn't make a+b work on strings, since then while with numbers,
> a+b and b+a would be the same, with strings they would not be, and
> we have these rather deeply held convictions about such matt
Damian Conway <[EMAIL PROTECTED]> writes:
>
>
>BTW, this is not just theoretical yearnings. I have written three modules
>in the past year that do not work as well as they could, simply because it
>is not possible to overload && and ||.
>
>Damian
I have one too.
--
Nick Ing-Simmons <[EMAIL PRO
Piers Cawley wrote:
>
> And the RFC then proceeds to ignore this point and proposes something
> that looks remarkably similar to the current overloading scenario. Or
> am I missing something? I really can't see where the win is with this
> proposition.
The win is that this allows us to embed obj
Nathan Wigner in the guise of Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> You can use facilities such as C to help fix this issue, but
> C is limited and slow. You can also overload operators, but
> this is not flexible enough for many applications since it applies
> to a package (and not in
Tom Christiansen wrote:
> Hm I don't recall C++ ever thinking to overload the control-flow
> operators ("&&", "||", "," (that is, comma), and "?:"). Why not?
> Even if their "a && b" should produce a more mundane 1 or 0, one
> still might wish control.
>
'&&', '||', et al are just operato
>I can currently overload + < > * to do this, but not &&. That's broken.
Hm I don't recall C++ ever thinking to overload the control-flow
operators ("&&", "||", "," (that is, comma), and "?:"). Why not?
Even if their "a && b" should produce a more mundane 1 or 0, one
still might wish contr
> Summary: I think these should all simply break down into a single
> Boolification test of some sort, as occurs already with operator
> overload.
Counter-summary: Although the high and low precedence binary ops could be
rolled together, the current version of operator o
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
>LOGHIGHAND Called in && context
>LOGHIGHOR Called in || context
>LOGLOWAND Called in and context
>LOGLOWOR Called in or context
>LOGIFE
>Data Conversion and Access
>-
>STRING Called in a string context
>NUMBER Called in a numeric context
>BOOLEAN Called in a boolean context
>
>
>Operator Overloading
>
>You could overload
> FILE < STRING
>to be a print operator returning a FILE so we can do C++ like
> cout << "hello Bjarne" <
Nathan Wiger wrote:
>
> Oh geez! I'm sorry, I forgot to mention David Nicol in the REFERENCES,
> who also gave great input, especially on the BOOLEAN accessor. Thanks
> David! I swear I'll put you in v2. :-{
>
> -Nate
Whatever.
You could overload
FILE < STRING
to be a print operato
Tom Christiansen wrote:
>
> I encourage one to examine how Python does this. Particularly attractive
> is the way one does not have to distinguish between tie and operator
> overloading there.
I'll check it out.
But just to clarify: This proposal means we won't be distinguishing
between tie a
>Jonathan Scott Duff wrote:
>>
>> >Operator Overloading
>> >-
>> >PLUS Called in + context
>> >MINUSCalled in - context
>> >TIMESCalled in * context
>> >DIVIDED Called in / context
Jonathan Scott Duff wrote:
>
> >Operator Overloading
> >-
> >PLUS Called in + context
> >MINUSCalled in - context
> >TIMESCalled in * context
> >DIVIDED Called in / context
> >
On Fri, Aug 25, 2000 at 03:23:25PM -, Perl6 RFC Librarian wrote:
>Operator Overloading
>-
>PLUS Called in + context
>MINUSCalled in - context
>TIMESCalled in * context
>DIVIDED
Oh geez! I'm sorry, I forgot to mention David Nicol in the REFERENCES,
who also gave great input, especially on the BOOLEAN accessor. Thanks
David! I swear I'll put you in v2. :-{
-Nate
Perl6 RFC Librarian wrote:
>
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
16 matches
Mail list logo
