?Well, you could implement BigNums with this proposal. You just need to make
the assumption the browser use int32 to store integer numbers smaller than
the max limit. Then, you build up an array that represent the big number,
where arr[0] is its part from 0 to 2^32-1, arr[1] its part (=the bytes) from
2^31 to 2^64-1, and the like. You could also rely on something more subtile
and less hazardous if you prefer.
Regarding the a+bi problem, I may have a solution : I propose the following
methods : a.canAdd(b), return true if a.add(b) can succeed.
The default a.canAdd(b) method would check if "b" can be converted into the
type of "a" using b.convertTo(a.constructor) or
a.constructor.convertFrom(b).
The default Function.prototype.canConvertFrom(b) would return true only if
"b" is of type (or inherits from type) "this".
In this case, the Complex class should implements some conversion logic to
implement [[Number -- (widening) -> Complex]] and [[Complex --
(narrowing) -> Number]].
a = 1;
b = new Complex(0,1); // b = i := sqrt(-1)
a+b;
---> a.canAdd(b)
---> b.canConvertTo(Number) : no (because it has a complex part != 0)
---> Number.canConvertFrom(b) : no (because UA don't have this
implemented)
---> no (a+b is not evaluted as a.addRight(b))
---> b.canAdd(a)
---> a.canConvertTo(Complex) : no (because UA don't have this
implemented)
---> Complex.canConvertFrom(a) : yes (because it's implemented by the
user)
---> yes
----> a+b is evaluated as b.addLeft(a);
When a.canAdd(b) && b.canAdd(a) AND a.operatorPriority==b.operatorPriority,
a.addRight(b) is called.
I suggest to use some special syntax for those additions, and not use a true
property called "add", because it can mess up many already-written code.
What about Complex.prototype = {
operator add: function(b) { b=Complex.convertFrom(b); return new
Complex(this.a+b.a, this.b+b.b); },
operator canConvertFrom: function(b) { return
b.constructor==Complex||typeof(b)=="number"; },
....
// as no operators for addLeft/addRight are defined, addLeft and
addRight are mapped to "add" (commutativity is implied).
// as no operator for multiply is defined, default
Object.prototype.[operator]multiply apply, which lead to an error if used
with non-Number objects.
} and Object.defineOperator/Object.getOperatorDescriptor/... ?
BTW, as it may cause huge difficulties for UAs, I propose to have the
operators of String, Number, Date (& others) marked as read-only.
Regards,
François
-----Message d'origine-----
From: Erik Corry
Sent: Monday, January 10, 2011 11:12 AM
To: thaddee yann tyl
Cc: [email protected]
Subject: Re: Operator Overloading
2011/1/10 thaddee yann tyl <[email protected]>:
I see no reason to name the "floordiv" trap that way. Python has a
Agreed.
On a slightly more high level note it seems like there is a very large
number of complex proposals being poured into Harmony. If they are
all implemented the language will become unwieldy and complex both for
users and implementers. Is there a sense in which we have a
'complexity budget' or does the committee feel we can add all
proposals to the language?
On the concrete proposal I note that the strawman claims this can be
used to implement bignums, but it seems to me there is no way to
implement storage of arbitrary size so that would appear to be
impossible. Am I missing something.
Another question: As I read the proposal, the dispatch is on the left
hand side of binary operators. Does the proposal have a way for a+b
to work where a is an old-fashioned number and b is a complex?
--
Erik Corry
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
