Bringing up the issue of numerical constraints again

[Lars T Hansen]

On Nov 17, 2007 11:11 AM, Yuh-Ruey Chen <maian330 at gmail.com> wrote:
> Is it not possible to emulate this already with classes? I think you can
> use the implicitly-called construct method, e.g.
>
> class myint {
>     private var i: int;
>     function myint(x: int) {
>        this.i = int;
>     }
>     meta static function invoke(x: int) {
>        if (x > SOME_MAX_VALUE || x < SOME_MIN_VALUE)
>           throw some_error;
>        return new myint(x);
>     }
> }
>
> Or something like that. Above code is probably wrong. I'm not sure
> exactly when and how invoke is called

It's only ever called explicitly.

> or even what the implicit type conversion customization protocol is.

Any number type converts to any other; String and string interconvert;
Boolean and boolean interconvert; anything converts to boolean.  These
are special case rules in the system; you can't extend them.

> However, if it isn't possible to create a class to emulate such
> constraints, maybe we ought to do something about it...

A more restrictive rule might be that implicit conversions can only
take place so that data are not lost, ie, implicit double -> uint is
allowed if the value fits in uint but not otherwise.  I don't think
this fits in very well with ES3; in ES3, the ToUint32 conversion will
happily chop off higher order bits.  I'm not defending that, just
noting that if we want to stick to "the spirit of the language" then
we stick with this conversion behavior on (any number) -> uint also.

--lars

>
> -Yuh-Ruey Chen
>
>
> liorean wrote:
> > Hello!
> >
> > Since we now have a namespace for uint specific math operations, and
> > discussion in another thread about using pragmas for throwing if
> > assigning to ReadOnly properties... Is it possible we could have a
> > look at the idea of adding constrained primitive types or adding a
> > pragma changing the mechanism for, or adding a separate set of
> > operations, constraining number types by the simple rule of (input >
> > output_type.MAX_VALUE) and (input < output_type.MIN_VALUE) throwing an
> > out-of-bounds error.
> >
> > I'm a little concerned that a type of uint allows assigning negatives
> > with a silent round-the-corner conversion and allows values of NaN and
> > Infinity. (I imagine for example the DOM interfaces that have uint
> > constraints really would like these to throw an out-of-bounds
> > exception or similar.)
> >
> > Also, the RI gives an Overflow exception for values 2^32 or greater,
> > which I'm not sure whether it's the intended behaviour or a result of
> > the underlying implementation that is in fact intended to fail
> > silently like the other cases.
> >
> > >> function fn(input:uint):uint input;
> > >> fn(0x7fffffff);
> > 2147483647
> > >> fn(-0x80000000);
> > 2147483648
> > >> fn(Infinity);
> > 0
> > >> fn(NaN);
> > 0
> > >> fn(0x100000000);
> > unhandled exception: Overflow
> >
> > >> function fn(input:int):int input;
> > >> fn(0x7fffffff)
> > 2147483647
> > >> fn(0x80000000)
> > -2147483648
> > >> fn(-0x80000000)
> > -2147483648
> > >> fn(NaN)
> > 0
> > >> fn(Infinity)
> > 0
> > >> fn(0x100000000)
> > unhandled exception: Overflow
> >
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>