0001 
0002 /*
0003  *  JScripter Standard 1.0 - To Script In Java
0004  *  Copyright (C) 2008-2011  J.J.Liu<jianjunliu@126.com> <http://www.jscripter.org>
0005  *  
0006  *  This program is free software: you can redistribute it and/or modify
0007  *  it under the terms of the GNU Affero General Public License as published by
0008  *  the Free Software Foundation, either version 3 of the License, or
0009  *  (at your option) any later version.
0010  *  
0011  *  This program is distributed in the hope that it will be useful,
0012  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
0013  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
0014  *  GNU Affero General Public License for more details.
0015  *  
0016  *  You should have received a copy of the GNU Affero General Public License
0017  *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
0018  */
0019 
0020 package js.core;
0021 
0022 import js.*;
0023 
0024 /**
0025  * <p>An <b>opaque</b> class representing JavaScript number objects.</p>
0026  *
0027  * @author <a href="mailto:jianjunliu@126.com">J.J.Liu (Jianjun Liu)</a> at <a href="http://www.jscripter.org" target="_blank">http://www.jscripter.org</a>
0028  * @see js.core.JsGlobal.Number#create(Object)
0029  * @see jsx.core.NumberLikes
0030  * 
0031  * @javascript <b>Opaque</b> types can be resolved but no class objects for them can be 
0032  * generated into the target codes. Re-compilers must exit with error on the operations of 
0033  * accessing that kind of class objects.
0034  * The <tt>checkcast</tt> operation to the class literal of this interface must be ignored 
0035  * and <tt>instanceof</tt> to it always <tt>true</tt>.
0036  */
0037 public class JsNumber extends JsGlobal.Number.Prototype implements NumberLike<Number>
0038 {
0039     /**
0040      * <p>An <b>opaque</b> class representing members of its enclosing <b>opaque</b> type.</p>
0041      * <p>Note that, this class is <b>opaque</b> but its constructors are all <b>internal</b>. 
0042      * This class and the subclasses of this class are used to declare either <b>opaque</b> 
0043      * <tt>public</tt> instance fields of the opaque type {@link js.Var.Member} or the 
0044      * <b>opaque</b> <tt>public</tt> static fields of other <b>opaque</b> types while their 
0045      * constructors are used to define the fields inside <b>opaque</b> classes. Under 
0046      * either circumstance, the field names must be exactly same as the member names, as 
0047      * the <b>opaque</b> fields of <b>opaque</b> types are resolved by re-compilers directly 
0048      * based on the field names.</p>
0049      *
0050      * @author <a href="mailto:jianjunliu@126.com">J.J.Liu (Jianjun Liu)</a> at <a href="http://www.jscripter.org" target="_blank">http://www.jscripter.org</a>
0051      * 
0052      * @javascript <b>Opaque</b> types can be resolved but no class objects for them can be created 
0053      * in the target codes. Re-compilers must exit with error on operations accessing that kind 
0054      * of class objects.
0055      * Re-compilers must resolve an <b>opaque</b> instance field declared by this class in 
0056      * {@link js.Var.Member} or its subclasses to the JavaScript identifier: 
0057      * <pre>q.m</pre>
0058      * where <tt>m</tt> is the identifier of the field name and <tt>q</tt> is the identifier 
0059      * resolved from the instance of the enclosing member. Re-compilers must resolve an 
0060      * <b>opaque</b> static field declared by this class in <b>opaque</b> types other than 
0061      * {@link js.Var.Member} and its subclasses to the JavaScript identifier: 
0062      * <pre>m</pre>
0063      * where <tt>m</tt> is the identifier of the field name. And re-compilers must report 
0064      * error on the access to <b>opaque</b> fields declared by this class under any other 
0065      * circumstances.
0066      */
0067     public static class Member extends JsGlobal.Number.Prototype.Member
0068     {
0069         /**
0070          * <p>Internally constructs a member based on a qualifying member.</p>
0071          * <p>This constructor is <b>internal</b> and only called inside of <b>opaque</b> 
0072          * or <b>internal</b> classes or class members.</p>
0073          * <p>Note that, this constructor is <b>internal</b> but its declaring class is 
0074          * <b>opaque</b>. This constructor is used to define <b>opaque</b> instance fields 
0075          * declared in the declaring class of this constructor itself or its subclasses. 
0076          * Under this circumstance, the field names must be exactly same as the member 
0077          * names, as the <b>opaque</b> instance fields of the <b>opaque</b> type 
0078          * {@link js.Var.Member} or its subclasses are resolved by re-compilers directly 
0079          * to their names appending to the name resolved from the specified qualifying 
0080          * member with a dot in between.</p>
0081          * @param q A qualifying member
0082          * @param mid The ID of the member to construct
0083          * @since 1.0
0084          * @javascript Re-compilers must report error on the invocation to an <b>internal</b> constructor. 
0085          */
0086         public Member(JsObject.Member q, Mid mid) {
0087             super(q, mid);
0088         }
0089         /**
0090          * <p>Internally constructs a member without a qualifying member.</p>
0091          * <p>This constructor is <b>internal</b> and only called inside of <b>opaque</b> 
0092          * or <b>internal</b> classes or class members.</p>
0093          * <p>Note that, this constructor is <b>internal</b> but its declaring class is 
0094          * <b>opaque</b>. This constructor is used to define <b>opaque</b> static fields, 
0095          * declared in <b>opaque</b> types other than the declaring class of this constructor 
0096          * itself and its subclasses. Under this circumstance, the field names must be 
0097          * exactly same as the member names, as the <b>opaque</b> static fields of <b>opaque</b> 
0098          * types are generally resolved by re-compilers directly to identifiers of their names.</p>
0099          * @param mid The ID of the member to construct
0100          * @since 1.0
0101          * @javascript Re-compilers must report error on the invocation to an <b>internal</b> constructor. 
0102          */
0103         public Member(Mid mid) {
0104             super(mid);
0105         }
0106         /**
0107          * <p>Evaluates the property, represented by the current member instance, of the 
0108          * argument object.</p>
0109          * @param o The argument object
0110          * @return The value of the current member based on the object argument.
0111          * @since 1.0
0112          * @javascript Re-compilers must convert the instance invocation of this method into 
0113          * the JavaScript expression: 
0114          * <pre>o.m</pre>
0115          * where <tt>m</tt> is the identifier name resolved from the current member 
0116          * instance of the invocation.
0117          */
0118         @Override
0119         public JsNumber with(ObjectLike o) {
0120             return new JsNumber((JsObject)var(o).var(mid()));
0121         }
0122 
0123         /**
0124          * <p>An <b>opaque</b> instance field defining a sub-member that is named by the 
0125          * name of this field, qualified by the current member instance of the field, and 
0126          * to access the property of the name on an object.</p>
0127          * <p>The <tt>constructor</tt> property of an object is a reference to the function 
0128          * that was the constructor for that object.</p>
0129          * <p>A common use of the <tt>constructor</tt> property is to determine the type of unknown 
0130          * objects. Given an unknown value, you can use the {@link js.Js#typeof(Object)} operation 
0131          * to determine whether it is a primitive value or an object. If it is an object, you can 
0132          * use the <tt>constructor</tt> property to determine what type of object it is.</p>
0133          * <p>Note, however, that while this technique works for the objects built into core 
0134          * JavaScript, it is not guaranteed to work with host objects such as the <tt>window</tt> 
0135          * object of client-side JavaScript. The default implementation of the <tt>toString()</tt> 
0136          * method provides another way to determine the type of an unknown object.</p>
0137          * @since 1.0
0138          * @javascript Re-compilers must resolve the member of this instance field to the 
0139          * identifier of the field name appending to the identifier resolved from its 
0140          * qualifying member with a dot in between.
0141          */
0142         public final JsFunction.Member<JsNumber> constructor = new JsFunction.Member<JsNumber>(this, Members.constructor, Generic.get(JsNumber.class));
0143     }
0144 
0145     /**
0146      * <p>Internally constructs a number object.</p>
0147      * <p>This constructor is <b>internal</b> and only called inside of <b>opaque</b> or 
0148      * <b>internal</b> classes or class members.</p>
0149      * @since 1.0
0150      * @javascript Re-compilers must report error on the invocation to an <b>internal</b> constructor. 
0151      */
0152     protected JsNumber(Object var) {
0153         super((JsObject)var);
0154     }
0155     /**
0156      * <p>Casts an <b>opaque</b> object to the current <b>opaque</b> type by wrapping it 
0157      * with the wrapping constructor.</p>
0158      * @param var The argument of an <b>opaque</b> object.
0159      * @since 1.0
0160      * @javascript Re-compilers must ignore the construction operation of this constructor, 
0161      * that is, replacing it with its only argument.
0162      */
0163     public JsNumber(JsObject var) {
0164         super(var(var, (JsNumber)null));
0165     }
0166     /**
0167      * <p>Casts a number value to the current <b>opaque</b> type by wrapping it with the 
0168      * wrapping constructor.</p>
0169      * @param var The argument of a number.
0170      * @since 1.0
0171      * @javascript Re-compilers must ignore the construction operation of this constructor, 
0172      * that is, replacing it with its only argument.
0173      */
0174     public JsNumber(Number var) {
0175         this(JsGlobal.Number.with().create(var));
0176     }
0177     /**
0178      * <p>Casts a number value to the current <b>opaque</b> type by wrapping it with the 
0179      * wrapping constructor.</p>
0180      * @param var The argument of a number.
0181      * @since 1.0
0182      * @javascript Re-compilers must ignore the construction operation of this constructor, 
0183      * that is, replacing it with its only argument.
0184      */
0185     public JsNumber(Value<? extends Number> var) {
0186         this(JsGlobal.Number.with().create(var));
0187     }
0188 
0189     /**
0190      * <p>Simply returns the current number instance.</p>
0191      * <p>This method is useful for JS Simulation to implement opaque types.</p>
0192      * @return The current number instance.
0193      * @since 1.0
0194      * @javascript Re-compilers must ignore the instance invocation of this method, that is, 
0195      * replacing it with its current instance.
0196      */
0197     @Override
0198     public JsNumber var() {
0199         return (JsNumber)super.var();
0200     }
0201     /**
0202      * <p>Assigns the value of another number instance to the current number object.</p>
0203      * @param var The argument number instance.
0204      * @return The new instance.
0205      * @since 1.0
0206      * @javascript Re-compilers must convert the instance invocation of this method into 
0207      * the JavaScript expression: 
0208      * <pre>o = var</pre>
0209      * where <tt>o</tt> is the current instance of the invocation of this method.
0210      */
0211     @Override
0212     public final <S extends JsObject> S var(S var) {
0213         var(var, (JsNumber)null);
0214         return var;
0215     }
0216 
0217     /**
0218      * <p>An <b>opaque</b> static field defining a member that is named by the field name 
0219      * without a qualifying member and to access the property of the name on an object.</p>
0220      * <p>The <tt>constructor</tt> property of an object is a reference to the function 
0221      * that was the constructor for that object.</p>
0222      * <p>A common use of the <tt>constructor</tt> property is to determine the type of unknown 
0223      * objects. Given an unknown value, you can use the {@link js.Js#typeof(Object)} operation 
0224      * to determine whether it is a primitive value or an object. If it is an object, you can 
0225      * use the <tt>constructor</tt> property to determine what type of object it is.</p>
0226      * <p>Note, however, that while this technique works for the objects built into core 
0227      * JavaScript, it is not guaranteed to work with host objects such as the <tt>window</tt> 
0228      * object of client-side JavaScript. The default implementation of the <tt>toString()</tt> 
0229      * method provides another way to determine the type of an unknown object.</p>
0230      * @since 1.0
0231      * @javascript Re-compilers must resolve the member of this static field to the 
0232      * identifier of the field name.
0233      */
0234     public static final JsFunction.Member<JsNumber> constructor = new JsFunction.Member<JsNumber>(Members.constructor, Generic.get(JsNumber.class));
0235 
0236 
0237     /**
0238      * <p>Converts the current number to a string using exponential notation.</p>
0239      * @return A string representation of the current number, in exponential notation. The 
0240      * fractional part of the number is rounded, or padded with zeros, as necessary, so that 
0241      * it has the specified length.
0242      * @throws RuntimeException JavaScript throws a <tt>TypeError</tt> if this method 
0243      * is invoked on an instance that is not a number. See {@link Js#err(Object)} and 
0244      * {@link js.core.JsTypeError} for JS Simulation.
0245      * @see #toExponential(Object)
0246      * @see #toFixed()
0247      * @see #toFixed(Object)
0248      * @see #toLocaleString()
0249      * @see #toPrecision()
0250      * @see #toPrecision(Object)
0251      * @see #toString()
0252      * @see #toString(Object)
0253      * @see jsx.core.NumberLikes#toExponential(NumberLike)
0254      * @see jsx.core.NumberLikes#toExponential(Number)
0255      * @since 1.0
0256      * @javascript Re-compilers must convert the instance invocation of this method directly 
0257      * into a JavaScript invocation on its current primitive instance without changing the 
0258      * method name, but expanding variable arguments, if any, into comma-separated values. 
0259      */
0260     public final String toExponential() {
0261         return call(toExponential);
0262     }
0263 
0264     /**
0265      * <p>Converts the current number to a string using exponential notation with the 
0266      * specified number of digits after the decimal place.</p>
0267      * @param digits The number of digits that appears after the decimal point. This may be a 
0268      * value between 0 and 20, inclusive, and implementations may optionally support a larger 
0269      * range of values. If this argument is undefined, as many digits as necessary are used.
0270      * @return A string representation of the current number, in exponential notation, 
0271      * with one digit before the decimal place and <tt>digits</tt> digits after the 
0272      * decimal place. The fractional part of the number is rounded, or padded with zeros, 
0273      * as necessary, so that it has the specified length.
0274      * @throws RuntimeException JavaScript throws a <tt>RangeError</tt> if 
0275      * <tt>digits</tt> is too small or too large. See {@link Js#err(Object)} and 
0276      * {@link js.core.JsRangeError} for JS Simulation. Values between 0 and 20, inclusive, 
0277      * will not cause a <tt>RangeError</tt>. Implementations are allowed to support 
0278      * larger and smaller values as well.
0279      * @throws RuntimeException JavaScript throws a <tt>TypeError</tt> if this method 
0280      * is invoked on an instance that is not a number. See {@link Js#err(Object)} and 
0281      * {@link js.core.JsTypeError} for JS Simulation.
0282      * @see #toExponential()
0283      * @see #toFixed()
0284      * @see #toFixed(Object)
0285      * @see #toLocaleString()
0286      * @see #toPrecision()
0287      * @see #toPrecision(Object)
0288      * @see #toString()
0289      * @see #toString(Object)
0290      * @see jsx.core.NumberLikes#toExponential(NumberLike, Object)
0291      * @see jsx.core.NumberLikes#toExponential(Number, Object)
0292      * @since 1.0
0293      * @javascript Re-compilers must convert the instance invocation of this method directly 
0294      * into a JavaScript invocation on its current primitive instance without changing the 
0295      * method name, but expanding variable arguments, if any, into comma-separated values. 
0296      */
0297     public final String toExponential(Object digits) {
0298         return call(toExponential, digits);
0299     }
0300 
0301     /**
0302      * <p>Converts the current number to a string without digits after the decimal place.</p>
0303      * @return A string representation of the current number that does not use exponential 
0304      * notation and has no digits after the decimal place. The number is rounded if 
0305      * necessary. If the current number is greater than 1e+21, this method simply calls 
0306      * {@link #toString()} and returns a string in exponential notation.
0307      * @throws RuntimeException JavaScript throws a <tt>TypeError</tt> if this method 
0308      * is invoked on an instance that is not a number. See {@link Js#err(Object)} and 
0309      * {@link js.core.JsTypeError} for JS Simulation.
0310      * @see jsx.core.NumberLikes#toFixed(NumberLike)
0311      * @see jsx.core.NumberLikes#toFixed(NumberLike, Object)
0312      * @see jsx.core.NumberLikes#toFixed(Number)
0313      * @see jsx.core.NumberLikes#toFixed(Number, Object)
0314      * @see #toFixed(Object)
0315      * @see #toExponential()
0316      * @see #toExponential(Object)
0317      * @see #toLocaleString()
0318      * @see #toPrecision()
0319      * @see #toPrecision(Object)
0320      * @see #toString()
0321      * @see #toString(Object)
0322      * @see jsx.core.NumberLikes#toFixed(NumberLike)
0323      * @see jsx.core.NumberLikes#toFixed(Number)
0324      * @since 1.0
0325      * @javascript Re-compilers must convert the instance invocation of this method directly 
0326      * into a JavaScript invocation on its current primitive instance without changing the 
0327      * method name, but expanding variable arguments, if any, into comma-separated values. 
0328      */
0329     public final String toFixed() {
0330         return call(toFixed);
0331     }
0332 
0333     /**
0334      * <p>Converts the current number to a string that contains a specified number of 
0335      * digits after the decimal place.</p>
0336      * @param digits The number of digits to appear after the decimal point; this may be a 
0337      * value between 0 and 20, inclusive, and implementations may optionally support a 
0338      * larger range of values. If this argument is undefined, it is treated as 0.
0339      * @return A string representation of the current number that does not use exponential 
0340      * notation and has exactly <tt>digits</tt> digits after the decimal place. The number 
0341      * is rounded if necessary, and the fractional part is padded with zeros if necessary so 
0342      * that it has the specified length. If the current number is greater than 1e+21, this 
0343      * method simply calls {@link #toString()} and returns a string in exponential 
0344      * notation.
0345      * @throws RuntimeException JavaScript throws a <tt>RangeError</tt> if 
0346      * <tt>digits</tt> is too small or too large. See {@link Js#err(Object)} and 
0347      * {@link js.core.JsRangeError} for JS Simulation. Values between 0 and 20, inclusive, 
0348      * will not cause a <tt>RangeError</tt>. Implementations are allowed to support 
0349      * larger and smaller values as well.
0350      * @throws RuntimeException JavaScript throws a <tt>TypeError</tt> if this method 
0351      * is invoked on an instance that is not a number. See {@link Js#err(Object)} and 
0352      * {@link js.core.JsTypeError} for JS Simulation.
0353      * @see #toFixed()
0354      * @see #toExponential()
0355      * @see #toExponential(Object)
0356      * @see #toLocaleString()
0357      * @see #toPrecision()
0358      * @see #toPrecision(Object)
0359      * @see #toString()
0360      * @see #toString(Object)
0361      * @see jsx.core.NumberLikes#toFixed(NumberLike, Object)
0362      * @see jsx.core.NumberLikes#toFixed(Number, Object)
0363      * @since 1.0
0364      * @javascript Re-compilers must convert the instance invocation of this method directly 
0365      * into a JavaScript invocation on its current primitive instance without changing the 
0366      * method name, but expanding variable arguments, if any, into comma-separated values. 
0367      */
0368     public final String toFixed(Object digits) {
0369         return call(toFixed, digits);
0370     }
0371 
0372     /**
0373      * <p>Converts the current number to a string.</p>
0374      * <p>This method simply calls {@link #toString()} to convert the number to a base-10 
0375      * value.</p>
0376      * @return A string representation of the current number. The number is rounded or 
0377      * padded with zeros as necessary.
0378      * @throws RuntimeException JavaScript throws a <tt>TypeError</tt> if this method 
0379      * is invoked on an instance that is not a number. See {@link Js#err(Object)} and 
0380      * {@link js.core.JsTypeError} for JS Simulation.
0381      * @see #toPrecision(Object)
0382      * @see #toExponential()
0383      * @see #toExponential(Object)
0384      * @see #toFixed()
0385      * @see #toFixed(Object)
0386      * @see #toLocaleString()
0387      * @see #toString()
0388      * @see #toString(Object)
0389      * @see jsx.core.NumberLikes#toPrecision(NumberLike)
0390      * @see jsx.core.NumberLikes#toPrecision(Number)
0391      * @since 1.0
0392      * @javascript Re-compilers must convert the instance invocation of this method directly 
0393      * into a JavaScript invocation on its current primitive instance without changing the 
0394      * method name, but expanding variable arguments, if any, into comma-separated values. 
0395      */
0396     public final String toPrecision() {
0397         return call(toPrecision);
0398     }
0399 
0400     /**
0401      * <p>Converts the current number to a string using the specified number of significant 
0402      * digits. Uses exponential or fixed-point notation depending on the size of the number 
0403      * and the number of significant digits specified.</p>
0404      * @param precision The number of significant digits to appear in the returned string. 
0405      * This may be a value between 1 and 21, inclusive. Implementations are allowed to 
0406      * optionally support larger and smaller values of precision. If this argument is 
0407      * undefined, the {@link #toString()} method is used instead to convert the number to 
0408      * a base-10 value.
0409      * @return A string representation of the current number that contains 
0410      * <tt>precision</tt> significant digits. If <tt>precision</tt> is large 
0411      * enough to include all the digits of the integer part of the number, the returned 
0412      * string uses fixed-point notation. Otherwise, exponential notation is used with one 
0413      * digit before the decimal place and <tt>precision - 1</tt> digits after the 
0414      * decimal place. The number is rounded or padded with zeros as necessary.
0415      * @throws RuntimeException JavaScript throws a <tt>RangeError</tt> if 
0416      * <tt>digits</tt> is too small or too large. See {@link Js#err(Object)} and 
0417      * {@link js.core.JsRangeError} for JS Simulation. Values between 1 and 20, inclusive, 
0418      * will not cause a <tt>RangeError</tt>. Implementations are allowed to support 
0419      * larger and smaller values as well.
0420      * @throws RuntimeException JavaScript throws a <tt>TypeError</tt> if this method 
0421      * is invoked on an instance that is not a number. See {@link Js#err(Object)} and 
0422      * {@link js.core.JsTypeError} for JS Simulation.
0423      * @see #toPrecision()
0424      * @see #toExponential()
0425      * @see #toExponential(Object)
0426      * @see #toFixed()
0427      * @see #toFixed(Object)
0428      * @see #toLocaleString()
0429      * @see #toString()
0430      * @see #toString(Object)
0431      * @see jsx.core.NumberLikes#toPrecision(NumberLike, Object)
0432      * @see jsx.core.NumberLikes#toPrecision(Number, Object)
0433      * @since 1.0
0434      * @javascript Re-compilers must convert the instance invocation of this method directly 
0435      * into a JavaScript invocation on its current primitive instance without changing the 
0436      * method name, but expanding variable arguments, if any, into comma-separated values. 
0437      */
0438     public final String toPrecision(Object precision) {
0439         return call(toPrecision, precision);
0440     }
0441 
0442     /**
0443      * <p>Converts the current number to a string. When the <tt>radix</tt> argument is 
0444      * undefined or is specified as 10, the number is converted to a base-10 string.</p> 
0445      * <p>Although the ECMAScript specification does not require implementations to honor 
0446      * any other values for radix, all implementations in common use accept values between 
0447      * 2 and 36.</p>
0448      * @param radix An optional argument that specifies the radix, or base, between 2 and 36, 
0449      * in which the number should be represented. If undefined, base 10 is used. Note, 
0450      * however, that the ECMAScript specification allows an implementation to return any 
0451      * value if this argument is specified as any value other than 10.
0452      * @return A string representation of the current number, in the specified base.
0453      * @throws RuntimeException JavaScript throws a <tt>TypeError</tt> if this method 
0454      * is invoked on an instance that is not a number. See {@link Js#err(Object)} and 
0455      * {@link js.core.JsTypeError} for JS Simulation.
0456      * @see #toString()
0457      * @see #toExponential()
0458      * @see #toExponential(Object)
0459      * @see #toFixed()
0460      * @see #toFixed(Object)
0461      * @see #toPrecision()
0462      * @see #toPrecision(Object)
0463      * @see #toLocaleString()
0464      * @since 1.0
0465      * @javascript Re-compilers must convert the instance invocation of this method directly 
0466      * into a JavaScript invocation on its current primitive instance without changing the 
0467      * method name, but expanding variable arguments, if any, into comma-separated values. 
0468      */
0469     public final String toString(Object radix) {
0470         return call(toString, radix);
0471     }
0472 
0473     /**
0474      * <p>Returns the primitive value associated with the current instance, if there is one. 
0475      * This invocation returns the primitive number value associated with the current instance.</p>
0476      * @return The primitive number value associated with the current instance.
0477      * @throws RuntimeException JavaScript throws a <tt>TypeError</tt> if this method 
0478      * is invoked on an instance that is not a number. See {@link Js#err(Object)} and 
0479      * {@link js.core.JsTypeError} for JS Simulation.
0480      * @see #toString()
0481      * @since 1.0
0482      * @javascript Re-compilers must convert the instance invocation of this method directly 
0483      * into a JavaScript invocation on its current number instance without changing the 
0484      * method name, but expanding variable arguments, if any, into comma-separated values. 
0485      */
0486     @Override
0487     public Number valueOf() {
0488         return var().valueOf();
0489     }
0490 
0491     /**
0492      * <p>Logically evaluates the current number instance.</p>
0493      * @return The logical value of the current number instance.
0494      * @since 1.0
0495      * @javascript Re-compilers must ignore the instance invocation of this method, that is, 
0496      * replacing it with its current date instance.
0497      */
0498     public final boolean be() {
0499         return Js.be(var());
0500     }
0501 
0502     /**
0503      * <p>Performs unary negation, resembling the unary minus operator in JavaScript.</p>
0504      * <p>This operation converts a positive value to an equivalently negative value, and 
0505      * vice versa. If the operand is not a number, it attempts to convert it to one.</p>
0506      * @return The negation of the current number instance.
0507      * @since 1.0
0508      * @javascript Re-compilers must replace the instance invocation of this method with the 
0509      * JavaScript expression:
0510      * <pre>-d</pre>
0511      * where <tt>d</tt> is the current number instance of the invocation of this 
0512      * method.
0513      */
0514     public final Number neg() {
0515         return Js.neg(this);
0516     }
0517 
0518     /**
0519      * <p>Inverts the boolean value of the current number instance, resembling the logical 
0520      * NOT operator in JavaScript.</p>
0521      * <p>This operation converts the current number instance to a boolean value using 
0522      * the following rules if necessary before inverting the converted value.</p>
0523      * <ul>
0524      * <li>If a number is used where a boolean value is expected, the number is converted 
0525      * to <tt>true</tt> unless the number is 0 or NaN, which are converted to <tt>false</tt>.</li>
0526      * <li>If a string is used where a boolean value is expected, it is converted to <tt>true</tt> 
0527      * except for the empty string, which is converted to <tt>false</tt>.</li>
0528      * <li><tt>null</tt> and the undefined value convert to <tt>false</tt>, and any 
0529      * non-null object, array, or function converts to <tt>true</tt>.
0530      * </ul>
0531      * <p>You can convert any value <tt>x</tt> to its equivalent boolean value by applying 
0532      * this operation twice: <tt>Js.not(Js.not(x))</tt></p>
0533      * <p>Note that, this method is probably useful in emulation codes just for perfect 
0534      * re-compilations. However, in most cases you can use the logical NOT operator of the 
0535      * Java language like this:
0536      * <pre>!Js.be(var)</pre>
0537      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
0538      * JavaScript expression since the Java compilers generally used are free to compile 
0539      * the expression into any byte codes they think efficient, making it too hard for the 
0540      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
0541      * @return The inverted boolean value.
0542      * @since 1.0
0543      * @javascript Re-compilers must replace the instance invocation of this method with the 
0544      * JavaScript expression:
0545      * <pre>!d</pre>
0546      * where <tt>d</tt> is the current number instance of the invocation of this method.
0547      */
0548     public final boolean not() {
0549         return Js.not(this);
0550     }
0551 
0552     /**
0553      * <p>Bitwise-NOT operation, resembling that of JavaScript, operates by reversing all 
0554      * bits in the current number instance.</p>
0555      * <p>Because of the way signed integers are represented in JavaScript, applying this 
0556      * operation to a value is equivalent to changing its sign and subtracting 1.</p>
0557      * <p>Despite the fact that all numbers in JavaScript are floating-point numbers, the bitwise 
0558      * operation requires numeric operands that have integer values. It operate on the integer 
0559      * values using a 32-bit integer representation instead of the equivalent floating-point 
0560      * representation.</p>
0561      * <p>If this bitwise operation is used with the current number instance that are 
0562      * not integers or are too large to fit in a 32-bit integer representation, it simply 
0563      * coerces them to 32-bit integers by dropping any fractional part of the value or any 
0564      * bits beyond the 32nd.</p>
0565      * @return The bitwise-NOT of the current number instance.
0566      * @since 1.0
0567      * @javascript Re-compilers must replace the instance invocation of this method with the 
0568      * JavaScript expression:
0569      * <pre>~d</pre>
0570      * where <tt>d</tt> is the current number instance of the invocation of this method.
0571      */
0572     public final int bnot() {
0573         return Js.bnot(valueOf());
0574     }
0575 
0576     /**
0577      * <p>Multiplies the value of the current number instance with the operand, resembling 
0578      * the multiplication operator in JavaScript.</p>
0579      * <p>If used with non-numeric values, this operation attempts to convert them to 
0580      * numbers.</p>
0581      * @param other Any numeric value.
0582      * @return The product of the current number instance and the operand.
0583      * @since 1.0
0584      * @javascript Re-compilers must replace the instance invocation of this method with the 
0585      * JavaScript expression:
0586      * <pre>d * other</pre>
0587      * where <tt>d</tt> is the current number instance of the invocation of this method.
0588      */
0589     public final Number mul(Object other) {
0590         return Js.mul(this, other);
0591     }
0592 
0593     /**
0594      * <p>Divides the value of the current number instance by the operand, resembling the 
0595      * division operator in JavaScript.</p>
0596      * <p>Used with non-numeric values, this operation attempts to convert them to 
0597      * numbers. If you are used to programming languages that distinguish between integer 
0598      * and floating-point numbers, you might expect to get an integer result when you 
0599      * divide one integer by another. In JavaScript, however, all numbers are floating-point, 
0600      * so all division operations have floating-point results. Division by zero yields positive 
0601      * or negative infinity, while <tt>0/0</tt> evaluates to <tt>NaN</tt>.</p>
0602      * @param other Any numeric value.
0603      * @return The quotient of the current number instance and the operand.
0604      * @since 1.0
0605      * @javascript Re-compilers must replace the instance invocation of this method with the 
0606      * JavaScript expression:
0607      * <pre>d / other</pre>
0608      * where <tt>d</tt> is the current number instance of the invocation of this method.
0609      */
0610     public final Number div(Object other) {
0611         return Js.div(this, other);
0612     }
0613 
0614     /**
0615      * <p>Computes the value of the current number instance modulo the operand, resembling 
0616      * the modulo operator in JavaScript.</p>
0617      * <p>The operation returns the remainder when the current number instance is divided 
0618      * by the operand a certain number of times. If used with non-numeric values, the 
0619      * operation attempts to convert them to numbers. The sign of the result is the same 
0620      * as the sign of the current number instance.</p>
0621      * <p>This operation is typically used with integer values, it also works for 
0622      * floating-point values.</p>
0623      * @param other Any numeric value.
0624      * @return The remainder.
0625      * @since 1.0
0626      * @javascript Re-compilers must replace the instance invocation of this method with the 
0627      * JavaScript expression:
0628      * <pre>d % other</pre>
0629      * where <tt>d</tt> is the current number instance of the invocation of this method.
0630      */
0631     public final Number mod(Object other) {
0632         return Js.mod(this, other);
0633     }
0634 
0635     /**
0636      * <p>Subtracts the operand from the value of the current number instance, resembling 
0637      * the subtraction operator in JavaScript.</p>
0638      * <p>If used with non-numeric values, this operation attempts to convert them to 
0639      * numbers.</p>
0640      * @param other Any numeric value.
0641      * @return The difference between the current number instance and the operand.
0642      * @since 1.0
0643      * @javascript Re-compilers must replace the instance invocation of this method with the 
0644      * JavaScript expression:
0645      * <pre>d - other</pre>
0646      * where <tt>d</tt> is the current number instance of the invocation of this method.
0647      */
0648     public final Number sub(Object other) {
0649         return Js.sub(this, other);
0650     }
0651 
0652     /**
0653      * <p>Adds the current number instance to a numeric operand or concatenates it with 
0654      * a string operand, resembling the addition operator in JavaScript.</p>
0655      * <p>If one value is a string, the other is converted to a string, and the two 
0656      * strings are then concatenated. Object operands are converted to numbers or strings 
0657      * that can be added or concatenated. The conversion is performed by {@link Js#valueOf(Object)}  
0658      * method and/or the {@link Js#toString(Object)} method on the object.</p>
0659      * @param other A value or object.
0660      * @return The sum or concatenation of the values.
0661      * @since 1.0
0662      * @javascript Re-compilers must replace the instance invocation of this method with the 
0663      * JavaScript expression:
0664      * <pre>d + other</pre>
0665      * where <tt>d</tt> is the current number instance of the invocation of this method.
0666      */
0667     public Object add(Object other) {
0668         return Js.add(this, other);
0669     }
0670 
0671     /**
0672      * <p>Adds the current number instance to a numeric operand or concatenates it with 
0673      * a string operand, resembling the addition operator in JavaScript.</p>
0674      * <p>If one value is a string, the other is converted to a string, and the two 
0675      * strings are then concatenated. Object operands are converted to numbers or strings 
0676      * that can be added or concatenated. The conversion is performed by {@link Js#valueOf(Object)}  
0677      * method and/or the {@link Js#toString(Object)} method on the object.</p>
0678      * @param other A value or object.
0679      * @return The sum or concatenation of the values.
0680      * @since 1.0
0681      * @javascript Re-compilers must replace the instance invocation of this method with the 
0682      * JavaScript expression:
0683      * <pre>d + other</pre>
0684      * where <tt>d</tt> is the current number instance of the invocation of this method.
0685      */
0686     public final String add(String other) {
0687         return Js.add(this, other);
0688     }
0689 
0690     /**
0691      * <p>Adds the current number instance to a numeric operand or concatenates it with 
0692      * a string operand, resembling the addition operator in JavaScript.</p>
0693      * <p>If one value is a string, the other is converted to a string, and the two 
0694      * strings are then concatenated. Object operands are converted to numbers or strings 
0695      * that can be added or concatenated. The conversion is performed by {@link Js#valueOf(Object)}  
0696      * method and/or the {@link Js#toString(Object)} method on the object.</p>
0697      * @param other A value or object.
0698      * @return The sum or concatenation of the values.
0699      * @since 1.0
0700      * @javascript Re-compilers must replace the instance invocation of this method with the 
0701      * JavaScript expression:
0702      * <pre>d + other</pre>
0703      * where <tt>d</tt> is the current number instance of the invocation of this method.
0704      */
0705     public final String add(Value<String> other) {
0706         return Js.add(this, other.var());
0707     }
0708 
0709     /**
0710      * <p>Less-than operation, resembling that of JavaScript, evaluates to <tt>true</tt> if 
0711      * the current number instance is less than the second operand; otherwise it 
0712      * evaluates to <tt>false</tt>.</p>
0713      * <p>The operands of this operation may be of any type. Comparison can be performed 
0714      * only on numbers and strings, however, so operands that are not numbers or strings 
0715      * are converted. Comparison and conversion occur as follows:</p>
0716      * <ul>
0717      * <li>If both operands are numbers, or if both convert to numbers, they are compared 
0718      * numerically.</li>
0719      * <li>If both operands are strings or convert to strings, they are compared as 
0720      * strings.</li>
0721      * <li>If one operand is or converts to a string, and one is or converts to a number, 
0722      * the operation attempts to convert the string to a number and performs a numerical 
0723      * comparison. If the string does not represent a number, it converts to <tt>NaN</tt>, 
0724      * and the comparison is <tt>false</tt>. In JavaScript 1.1, the string-to-number 
0725      * conversion causes an error instead of yielding <tt>NaN</tt>.</li>
0726      * <li>If an object can be converted to either a number or a string, JavaScript performs 
0727      * the numerical conversion. This means, for example, that Date objects are compared 
0728      * numerically, and it is meaningful to compare two dates to see whether one is earlier 
0729      * than the other.</li>
0730      * <li>If the operands of the comparison operations cannot both be successfully converted 
0731      * to numbers or to strings, these operations always return <tt>false</tt>.</li>
0732      * <li>If either operand is or converts to <tt>NaN</tt>, the comparison operation always 
0733      * yields <tt>false</tt>.</li>
0734      * </ul>
0735      * <p>Keep in mind that string comparison is done on a strict character-by-character 
0736      * basis using the numerical value of each character from the Unicode encoding. Although 
0737      * in some cases the Unicode standard allows equivalent strings to be encoded using 
0738      * different sequences of characters, the JavaScript comparison operations do not 
0739      * detect these encoding differences; they assume that all strings are expressed in 
0740      * normalized form. Note in particular that string comparison is case-sensitive, and 
0741      * in the Unicode encoding (at least for the ASCII subset), all capital letters are 
0742      * "less than" all lowercase letters. This rule can cause confusing results if you do 
0743      * not expect it.</p>
0744      * <p>For a more robust string-comparison algorithm, see the {@link StringLike#localeCompare(Object)} 
0745      * method, which also takes locale-specific definitions of alphabetical order into account. 
0746      * For case-insensitive comparisons, you must first convert the strings to all lowercase or 
0747      * all uppercase using {@link StringLike#toLowerCase()} or {@link StringLike#toUpperCase()}.</p>
0748      * <p>The less-than-or-equal and greater-than-or-equal operations do not rely on the 
0749      * equality or identity operations for determining whether two values are "equal." 
0750      * Instead, the less-than-or-equal operator is simply defined as "not greater than", 
0751      * and the greater-than-or-equal operator is defined as "not less than". The one 
0752      * exception occurs when either operand is (or converts to) <tt>NaN</tt>, in which case 
0753      * all comparison operations return <tt>false</tt>.</p>
0754      * @param other A value or object.
0755      * @return <tt>true</tt> if the current number instance is less than the second 
0756      * operand; otherwise <tt>false</tt>.
0757      * @since 1.0
0758      * @javascript Re-compilers must replace the instance invocation of this method with the 
0759      * JavaScript expression:
0760      * <pre>d < other</pre>
0761      * where <tt>d</tt> is the current number instance of the invocation of this method.
0762      */
0763     public final boolean lt(Object other) {
0764         return Js.lt(valueOf(), other);
0765     }
0766 
0767     /**
0768      * <p>Greater-than operation, resembling that of JavaScript, evaluates to <tt>true</tt> if 
0769      * the current number instance is greater than the second operand; otherwise it 
0770      * evaluates to <tt>false</tt>.</p>
0771      * <p>The operands of this operation may be of any type. Comparison can be performed 
0772      * only on numbers and strings, however, so operands that are not numbers or strings 
0773      * are converted. Comparison and conversion occur as follows:</p>
0774      * <ul>
0775      * <li>If both operands are numbers, or if both convert to numbers, they are compared 
0776      * numerically.</li>
0777      * <li>If both operands are strings or convert to strings, they are compared as 
0778      * strings.</li>
0779      * <li>If one operand is or converts to a string, and one is or converts to a number, 
0780      * the operation attempts to convert the string to a number and performs a numerical 
0781      * comparison. If the string does not represent a number, it converts to <tt>NaN</tt>, 
0782      * and the comparison is <tt>false</tt>. In JavaScript 1.1, the string-to-number 
0783      * conversion causes an error instead of yielding <tt>NaN</tt>.</li>
0784      * <li>If an object can be converted to either a number or a string, JavaScript performs 
0785      * the numerical conversion. This means, for example, that Date objects are compared 
0786      * numerically, and it is meaningful to compare two dates to see whether one is earlier 
0787      * than the other.</li>
0788      * <li>If the operands of the comparison operations cannot both be successfully converted 
0789      * to numbers or to strings, these operations always return <tt>false</tt>.</li>
0790      * <li>If either operand is or converts to <tt>NaN</tt>, the comparison operation always 
0791      * yields <tt>false</tt>.</li>
0792      * </ul>
0793      * <p>Keep in mind that string comparison is done on a strict character-by-character 
0794      * basis using the numerical value of each character from the Unicode encoding. Although 
0795      * in some cases the Unicode standard allows equivalent strings to be encoded using 
0796      * different sequences of characters, the JavaScript comparison operations do not 
0797      * detect these encoding differences; they assume that all strings are expressed in 
0798      * normalized form. Note in particular that string comparison is case-sensitive, and 
0799      * in the Unicode encoding (at least for the ASCII subset), all capital letters are 
0800      * "less than" all lowercase letters. This rule can cause confusing results if you do 
0801      * not expect it.</p>
0802      * <p>For a more robust string-comparison algorithm, see the {@link StringLike#localeCompare(Object)} 
0803      * method, which also takes locale-specific definitions of alphabetical order into account. 
0804      * For case-insensitive comparisons, you must first convert the strings to all lowercase or 
0805      * all uppercase using {@link StringLike#toLowerCase()} or {@link StringLike#toUpperCase()}.</p>
0806      * <p>The less-than-or-equal and greater-than-or-equal operations do not rely on the 
0807      * equality or identity operations for determining whether two values are "equal." 
0808      * Instead, the less-than-or-equal operator is simply defined as "not greater than", 
0809      * and the greater-than-or-equal operator is defined as "not less than". The one 
0810      * exception occurs when either operand is (or converts to) <tt>NaN</tt>, in which case 
0811      * all comparison operations return <tt>false</tt>.</p>
0812      * @param other A value or object.
0813      * @return <tt>true</tt> if the current number instance is greater than the second 
0814      * operand; otherwise <tt>false</tt>.
0815      * @since 1.0
0816      * @javascript Re-compilers must replace the instance invocation of this method with the 
0817      * JavaScript expression:
0818      * <pre>p > other</pre>
0819      * where <tt>p</tt> is the current number instance of the invocation of this method.
0820      */
0821     public final boolean gt(Object other) {
0822         return Js.gt(valueOf(), other);
0823     }
0824 
0825     /**
0826      * <p>Less-than-or-equal operation, resembling that of JavaScript, evaluates to 
0827      * <tt>true</tt> if the current number instance is less than or equal to the second 
0828      * operand; otherwise it evaluates to <tt>false</tt>.</p>
0829      * <p>The operands of this operation may be of any type. Comparison can be performed 
0830      * only on numbers and strings, however, so operands that are not numbers or strings 
0831      * are converted. Comparison and conversion occur as follows:</p>
0832      * <ul>
0833      * <li>If both operands are numbers, or if both convert to numbers, they are compared 
0834      * numerically.</li>
0835      * <li>If both operands are strings or convert to strings, they are compared as 
0836      * strings.</li>
0837      * <li>If one operand is or converts to a string, and one is or converts to a number, 
0838      * the operation attempts to convert the string to a number and performs a numerical 
0839      * comparison. If the string does not represent a number, it converts to <tt>NaN</tt>, 
0840      * and the comparison is <tt>false</tt>. In JavaScript 1.1, the string-to-number 
0841      * conversion causes an error instead of yielding <tt>NaN</tt>.</li>
0842      * <li>If an object can be converted to either a number or a string, JavaScript performs 
0843      * the numerical conversion. This means, for example, that Date objects are compared 
0844      * numerically, and it is meaningful to compare two dates to see whether one is earlier 
0845      * than the other.</li>
0846      * <li>If the operands of the comparison operations cannot both be successfully converted 
0847      * to numbers or to strings, these operations always return <tt>false</tt>.</li>
0848      * <li>If either operand is or converts to <tt>NaN</tt>, the comparison operation always 
0849      * yields <tt>false</tt>.</li>
0850      * </ul>
0851      * <p>Keep in mind that string comparison is done on a strict character-by-character 
0852      * basis using the numerical value of each character from the Unicode encoding. Although 
0853      * in some cases the Unicode standard allows equivalent strings to be encoded using 
0854      * different sequences of characters, the JavaScript comparison operations do not 
0855      * detect these encoding differences; they assume that all strings are expressed in 
0856      * normalized form. Note in particular that string comparison is case-sensitive, and 
0857      * in the Unicode encoding (at least for the ASCII subset), all capital letters are 
0858      * "less than" all lowercase letters. This rule can cause confusing results if you do 
0859      * not expect it.</p>
0860      * <p>For a more robust string-comparison algorithm, see the {@link StringLike#localeCompare(Object)} 
0861      * method, which also takes locale-specific definitions of alphabetical order into account. 
0862      * For case-insensitive comparisons, you must first convert the strings to all lowercase or 
0863      * all uppercase using {@link StringLike#toLowerCase()} or {@link StringLike#toUpperCase()}.</p>
0864      * <p>The less-than-or-equal and greater-than-or-equal operations do not rely on the 
0865      * equality or identity operations for determining whether two values are "equal." 
0866      * Instead, the less-than-or-equal operator is simply defined as "not greater than", 
0867      * and the greater-than-or-equal operator is defined as "not less than". The one 
0868      * exception occurs when either operand is (or converts to) <tt>NaN</tt>, in which case 
0869      * all comparison operations return <tt>false</tt>.</p>
0870      * @param other A value or object.
0871      * @return <tt>true</tt> if the current number instance is less than or equal to 
0872      * the second operand; otherwise <tt>false</tt>.
0873      * @since 1.0
0874      * @javascript Re-compilers must replace the instance invocation of this method with the 
0875      * JavaScript expression:
0876      * <pre>p <= other</pre>
0877      * where <tt>p</tt> is the current number instance of the invocation of this method.
0878      */
0879     public final boolean lte(Object other) {
0880         return Js.lte(valueOf(), other);
0881     }
0882 
0883     /**
0884      * <p>Greater-than-or-equal operation, resembling that of JavaScript, evaluates to 
0885      * <tt>true</tt> if the current number instance is greater than or equal to the 
0886      * second operand; otherwise it evaluates to <tt>false</tt>.</p>
0887      * <p>The operands of this operation may be of any type. Comparison can be performed 
0888      * only on numbers and strings, however, so operands that are not numbers or strings 
0889      * are converted. Comparison and conversion occur as follows:</p>
0890      * <ul>
0891      * <li>If both operands are numbers, or if both convert to numbers, they are compared 
0892      * numerically.</li>
0893      * <li>If both operands are strings or convert to strings, they are compared as 
0894      * strings.</li>
0895      * <li>If one operand is or converts to a string, and one is or converts to a number, 
0896      * the operation attempts to convert the string to a number and performs a numerical 
0897      * comparison. If the string does not represent a number, it converts to <tt>NaN</tt>, 
0898      * and the comparison is <tt>false</tt>. In JavaScript 1.1, the string-to-number 
0899      * conversion causes an error instead of yielding <tt>NaN</tt>.</li>
0900      * <li>If an object can be converted to either a number or a string, JavaScript performs 
0901      * the numerical conversion. This means, for example, that Date objects are compared 
0902      * numerically, and it is meaningful to compare two dates to see whether one is earlier 
0903      * than the other.</li>
0904      * <li>If the operands of the comparison operations cannot both be successfully converted 
0905      * to numbers or to strings, these operations always return <tt>false</tt>.</li>
0906      * <li>If either operand is or converts to <tt>NaN</tt>, the comparison operation always 
0907      * yields <tt>false</tt>.</li>
0908      * </ul>
0909      * <p>Keep in mind that string comparison is done on a strict character-by-character 
0910      * basis using the numerical value of each character from the Unicode encoding. Although 
0911      * in some cases the Unicode standard allows equivalent strings to be encoded using 
0912      * different sequences of characters, the JavaScript comparison operations do not 
0913      * detect these encoding differences; they assume that all strings are expressed in 
0914      * normalized form. Note in particular that string comparison is case-sensitive, and 
0915      * in the Unicode encoding (at least for the ASCII subset), all capital letters are 
0916      * "less than" all lowercase letters. This rule can cause confusing results if you do 
0917      * not expect it.</p>
0918      * <p>For a more robust string-comparison algorithm, see the {@link StringLike#localeCompare(Object)} 
0919      * method, which also takes locale-specific definitions of alphabetical order into account. 
0920      * For case-insensitive comparisons, you must first convert the strings to all lowercase or 
0921      * all uppercase using {@link StringLike#toLowerCase()} or {@link StringLike#toUpperCase()}.</p>
0922      * <p>The less-than-or-equal and greater-than-or-equal operations do not rely on the 
0923      * equality or identity operations for determining whether two values are "equal." 
0924      * Instead, the less-than-or-equal operator is simply defined as "not greater than", 
0925      * and the greater-than-or-equal operator is defined as "not less than". The one 
0926      * exception occurs when either operand is (or converts to) <tt>NaN</tt>, in which case 
0927      * all comparison operations return <tt>false</tt>.</p>
0928      * @param other A value or object.
0929      * @return <tt>true</tt> if the current number instance is greater than or equal to 
0930      * the second operand; otherwise <tt>false</tt>.
0931      * @since 1.0
0932      * @javascript Re-compilers must replace the instance invocation of this method with the 
0933      * JavaScript expression:
0934      * <pre>p >= other</pre>
0935      * where <tt>p</tt> is the current number instance of the invocation of this method.
0936      */
0937     public final boolean gte(Object other) {
0938         return Js.gte(valueOf(), other);
0939     }
0940 
0941     /**
0942      * <p>Checks if the current number instance is an instance of the second operand, 
0943      * resembling the <tt>instanceof</tt> operator in JavaScript.</p>
0944      * <p>This operation expects the first operand be an object and the second be a class 
0945      * of objects. In JavaScript, classes of objects are defined by the constructor function 
0946      * that initializes them.</p>
0947      * @param other A constructor function.
0948      * @return <tt>true</tt> if the current number instance is an instance of the second 
0949      * operand; <tt>false</tt>, otherwise;
0950      * @since 1.0
0951      * @javascript Re-compilers must replace the instance invocation of this method with the 
0952      * JavaScript expression:
0953      * <pre>p instanceof other</pre>
0954      * where <tt>p</tt> is the current number instance of the invocation of this method.
0955      */
0956     public final boolean instanceOf(Object other) {
0957         return Js.instanceOf(this, other);
0958     }
0959 
0960     /**
0961      * <p>Checks whether the two operands are "equal" using a more relaxed definition of 
0962      * sameness that allows type conversions, resembling the equality operator in 
0963      * JavaScript.</p>
0964      * <p>The equality and identity operations check whether two values are the same, using 
0965      * two different definitions of sameness. Both operations accept operands of any type, 
0966      * and both return <tt>true</tt> if their operands are the same and <tt>false</tt> 
0967      * if they are different. The identity operation checks whether its two operands are 
0968      * "identical" using a strict definition of sameness. The equality operation checks 
0969      * whether its two operands are "equal" using a more relaxed definition of sameness 
0970      * that allows type conversions.</p>
0971      * <p>The identity operation is standardized by ECMAScript v3 and implemented in 
0972      * JavaScript 1.3 and later. Be sure you understand the differences between the 
0973      * assignment, equality, and identity operations, and be careful to use the correct one 
0974      * when coding! Although it is tempting to call all three operations "equals," it may 
0975      * help to reduce confusion if you read "gets or is assigned" for assignment operation, 
0976      * "is equal to" for equality operation, and "is identical to" for identity operation.</p>
0977      * <p>In JavaScript, numbers, strings, and boolean values are compared by value. In this 
0978      * case, two separate values are involved, and the equality and identity operations 
0979      * check that these two values are identical. This means that two variables are equal 
0980      * or identical only if they contain the same value. For example, two strings are equal 
0981      * only if they each contain exactly the same characters.</p>
0982      * <p>On the other hand, objects, arrays, and functions are compared by reference. This 
0983      * means that two variables are equal only if they refer to the same object. Two 
0984      * separate arrays are never equal or identical, even if they contain equal or identical 
0985      * elements. Two variables that contain references to objects, arrays, or functions are 
0986      * equal only if they refer to the same object, array, or function. If you want to test 
0987      * that two distinct objects contain the same properties or that two distinct arrays 
0988      * contain the same elements, you'll have to check the properties or elements individually 
0989      * for equality or identity. And, if any of the properties or elements are themselves 
0990      * objects or arrays, you'll have to decide how deep you want the comparison to go.</p>
0991      * <p>The following rules determine whether two values are equal according to the 
0992      * equality operation:
0993      * <ul>
0994      * <li>If the two values have the same type, test them for identity. If the values are 
0995      * identical, they are equal; if they are not identical, they are not equal.</li>
0996      * <li>If the two values do not have the same type, they may still be equal. Use the 
0997      * following rules and type conversions to check for equality:</li>
0998      * <ul>
0999      * <li>If one value is null and the other is undefined, they are equal.</li>
1000      * <li>If one value is a number and the other is a string, convert the string to a 
1001      * number and try the comparison again, using the converted value.</li>
1002      * <li>If either value is <tt>true</tt>, convert it to 1 and try the comparison 
1003      * again. If either value is <tt>false</tt>, convert it to 0 and try the comparison 
1004      * again.</li>
1005      * <li>If one value is an object and the other is a number or string, convert the 
1006      * object to a primitive and try the comparison again. An object is converted to a 
1007      * primitive value by either its <tt>toString()</tt> method or its <tt>valueOf()</tt> 
1008      * method. The built-in classes of core JavaScript attempt <tt>valueOf()</tt> 
1009      * conversion before <tt>toString()</tt> conversion, except for the Date class, 
1010      * which performs <tt>toString()</tt> conversion. Objects that are not part of core 
1011      * JavaScript may convert themselves to primitive values in an implementation-defined 
1012      * way.</li>
1013      * <li>Any other combinations of values are not equal.</li>
1014      * </ul>
1015      * </ul>
1016      * @param other Any value or object.
1017      * @return <tt>true</tt> if the first operand equals the second; <tt>false</tt>, 
1018      * otherwise;
1019      * @since 1.0
1020      * @javascript Re-compilers must replace the instance invocation of this method with the 
1021      * JavaScript expression:
1022      * <pre>p == other</pre>
1023      * where <tt>p</tt> is the current number instance of the invocation of this method.
1024      */
1025     public final boolean eq(Object other) {
1026         return Js.eq(this, other);
1027     }
1028 
1029     /**
1030      * <p>Checks whether the two operands are "identical" using a strict definition of 
1031      * sameness, resembling the identity operator in JavaScript.</p>
1032      * <p>The equality and identity operations check whether two values are the same, using 
1033      * two different definitions of sameness. Both operations accept operands of any type, 
1034      * and both return <tt>true</tt> if their operands are the same and <tt>false</tt> 
1035      * if they are different. The identity operation checks whether its two operands are 
1036      * "identical" using a strict definition of sameness. The equality operation checks 
1037      * whether its two operands are "equal" using a more relaxed definition of sameness 
1038      * that allows type conversions.</p>
1039      * <p>The identity operation is standardized by ECMAScript v3 and implemented in 
1040      * JavaScript 1.3 and later. Be sure you understand the differences between the 
1041      * assignment, equality, and identity operations, and be careful to use the correct one 
1042      * when coding! Although it is tempting to call all three operations "equals," it may 
1043      * help to reduce confusion if you read "gets or is assigned" for assignment operation, 
1044      * "is equal to" for equality operation, and "is identical to" for identity operation.</p>
1045      * <p>In JavaScript, numbers, strings, and boolean values are compared by value. In this 
1046      * case, two separate values are involved, and the equality and identity operations 
1047      * check that these two values are identical. This means that two variables are equal 
1048      * or identical only if they contain the same value. For example, two strings are equal 
1049      * only if they each contain exactly the same characters.</p>
1050      * <p>On the other hand, objects, arrays, and functions are compared by reference. This 
1051      * means that two variables are equal only if they refer to the same object. Two 
1052      * separate arrays are never equal or identical, even if they contain equal or identical 
1053      * elements. Two variables that contain references to objects, arrays, or functions are 
1054      * equal only if they refer to the same object, array, or function. If you want to test 
1055      * that two distinct objects contain the same properties or that two distinct arrays 
1056      * contain the same elements, you'll have to check the properties or elements individually 
1057      * for equality or identity. And, if any of the properties or elements are themselves 
1058      * objects or arrays, you'll have to decide how deep you want the comparison to go.</p>
1059      * <p>The following rules determine whether two values are identical according to the identity operation:
1060      * <ul>
1061      * <li>If the two values have different types, they are not identical.</li>
1062      * <li>If both values are numbers and have the same value, they are identical, unless 
1063      * either or both values are <tt>NaN</tt>, in which case they are not identical. 
1064      * The <tt>NaN</tt> value is never identical to any other value, including itself! 
1065      * To check whether a value is <tt>NaN</tt>, use the global {@link Js#isNaN(Object)} 
1066      * function.</li>
1067      * <li>If both values are strings and contain exactly the same characters in the same 
1068      * positions, they are identical. If the strings differ in length or content, they are 
1069      * not identical. Note that in some cases, the Unicode standard allows more than one 
1070      * way to encode the same string. For efficiency, however, JavaScript's string 
1071      * comparison compares strictly on a character-by-character basis, and it assumes that 
1072      * all strings have been converted to a "normalized form" before they are compared. 
1073      * See the {@link StringLike#localeCompare(Object)} for another way to compare strings.</li>
1074      * <li>If both values are the boolean value <tt>true</tt> or both are the boolean 
1075      * value <tt>false</tt>, they are identical.</li>
1076      * <li>If both values refer to the same object, array, or function, they are identical. 
1077      * If they refer to different objects (or arrays or functions) they are not identical, 
1078      * even if both objects have identical properties or both arrays have identical elements.</li>
1079      * <li>If both values are null or both values are undefined, they are identical.</li>
1080      * </ul>
1081      * @param other Any value or object.
1082      * @return <tt>true</tt> if the first operand is identical to the second; 
1083      * <tt>false</tt>, otherwise;
1084      * @since 1.0
1085      * @javascript Re-compilers must replace the instance invocation of this method with the 
1086      * JavaScript expression:
1087      * <pre>p === other</pre>
1088      * where <tt>p</tt> is the current number instance of the invocation of this method.
1089      */
1090     public final boolean eqs(Object other) {
1091         return Js.eqs(this, other);
1092     }
1093 
1094     /**
1095      * <p>Checks whether the two operands are not "equal" using a more relaxed definition of 
1096      * sameness that allows type conversions, resembling the equality operator in 
1097      * JavaScript.</p>
1098      * <p>The equality and identity operations check whether two values are the same, using 
1099      * two different definitions of sameness. Both operations accept operands of any type, 
1100      * and both return <tt>true</tt> if their operands are the same and <tt>false</tt> 
1101      * if they are different. The identity operation checks whether its two operands are 
1102      * "identical" using a strict definition of sameness. The equality operation checks 
1103      * whether its two operands are "equal" using a more relaxed definition of sameness 
1104      * that allows type conversions.</p>
1105      * <p>The identity operation is standardized by ECMAScript v3 and implemented in 
1106      * JavaScript 1.3 and later. Be sure you understand the differences between the 
1107      * assignment, equality, and identity operations, and be careful to use the correct one 
1108      * when coding! Although it is tempting to call all three operations "equals," it may 
1109      * help to reduce confusion if you read "gets or is assigned" for assignment operation, 
1110      * "is equal to" for equality operation, and "is identical to" for identity operation.</p>
1111      * <p>In JavaScript, numbers, strings, and boolean values are compared by value. In this 
1112      * case, two separate values are involved, and the equality and identity operations 
1113      * check that these two values are identical. This means that two variables are equal 
1114      * or identical only if they contain the same value. For example, two strings are equal 
1115      * only if they each contain exactly the same characters.</p>
1116      * <p>On the other hand, objects, arrays, and functions are compared by reference. This 
1117      * means that two variables are equal only if they refer to the same object. Two 
1118      * separate arrays are never equal or identical, even if they contain equal or identical 
1119      * elements. Two variables that contain references to objects, arrays, or functions are 
1120      * equal only if they refer to the same object, array, or function. If you want to test 
1121      * that two distinct objects contain the same properties or that two distinct arrays 
1122      * contain the same elements, you'll have to check the properties or elements individually 
1123      * for equality or identity. And, if any of the properties or elements are themselves 
1124      * objects or arrays, you'll have to decide how deep you want the comparison to go.</p>
1125      * <p>The following rules determine whether two values are equal according to the 
1126      * equality operation:
1127      * <ul>
1128      * <li>If the two values have the same type, test them for identity. If the values are 
1129      * identical, they are equal; if they are not identical, they are not equal.</li>
1130      * <li>If the two values do not have the same type, they may still be equal. Use the 
1131      * following rules and type conversions to check for equality:</li>
1132      * <ul>
1133      * <li>If one value is null and the other is undefined, they are equal.</li>
1134      * <li>If one value is a number and the other is a string, convert the string to a 
1135      * number and try the comparison again, using the converted value.</li>
1136      * <li>If either value is <tt>true</tt>, convert it to 1 and try the comparison 
1137      * again. If either value is <tt>false</tt>, convert it to 0 and try the comparison 
1138      * again.</li>
1139      * <li>If one value is an object and the other is a number or string, convert the 
1140      * object to a primitive and try the comparison again. An object is converted to a 
1141      * primitive value by either its <tt>toString()</tt> method or its <tt>valueOf()</tt> 
1142      * method. The built-in classes of core JavaScript attempt <tt>valueOf()</tt> 
1143      * conversion before <tt>toString()</tt> conversion, except for the Date class, 
1144      * which performs <tt>toString()</tt> conversion. Objects that are not part of core 
1145      * JavaScript may convert themselves to primitive values in an implementation-defined 
1146      * way.</li>
1147      * <li>Any other combinations of values are not equal.</li>
1148      * </ul>
1149      * </ul>
1150      * @param other Any value or object.
1151      * @return <tt>false</tt> if the first operand equals the second; <tt>true</tt>, 
1152      * otherwise;
1153      * @since 1.0
1154      * @javascript Re-compilers must replace the instance invocation of this method with the 
1155      * JavaScript expression:
1156      * <pre>p != other</pre>
1157      * where <tt>p</tt> is the current number instance of the invocation of this method.
1158      */
1159     public final boolean neq(Object other) {
1160         return Js.neq(this, other);
1161     }
1162 
1163     /**
1164      * <p>Checks whether the two operands are not "identical" using a strict definition of 
1165      * sameness, resembling the identity operator in JavaScript.</p>
1166      * <p>The equality and identity operations check whether two values are the same, using 
1167      * two different definitions of sameness. Both operations accept operands of any type, 
1168      * and both return <tt>true</tt> if their operands are the same and <tt>false</tt> 
1169      * if they are different. The identity operation checks whether its two operands are 
1170      * "identical" using a strict definition of sameness. The equality operation checks 
1171      * whether its two operands are "equal" using a more relaxed definition of sameness 
1172      * that allows type conversions.</p>
1173      * <p>The identity operation is standardized by ECMAScript v3 and implemented in 
1174      * JavaScript 1.3 and later. Be sure you understand the differences between the 
1175      * assignment, equality, and identity operations, and be careful to use the correct one 
1176      * when coding! Although it is tempting to call all three operations "equals," it may 
1177      * help to reduce confusion if you read "gets or is assigned" for assignment operation, 
1178      * "is equal to" for equality operation, and "is identical to" for identity operation.</p>
1179      * <p>In JavaScript, numbers, strings, and boolean values are compared by value. In this 
1180      * case, two separate values are involved, and the equality and identity operations 
1181      * check that these two values are identical. This means that two variables are equal 
1182      * or identical only if they contain the same value. For example, two strings are equal 
1183      * only if they each contain exactly the same characters.</p>
1184      * <p>On the other hand, objects, arrays, and functions are compared by reference. This 
1185      * means that two variables are equal only if they refer to the same object. Two 
1186      * separate arrays are never equal or identical, even if they contain equal or identical 
1187      * elements. Two variables that contain references to objects, arrays, or functions are 
1188      * equal only if they refer to the same object, array, or function. If you want to test 
1189      * that two distinct objects contain the same properties or that two distinct arrays 
1190      * contain the same elements, you'll have to check the properties or elements individually 
1191      * for equality or identity. And, if any of the properties or elements are themselves 
1192      * objects or arrays, you'll have to decide how deep you want the comparison to go.</p>
1193      * <p>The following rules determine whether two values are identical according to the identity operation:
1194      * <ul>
1195      * <li>If the two values have different types, they are not identical.</li>
1196      * <li>If both values are numbers and have the same value, they are identical, unless 
1197      * either or both values are <tt>NaN</tt>, in which case they are not identical. 
1198      * The <tt>NaN</tt> value is never identical to any other value, including itself! 
1199      * To check whether a value is <tt>NaN</tt>, use the global {@link Js#isNaN(Object)} 
1200      * function.</li>
1201      * <li>If both values are strings and contain exactly the same characters in the same 
1202      * positions, they are identical. If the strings differ in length or content, they are 
1203      * not identical. Note that in some cases, the Unicode standard allows more than one 
1204      * way to encode the same string. For efficiency, however, JavaScript's string 
1205      * comparison compares strictly on a character-by-character basis, and it assumes that 
1206      * all strings have been converted to a "normalized form" before they are compared. 
1207      * See the {@link StringLike#localeCompare(Object)} for another way to compare strings.</li>
1208      * <li>If both values are the boolean value <tt>true</tt> or both are the boolean 
1209      * value <tt>false</tt>, they are identical.</li>
1210      * <li>If both values refer to the same object, array, or function, they are identical. 
1211      * If they refer to different objects (or arrays or functions) they are not identical, 
1212      * even if both objects have identical properties or both arrays have identical elements.</li>
1213      * <li>If both values are null or both values are undefined, they are identical.</li>
1214      * </ul>
1215      * @param other Any value or object.
1216      * @return <tt>false</tt> if the first operand is identical to the second; 
1217      * <tt>true</tt>, otherwise;
1218      * @since 1.0
1219      * @javascript Re-compilers must replace the instance invocation of this method with the 
1220      * JavaScript expression:
1221      * <pre>p !== other</pre>
1222      * where <tt>p</tt> is the current number instance of the invocation of this method.
1223      */
1224     public final boolean neqs(Object other) {
1225         return Js.neqs(this, other);
1226     }
1227 
1228     /**
1229      * <p>Bitwise-AND operation, resembling that of JavaScript, performs a boolean AND 
1230      * operation on each bit of the integer arguments. A bit is set in the result only if 
1231      * the corresponding bit is set in both operands.</p>
1232      * <p>Despite the fact that all numbers in JavaScript are floating-point numbers, the bitwise 
1233      * operation requires numeric operands that have integer values. It operate on the integer 
1234      * operands using a 32-bit integer representation instead of the equivalent floating-point 
1235      * representation.</p>
1236      * <p>If this bitwise operation is used with operands that are not integers or are too 
1237      * large to fit in a 32-bit integer representation, it simply coerces the operands to 
1238      * 32-bit integers by dropping any fractional part of the operand or any bits beyond 
1239      * the 32nd.</p>
1240      * @param other A numeric value.
1241      * @return The bitwise-AND of the two operands.
1242      * @since 1.0
1243      * @javascript Re-compilers must replace the instance invocation of this method with the 
1244      * JavaScript expression:
1245      * <pre>p & other</pre>
1246      * where <tt>p</tt> is the current number instance of the invocation of this method.
1247      */
1248     public final int band(Object other) {
1249         return Js.band(valueOf(), other);
1250     }
1251 
1252     /**
1253      * <p>Bitwise-OR operation, resembling that of JavaScript, performs a boolean OR operation 
1254      * on each bit of the integer arguments. A bit is set in the result if the corresponding 
1255      * bit is set in one or both of the operands.</p>
1256      * <p>Despite the fact that all numbers in JavaScript are floating-point numbers, the bitwise 
1257      * operation requires numeric operands that have integer values. It operate on the integer 
1258      * operands using a 32-bit integer representation instead of the equivalent floating-point 
1259      * representation.</p>
1260      * <p>If this bitwise operation is used with operands that are not integers or are too 
1261      * large to fit in a 32-bit integer representation, it simply coerces the operands to 
1262      * 32-bit integers by dropping any fractional part of the operand or any bits beyond 
1263      * the 32nd.</p>
1264      * @param other A numeric value.
1265      * @return The bitwise-OR of the two operands.
1266      * @since 1.0
1267      * @javascript Re-compilers must replace the instance invocation of this method with the 
1268      * JavaScript expression:
1269      * <pre>p | other</pre>
1270      * where <tt>p</tt> is the current number instance of the invocation of this method.
1271      */
1272     public final int bor(Object other) {
1273         return Js.bor(valueOf(), other);
1274     }
1275 
1276     /**
1277      * <p>Bitwise-XOR operation, resembling that of JavaScript, performs a boolean exclusive 
1278      * OR operation on each bit of the integer arguments. Exclusive OR means that either 
1279      * operand one is <tt>true</tt> or operand two is <tt>true</tt>, but not both. A bit is 
1280      * set in this operation's result if a corresponding bit is set in one (but not both) 
1281      * of the two operands.</p>
1282      * <p>Despite the fact that all numbers in JavaScript are floating-point numbers, the bitwise 
1283      * operation requires numeric operands that have integer values. It operate on the integer 
1284      * operands using a 32-bit integer representation instead of the equivalent floating-point 
1285      * representation.</p>
1286      * <p>If this bitwise operation is used with operands that are not integers or are too 
1287      * large to fit in a 32-bit integer representation, it simply coerces the operands to 
1288      * 32-bit integers by dropping any fractional part of the operand or any bits beyond 
1289      * the 32nd.</p>
1290      * @param other A numeric value.
1291      * @return The bitwise-exclusive-OR of the two operands.
1292      * @since 1.0
1293      * @javascript Re-compilers must replace the instance invocation of this method with the 
1294      * JavaScript expression:
1295      * <pre>p ^ other</pre>
1296      * where <tt>p</tt> is the current number instance of the invocation of this method.
1297      */
1298     public final int xor(Object other) {
1299         return Js.xor(valueOf(), other);
1300     }
1301 
1302     /**
1303      * <p>Shift-left operation, resembling that of JavaScript, moves all bits in the 
1304      * current primitive instance to the left by the number of places specified in the 
1305      * second operand, which should be an integer between 0 and 31.</p>
1306      * <p>A zero is used for the new first bit, and the value of the 32nd bit is lost. 
1307      * Shifting a value left by one position is equivalent to multiplying by 2, shifting 
1308      * two positions is equivalent to multiplying by 4, etc.</p>
1309      * <p>Despite the fact that all numbers in JavaScript are floating-point numbers, the bitwise 
1310      * operation requires numeric operands that have integer values. It operate on the integer 
1311      * operands using a 32-bit integer representation instead of the equivalent floating-point 
1312      * representation.</p>
1313      * <p>If this bitwise operation is used with values that are not integers or are too 
1314      * large to fit in a 32-bit integer representation, it simply coerces the values to 
1315      * 32-bit integers by dropping any fractional part of the value or any bits beyond 
1316      * the 32nd. The shift operation requires a (right-side) operand between 0 and 31. After 
1317      * converting this operand to a 32-bit integer, it drops any bits beyond the 5th, which 
1318      * yields a number in the appropriate range.</p>
1319      * @param n The number of bits to shift.
1320      * @return The shifted integer number.
1321      * @since 1.0
1322      * @javascript Re-compilers must replace the instance invocation of this method with the 
1323      * JavaScript expression:
1324      * <pre>p << n</pre>
1325      * where <tt>p</tt> is the current number instance of the invocation of this method.
1326      */
1327     public final int shl(int n) {
1328         return Js.shl(valueOf(), n);
1329     }
1330 
1331     /**
1332      * <p>Shift-right operation, resembling that of JavaScript, moves all bits in the 
1333      * current primitive instance to the right by the number of places specified in the 
1334      * second operand (an integer between 0 and 31). Bits that are shifted off the right 
1335      * are lost. The bits filled in on the left depend on the sign bit of the original 
1336      * value, in order to preserve the sign of the result. If the current primitive 
1337      * instance is positive, the result has zeros placed in the high bits; if the current 
1338      * primitive instance is negative, the result has ones placed in the high bits.</p>
1339      * <p>Shifting a value right one place is equivalent to dividing by 2 (discarding the 
1340      * remainder), shifting right two places is equivalent to integer division by 4, and 
1341      * so on.</p>
1342      * <p>Despite the fact that all numbers in JavaScript are floating-point numbers, the bitwise 
1343      * operation requires numeric operands that have integer values. It operate on the integer 
1344      * operands using a 32-bit integer representation instead of the equivalent floating-point 
1345      * representation.</p>
1346      * <p>If this bitwise operation is used with values that are not integers or are too 
1347      * large to fit in a 32-bit integer representation, it simply coerces the values to 
1348      * 32-bit integers by dropping any fractional part of the value or any bits beyond 
1349      * the 32nd. The shift operation requires a (right-side) operand between 0 and 31. After 
1350      * converting this operand to a 32-bit integer, it drops any bits beyond the 5th, which 
1351      * yields a number in the appropriate range.</p>
1352      * @param n The number of bits to shift.
1353      * @return The shifted integer number.
1354      * @since 1.0
1355      * @javascript Re-compilers must replace the instance invocation of this method with the 
1356      * JavaScript expression:
1357      * <pre>p >> n</pre>
1358      * where <tt>p</tt> is the current number instance of the invocation of this method.
1359      */
1360     public final int shr(int n) {
1361         return Js.shr(valueOf(), n);
1362     }
1363 
1364     /**
1365      * <p>Shift-right-unsigned operation, resembling that of JavaScript, moves all bits in 
1366      * the current number instance to the right by the number of places specified in the 
1367      * second operand (an integer between 0 and 31). Bits that are shifted off the right 
1368      * are lost. The result has zeros placed in the high bits.</p>
1369      * <p>This operation is just like {@link #shr(int)}, except that the bits shifted 
1370      * in on the left are always zero, regardless of the sign of the current number instance.</p>
1371      * <p>Shifting a value right one place is equivalent to dividing by 2 (discarding the 
1372      * remainder), shifting right two places is equivalent to integer division by 4, and 
1373      * so on.</p>
1374      * <p>Despite the fact that all numbers in JavaScript are floating-point numbers, the bitwise 
1375      * operation requires numeric operands that have integer values. It operate on the integer 
1376      * operands using a 32-bit integer representation instead of the equivalent floating-point 
1377      * representation.</p>
1378      * <p>If this bitwise operation is used with values that are not integers or are too 
1379      * large to fit in a 32-bit integer representation, it simply coerces the values to 
1380      * 32-bit integers by dropping any fractional part of the value or any bits beyond 
1381      * the 32nd. The shift operation requires a (right-side) operand between 0 and 31. After 
1382      * converting this operand to a 32-bit integer, it drops any bits beyond the 5th, which 
1383      * yields a number in the appropriate range.</p>
1384      * @param n The number of bits to shift.
1385      * @return The shifted integer number.
1386      * @since 1.0
1387      * @javascript Re-compilers must replace the instance invocation of this method with the 
1388      * JavaScript expression:
1389      * <pre>p >>> n</pre>
1390      * where <tt>p</tt> is the current number instance of the invocation of this method.
1391      */
1392     public final int shru(int n) {
1393         return Js.shru(valueOf(), n);
1394     }
1395 
1396     /**
1397      * <p>Logical AND operation, resembling that of JavaScript, performs the Boolean AND 
1398      * operation on the two values: it returns <tt>true</tt> if and only if both its first 
1399      * operand and its second operand are <tt>true</tt>. If one or both of these operands 
1400      * is <tt>false</tt>, it returns <tt>false</tt>.</p>
1401      * <p>In JavaScript, depending on the value of the left-side expression, the operator 
1402      * may or may not evaluate the right-side expression. The actual behavior of the operator 
1403      * is somewhat more complicated. It starts by evaluating its first operand, the expression 
1404      * on its left. If the value of this expression can be converted to <tt>false</tt> 
1405      * (for example, if the left operand evaluates to <tt>null</tt>, 0, "", or undefined), 
1406      * the operator returns the value of the left-side expression. Otherwise, it evaluates 
1407      * its second operand, the expression on its right, and returns the value of that 
1408      * expression. In JavaScript 1.0 and JavaScript 1.1, if the left-side expression 
1409      * evaluates to <tt>false</tt>, the && operator returns <tt>false</tt> rather than 
1410      * returning the unconverted value of the left-side expression.</p>
1411      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1412      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1413      * anonymously, returning the actual expression in the method overriding 
1414      * {@link Var#var()}.</p>
1415      * <p>Sometimes, this operation probably does not do what the programmers intended. 
1416      * To avoid problems, do not use expressions with side effects (assignments, increments, 
1417      * decrements, and function calls) for the second operand unless you are quite sure 
1418      * you know exactly what you are doing.</p>
1419      * <p>Despite the fairly confusing way that this operation actually works, it is 
1420      * easiest, and perfectly safe, to think of it as merely a Boolean algebra operator. 
1421      * Although it does not actually return a boolean value, the value it returns can always 
1422      * be converted to a boolean value.</p>
1423      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1424      * re-compilations. However, in most cases you can use the logical AND operator of the 
1425      * Java language like this:
1426      * <pre>Js.be(var) && Js.be(other)</pre>
1427      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1428      * JavaScript expression since the Java compilers generally used are free to compile 
1429      * the expression into any byte codes they think efficient, making it too hard for the 
1430      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1431      * @param other A value or object.
1432      * @return The logical AND of the two operands.
1433      * @since 1.0
1434      * @javascript Re-compilers must replace the instance invocation of this method with the 
1435      * JavaScript expression:
1436      * <pre>p && other</pre>
1437      * where <tt>p</tt> is the current number instance of the invocation of this method.
1438      */
1439     public final Object and(Object other) {
1440         return Js.and(this, other);
1441     }
1442 
1443     /**
1444      * <p>Logical AND operation, resembling that of JavaScript, performs the Boolean AND 
1445      * operation on the two values: it returns <tt>true</tt> if and only if both its first 
1446      * operand and its second operand are <tt>true</tt>. If one or both of these operands 
1447      * is <tt>false</tt>, it returns <tt>false</tt>.</p>
1448      * <p>In JavaScript, depending on the value of the left-side expression, the operator 
1449      * may or may not evaluate the right-side expression. The actual behavior of the operator 
1450      * is somewhat more complicated. It starts by evaluating its first operand, the expression 
1451      * on its left. If the value of this expression can be converted to <tt>false</tt> 
1452      * (for example, if the left operand evaluates to <tt>null</tt>, 0, "", or undefined), 
1453      * the operator returns the value of the left-side expression. Otherwise, it evaluates 
1454      * its second operand, the expression on its right, and returns the value of that 
1455      * expression. In JavaScript 1.0 and JavaScript 1.1, if the left-side expression 
1456      * evaluates to <tt>false</tt>, the && operator returns <tt>false</tt> rather than 
1457      * returning the unconverted value of the left-side expression.</p>
1458      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1459      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1460      * anonymously, returning the actual expression in the method overriding 
1461      * {@link Var#var()}.</p>
1462      * <p>Sometimes, this operation probably does not do what the programmers intended. 
1463      * To avoid problems, do not use expressions with side effects (assignments, increments, 
1464      * decrements, and function calls) for the second operand unless you are quite sure 
1465      * you know exactly what you are doing.</p>
1466      * <p>Despite the fairly confusing way that this operation actually works, it is 
1467      * easiest, and perfectly safe, to think of it as merely a Boolean algebra operator. 
1468      * Although it does not actually return a boolean value, the value it returns can always 
1469      * be converted to a boolean value.</p>
1470      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1471      * re-compilations. However, in most cases you can use the logical AND operator of the 
1472      * Java language like this:
1473      * <pre>Js.be(var) && Js.be(other)</pre>
1474      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1475      * JavaScript expression since the Java compilers generally used are free to compile 
1476      * the expression into any byte codes they think efficient, making it too hard for the 
1477      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1478      * @param other A value or object.
1479      * @return The logical AND of the two operands.
1480      * @since 1.0
1481      * @javascript Re-compilers must replace the instance invocation of this method with the 
1482      * JavaScript expression:
1483      * <pre>p && other</pre>
1484      * where <tt>p</tt> is the current number instance of the invocation of this method.
1485      */
1486     public final Number and(Number other) {
1487         return Js.and(this, other);
1488     }
1489 
1490     /**
1491      * <p>Logical AND operation, resembling that of JavaScript, performs the Boolean AND 
1492      * operation on the two values: it returns <tt>true</tt> if and only if both its first 
1493      * operand and its second operand are <tt>true</tt>. If one or both of these operands 
1494      * is <tt>false</tt>, it returns <tt>false</tt>.</p>
1495      * <p>In JavaScript, depending on the value of the left-side expression, the operator 
1496      * may or may not evaluate the right-side expression. The actual behavior of the operator 
1497      * is somewhat more complicated. It starts by evaluating its first operand, the expression 
1498      * on its left. If the value of this expression can be converted to <tt>false</tt> 
1499      * (for example, if the left operand evaluates to <tt>null</tt>, 0, "", or undefined), 
1500      * the operator returns the value of the left-side expression. Otherwise, it evaluates 
1501      * its second operand, the expression on its right, and returns the value of that 
1502      * expression. In JavaScript 1.0 and JavaScript 1.1, if the left-side expression 
1503      * evaluates to <tt>false</tt>, the && operator returns <tt>false</tt> rather than 
1504      * returning the unconverted value of the left-side expression.</p>
1505      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1506      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1507      * anonymously, returning the actual expression in the method overriding 
1508      * {@link Var#var()}.</p>
1509      * <p>Sometimes, this operation probably does not do what the programmers intended. 
1510      * To avoid problems, do not use expressions with side effects (assignments, increments, 
1511      * decrements, and function calls) for the second operand unless you are quite sure 
1512      * you know exactly what you are doing.</p>
1513      * <p>Despite the fairly confusing way that this operation actually works, it is 
1514      * easiest, and perfectly safe, to think of it as merely a Boolean algebra operator. 
1515      * Although it does not actually return a boolean value, the value it returns can always 
1516      * be converted to a boolean value.</p>
1517      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1518      * re-compilations. However, in most cases you can use the logical AND operator of the 
1519      * Java language like this:
1520      * <pre>Js.be(var) && Js.be(other)</pre>
1521      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1522      * JavaScript expression since the Java compilers generally used are free to compile 
1523      * the expression into any byte codes they think efficient, making it too hard for the 
1524      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1525      * @param other A value or object.
1526      * @return The logical AND of the two operands.
1527      * @since 1.0
1528      * @javascript Re-compilers must replace the instance invocation of this method with the 
1529      * JavaScript expression:
1530      * <pre>p && other</pre>
1531      * where <tt>p</tt> is the current number instance of the invocation of this method.
1532      */
1533     public final Number and(Character other) {
1534         return Js.and(this, other);
1535     }
1536 
1537     /**
1538      * <p>Logical AND operation, resembling that of JavaScript, performs the Boolean AND 
1539      * operation on the two values: it returns <tt>true</tt> if and only if both its first 
1540      * operand and its second operand are <tt>true</tt>. If one or both of these operands 
1541      * is <tt>false</tt>, it returns <tt>false</tt>.</p>
1542      * <p>In JavaScript, depending on the value of the left-side expression, the operator 
1543      * may or may not evaluate the right-side expression. The actual behavior of the operator 
1544      * is somewhat more complicated. It starts by evaluating its first operand, the expression 
1545      * on its left. If the value of this expression can be converted to <tt>false</tt> 
1546      * (for example, if the left operand evaluates to <tt>null</tt>, 0, "", or undefined), 
1547      * the operator returns the value of the left-side expression. Otherwise, it evaluates 
1548      * its second operand, the expression on its right, and returns the value of that 
1549      * expression. In JavaScript 1.0 and JavaScript 1.1, if the left-side expression 
1550      * evaluates to <tt>false</tt>, the && operator returns <tt>false</tt> rather than 
1551      * returning the unconverted value of the left-side expression.</p>
1552      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1553      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1554      * anonymously, returning the actual expression in the method overriding 
1555      * {@link Var#var()}.</p>
1556      * <p>Sometimes, this operation probably does not do what the programmers intended. 
1557      * To avoid problems, do not use expressions with side effects (assignments, increments, 
1558      * decrements, and function calls) for the second operand unless you are quite sure 
1559      * you know exactly what you are doing.</p>
1560      * <p>Despite the fairly confusing way that this operation actually works, it is 
1561      * easiest, and perfectly safe, to think of it as merely a Boolean algebra operator. 
1562      * Although it does not actually return a boolean value, the value it returns can always 
1563      * be converted to a boolean value.</p>
1564      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1565      * re-compilations. However, in most cases you can use the logical AND operator of the 
1566      * Java language like this:
1567      * <pre>Js.be(var) && Js.be(other)</pre>
1568      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1569      * JavaScript expression since the Java compilers generally used are free to compile 
1570      * the expression into any byte codes they think efficient, making it too hard for the 
1571      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1572      * @param other A value or object.
1573      * @return The logical AND of the two operands.
1574      * @since 1.0
1575      * @javascript Re-compilers must replace the instance invocation of this method with the 
1576      * JavaScript expression:
1577      * <pre>p && other</pre>
1578      * where <tt>p</tt> is the current number instance of the invocation of this method.
1579      */
1580     public final Number and(Value<? extends Number> other) {
1581         return Js.and(this, other);
1582     }
1583 
1584     /**
1585      * <p>Logical AND operation, resembling that of JavaScript, performs the Boolean AND 
1586      * operation on the two values: it returns <tt>true</tt> if and only if both its first 
1587      * operand and its second operand are <tt>true</tt>. If one or both of these operands 
1588      * is <tt>false</tt>, it returns <tt>false</tt>.</p>
1589      * <p>In JavaScript, depending on the value of the left-side expression, the operator 
1590      * may or may not evaluate the right-side expression. The actual behavior of the operator 
1591      * is somewhat more complicated. It starts by evaluating its first operand, the expression 
1592      * on its left. If the value of this expression can be converted to <tt>false</tt> 
1593      * (for example, if the left operand evaluates to <tt>null</tt>, 0, "", or undefined), 
1594      * the operator returns the value of the left-side expression. Otherwise, it evaluates 
1595      * its second operand, the expression on its right, and returns the value of that 
1596      * expression. In JavaScript 1.0 and JavaScript 1.1, if the left-side expression 
1597      * evaluates to <tt>false</tt>, the && operator returns <tt>false</tt> rather than 
1598      * returning the unconverted value of the left-side expression.</p>
1599      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1600      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1601      * anonymously, returning the actual expression in the method overriding 
1602      * {@link Var#var()}.</p>
1603      * <p>Sometimes, this operation probably does not do what the programmers intended. 
1604      * To avoid problems, do not use expressions with side effects (assignments, increments, 
1605      * decrements, and function calls) for the second operand unless you are quite sure 
1606      * you know exactly what you are doing.</p>
1607      * <p>Despite the fairly confusing way that this operation actually works, it is 
1608      * easiest, and perfectly safe, to think of it as merely a Boolean algebra operator. 
1609      * Although it does not actually return a boolean value, the value it returns can always 
1610      * be converted to a boolean value.</p>
1611      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1612      * re-compilations. However, in most cases you can use the logical AND operator of the 
1613      * Java language like this:
1614      * <pre>Js.be(var) && Js.be(other)</pre>
1615      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1616      * JavaScript expression since the Java compilers generally used are free to compile 
1617      * the expression into any byte codes they think efficient, making it too hard for the 
1618      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1619      * @param other A value or object.
1620      * @return The logical AND of the two operands.
1621      * @since 1.0
1622      * @javascript Re-compilers must replace the instance invocation of this method with the 
1623      * JavaScript expression:
1624      * <pre>p && other</pre>
1625      * where <tt>p</tt> is the current number instance of the invocation of this method.
1626      */
1627     public final JsObject and(Var<? extends JsObject> other) {
1628         return Js.and(this, other);
1629     }
1630 
1631     /**
1632      * <p>Logical AND operation, resembling that of JavaScript, performs the Boolean AND 
1633      * operation on the two values: it returns <tt>true</tt> if and only if both its first 
1634      * operand and its second operand are <tt>true</tt>. If one or both of these operands 
1635      * is <tt>false</tt>, it returns <tt>false</tt>.</p>
1636      * <p>In JavaScript, depending on the value of the left-side expression, the operator 
1637      * may or may not evaluate the right-side expression. The actual behavior of the operator 
1638      * is somewhat more complicated. It starts by evaluating its first operand, the expression 
1639      * on its left. If the value of this expression can be converted to <tt>false</tt> 
1640      * (for example, if the left operand evaluates to <tt>null</tt>, 0, "", or undefined), 
1641      * the operator returns the value of the left-side expression. Otherwise, it evaluates 
1642      * its second operand, the expression on its right, and returns the value of that 
1643      * expression. In JavaScript 1.0 and JavaScript 1.1, if the left-side expression 
1644      * evaluates to <tt>false</tt>, the && operator returns <tt>false</tt> rather than 
1645      * returning the unconverted value of the left-side expression.</p>
1646      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1647      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1648      * anonymously, returning the actual expression in the method overriding 
1649      * {@link Var#var()}.</p>
1650      * <p>Sometimes, this operation probably does not do what the programmers intended. 
1651      * To avoid problems, do not use expressions with side effects (assignments, increments, 
1652      * decrements, and function calls) for the second operand unless you are quite sure 
1653      * you know exactly what you are doing.</p>
1654      * <p>Despite the fairly confusing way that this operation actually works, it is 
1655      * easiest, and perfectly safe, to think of it as merely a Boolean algebra operator. 
1656      * Although it does not actually return a boolean value, the value it returns can always 
1657      * be converted to a boolean value.</p>
1658      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1659      * re-compilations. However, in most cases you can use the logical AND operator of the 
1660      * Java language like this:
1661      * <pre>Js.be(var) && Js.be(other)</pre>
1662      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1663      * JavaScript expression since the Java compilers generally used are free to compile 
1664      * the expression into any byte codes they think efficient, making it too hard for the 
1665      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1666      * @param other A value or object.
1667      * @return The logical AND of the two operands.
1668      * @since 1.0
1669      * @javascript Re-compilers must replace the instance invocation of this method with the 
1670      * JavaScript expression:
1671      * <pre>p && other</pre>
1672      * where <tt>p</tt> is the current number instance of the invocation of this method.
1673      */
1674     public final JsNumber and(JsNumber other) {
1675         return Js.and(this, other);
1676     }
1677 
1678     /**
1679      * <p>Logical OR operation, resembling that of JavaScript, performs the Boolean OR 
1680      * operation on the two values: it returns <tt>true</tt> if either the first operand or 
1681      * the second operand is <tt>true</tt>, or if both are <tt>true</tt>. If both operands 
1682      * are <tt>false</tt>, it returns <tt>false</tt>.</p>
1683      * <p>In JavaScript, although the || operator is most often used simply as a Boolean OR 
1684      * operator, it, like the && operator, has more complex behavior. It starts by evaluating 
1685      * its first operand, the expression on its left. If the value of this expression can 
1686      * be converted to <tt>true</tt>, it returns the unconverted value of the left-side 
1687      * expression. Otherwise, it evaluates its second operand, the expression on its right, 
1688      * and returns the value of that expression. In JavaScript 1.0 and JavaScript 1.1, if the 
1689      * left-side expression can be converted to <tt>true</tt>, the operator returns <tt>true</tt> 
1690      * and doesn't return the unconverted value of the left-side expression.</p>
1691      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1692      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1693      * anonymously, returning the actual expression in the method overriding 
1694      * {@link Var#var()}.</p>
1695      * <p>As with the {@link #and(Object)} operation, you should avoid right-side 
1696      * operands that include side effects, unless you purposely want to use the fact that 
1697      * the right-side expression may not be evaluated in JavaScript.</p>
1698      * <p>Even when this operation is used with operands that are not boolean values, it 
1699      * can still be considered a Boolean OR operator because its return value, whatever the 
1700      * type, can be converted to a boolean value.</p>
1701      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1702      * re-compilations. However, in most cases you can use the logical OR operator of the 
1703      * Java language like this:
1704      * <pre>Js.be(var) || Js.be(other)</pre>
1705      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1706      * JavaScript expression since the Java compilers generally used are free to compile 
1707      * the expression into any byte codes they think efficient, making it too hard for the 
1708      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1709      * @param other A value or object.
1710      * @return The logical OR of the two operands.
1711      * @since 1.0
1712      * @javascript Re-compilers must replace the instance invocation of this method with the 
1713      * JavaScript expression:
1714      * <pre>p || other</pre>
1715      * where <tt>p</tt> is the current number instance of the invocation of this method.
1716      */
1717     public final Object or(Object other) {
1718         return Js.or(this, other);
1719     }
1720 
1721     /**
1722      * <p>Logical OR operation, resembling that of JavaScript, performs the Boolean OR 
1723      * operation on the two values: it returns <tt>true</tt> if either the first operand or 
1724      * the second operand is <tt>true</tt>, or if both are <tt>true</tt>. If both operands 
1725      * are <tt>false</tt>, it returns <tt>false</tt>.</p>
1726      * <p>In JavaScript, although the || operator is most often used simply as a Boolean OR 
1727      * operator, it, like the && operator, has more complex behavior. It starts by evaluating 
1728      * its first operand, the expression on its left. If the value of this expression can 
1729      * be converted to <tt>true</tt>, it returns the unconverted value of the left-side 
1730      * expression. Otherwise, it evaluates its second operand, the expression on its right, 
1731      * and returns the value of that expression. In JavaScript 1.0 and JavaScript 1.1, if the 
1732      * left-side expression can be converted to <tt>true</tt>, the operator returns <tt>true</tt> 
1733      * and doesn't return the unconverted value of the left-side expression.</p>
1734      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1735      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1736      * anonymously, returning the actual expression in the method overriding 
1737      * {@link Var#var()}.</p>
1738      * <p>As with the {@link #and(Object)} operation, you should avoid right-side 
1739      * operands that include side effects, unless you purposely want to use the fact that 
1740      * the right-side expression may not be evaluated in JavaScript.</p>
1741      * <p>Even when this operation is used with operands that are not boolean values, it 
1742      * can still be considered a Boolean OR operator because its return value, whatever the 
1743      * type, can be converted to a boolean value.</p>
1744      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1745      * re-compilations. However, in most cases you can use the logical OR operator of the 
1746      * Java language like this:
1747      * <pre>Js.be(var) || Js.be(other)</pre>
1748      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1749      * JavaScript expression since the Java compilers generally used are free to compile 
1750      * the expression into any byte codes they think efficient, making it too hard for the 
1751      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1752      * @param other A value or object.
1753      * @return The logical OR of the two operands.
1754      * @since 1.0
1755      * @javascript Re-compilers must replace the instance invocation of this method with the 
1756      * JavaScript expression:
1757      * <pre>p || other</pre>
1758      * where <tt>p</tt> is the current number instance of the invocation of this method.
1759      */
1760     public final JsNumber or(Character other) {
1761         return Js.or(this, other);
1762     }
1763 
1764     /**
1765      * <p>Logical OR operation, resembling that of JavaScript, performs the Boolean OR 
1766      * operation on the two values: it returns <tt>true</tt> if either the first operand or 
1767      * the second operand is <tt>true</tt>, or if both are <tt>true</tt>. If both operands 
1768      * are <tt>false</tt>, it returns <tt>false</tt>.</p>
1769      * <p>In JavaScript, although the || operator is most often used simply as a Boolean OR 
1770      * operator, it, like the && operator, has more complex behavior. It starts by evaluating 
1771      * its first operand, the expression on its left. If the value of this expression can 
1772      * be converted to <tt>true</tt>, it returns the unconverted value of the left-side 
1773      * expression. Otherwise, it evaluates its second operand, the expression on its right, 
1774      * and returns the value of that expression. In JavaScript 1.0 and JavaScript 1.1, if the 
1775      * left-side expression can be converted to <tt>true</tt>, the operator returns <tt>true</tt> 
1776      * and doesn't return the unconverted value of the left-side expression.</p>
1777      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1778      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1779      * anonymously, returning the actual expression in the method overriding 
1780      * {@link Var#var()}.</p>
1781      * <p>As with the {@link #and(Object)} operation, you should avoid right-side 
1782      * operands that include side effects, unless you purposely want to use the fact that 
1783      * the right-side expression may not be evaluated in JavaScript.</p>
1784      * <p>Even when this operation is used with operands that are not boolean values, it 
1785      * can still be considered a Boolean OR operator because its return value, whatever the 
1786      * type, can be converted to a boolean value.</p>
1787      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1788      * re-compilations. However, in most cases you can use the logical OR operator of the 
1789      * Java language like this:
1790      * <pre>Js.be(var) || Js.be(other)</pre>
1791      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1792      * JavaScript expression since the Java compilers generally used are free to compile 
1793      * the expression into any byte codes they think efficient, making it too hard for the 
1794      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1795      * @param other A value or object.
1796      * @return The logical OR of the two operands.
1797      * @since 1.0
1798      * @javascript Re-compilers must replace the instance invocation of this method with the 
1799      * JavaScript expression:
1800      * <pre>p || other</pre>
1801      * where <tt>p</tt> is the current number instance of the invocation of this method.
1802      */
1803     public final JsNumber or(Number other) {
1804         return Js.or(this, other);
1805     }
1806 
1807     /**
1808      * <p>Logical OR operation, resembling that of JavaScript, performs the Boolean OR 
1809      * operation on the two values: it returns <tt>true</tt> if either the first operand or 
1810      * the second operand is <tt>true</tt>, or if both are <tt>true</tt>. If both operands 
1811      * are <tt>false</tt>, it returns <tt>false</tt>.</p>
1812      * <p>In JavaScript, although the || operator is most often used simply as a Boolean OR 
1813      * operator, it, like the && operator, has more complex behavior. It starts by evaluating 
1814      * its first operand, the expression on its left. If the value of this expression can 
1815      * be converted to <tt>true</tt>, it returns the unconverted value of the left-side 
1816      * expression. Otherwise, it evaluates its second operand, the expression on its right, 
1817      * and returns the value of that expression. In JavaScript 1.0 and JavaScript 1.1, if the 
1818      * left-side expression can be converted to <tt>true</tt>, the operator returns <tt>true</tt> 
1819      * and doesn't return the unconverted value of the left-side expression.</p>
1820      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1821      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1822      * anonymously, returning the actual expression in the method overriding 
1823      * {@link Var#var()}.</p>
1824      * <p>As with the {@link #and(Object)} operation, you should avoid right-side 
1825      * operands that include side effects, unless you purposely want to use the fact that 
1826      * the right-side expression may not be evaluated in JavaScript.</p>
1827      * <p>Even when this operation is used with operands that are not boolean values, it 
1828      * can still be considered a Boolean OR operator because its return value, whatever the 
1829      * type, can be converted to a boolean value.</p>
1830      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1831      * re-compilations. However, in most cases you can use the logical OR operator of the 
1832      * Java language like this:
1833      * <pre>Js.be(var) || Js.be(other)</pre>
1834      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1835      * JavaScript expression since the Java compilers generally used are free to compile 
1836      * the expression into any byte codes they think efficient, making it too hard for the 
1837      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1838      * @param other A value or object.
1839      * @return The logical OR of the two operands.
1840      * @since 1.0
1841      * @javascript Re-compilers must replace the instance invocation of this method with the 
1842      * JavaScript expression:
1843      * <pre>p || other</pre>
1844      * where <tt>p</tt> is the current number instance of the invocation of this method.
1845      */
1846     public final JsNumber or(Value<? extends Number> other) {
1847         return Js.or(this, other);
1848     }
1849 
1850     /**
1851      * <p>Logical OR operation, resembling that of JavaScript, performs the Boolean OR 
1852      * operation on the two values: it returns <tt>true</tt> if either the first operand or 
1853      * the second operand is <tt>true</tt>, or if both are <tt>true</tt>. If both operands 
1854      * are <tt>false</tt>, it returns <tt>false</tt>.</p>
1855      * <p>In JavaScript, although the || operator is most often used simply as a Boolean OR 
1856      * operator, it, like the && operator, has more complex behavior. It starts by evaluating 
1857      * its first operand, the expression on its left. If the value of this expression can 
1858      * be converted to <tt>true</tt>, it returns the unconverted value of the left-side 
1859      * expression. Otherwise, it evaluates its second operand, the expression on its right, 
1860      * and returns the value of that expression. In JavaScript 1.0 and JavaScript 1.1, if the 
1861      * left-side expression can be converted to <tt>true</tt>, the operator returns <tt>true</tt> 
1862      * and doesn't return the unconverted value of the left-side expression.</p>
1863      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1864      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1865      * anonymously, returning the actual expression in the method overriding 
1866      * {@link Var#var()}.</p>
1867      * <p>As with the {@link #and(Object)} operation, you should avoid right-side 
1868      * operands that include side effects, unless you purposely want to use the fact that 
1869      * the right-side expression may not be evaluated in JavaScript.</p>
1870      * <p>Even when this operation is used with operands that are not boolean values, it 
1871      * can still be considered a Boolean OR operator because its return value, whatever the 
1872      * type, can be converted to a boolean value.</p>
1873      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1874      * re-compilations. However, in most cases you can use the logical OR operator of the 
1875      * Java language like this:
1876      * <pre>Js.be(var) || Js.be(other)</pre>
1877      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1878      * JavaScript expression since the Java compilers generally used are free to compile 
1879      * the expression into any byte codes they think efficient, making it too hard for the 
1880      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1881      * @param other A value or object.
1882      * @return The logical OR of the two operands.
1883      * @since 1.0
1884      * @javascript Re-compilers must replace the instance invocation of this method with the 
1885      * JavaScript expression:
1886      * <pre>p || other</pre>
1887      * where <tt>p</tt> is the current number instance of the invocation of this method.
1888      */
1889     public final JsNumber or(Value.Character other) {
1890         return Js.or(this, other);
1891     }
1892 
1893     /**
1894      * <p>Logical OR operation, resembling that of JavaScript, performs the Boolean OR 
1895      * operation on the two values: it returns <tt>true</tt> if either the first operand or 
1896      * the second operand is <tt>true</tt>, or if both are <tt>true</tt>. If both operands 
1897      * are <tt>false</tt>, it returns <tt>false</tt>.</p>
1898      * <p>In JavaScript, although the || operator is most often used simply as a Boolean OR 
1899      * operator, it, like the && operator, has more complex behavior. It starts by evaluating 
1900      * its first operand, the expression on its left. If the value of this expression can 
1901      * be converted to <tt>true</tt>, it returns the unconverted value of the left-side 
1902      * expression. Otherwise, it evaluates its second operand, the expression on its right, 
1903      * and returns the value of that expression. In JavaScript 1.0 and JavaScript 1.1, if the 
1904      * left-side expression can be converted to <tt>true</tt>, the operator returns <tt>true</tt> 
1905      * and doesn't return the unconverted value of the left-side expression.</p>
1906      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1907      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1908      * anonymously, returning the actual expression in the method overriding 
1909      * {@link Var#var()}.</p>
1910      * <p>As with the {@link #and(Object)} operation, you should avoid right-side 
1911      * operands that include side effects, unless you purposely want to use the fact that 
1912      * the right-side expression may not be evaluated in JavaScript.</p>
1913      * <p>Even when this operation is used with operands that are not boolean values, it 
1914      * can still be considered a Boolean OR operator because its return value, whatever the 
1915      * type, can be converted to a boolean value.</p>
1916      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1917      * re-compilations. However, in most cases you can use the logical OR operator of the 
1918      * Java language like this:
1919      * <pre>Js.be(var) || Js.be(other)</pre>
1920      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1921      * JavaScript expression since the Java compilers generally used are free to compile 
1922      * the expression into any byte codes they think efficient, making it too hard for the 
1923      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1924      * @param other A value or object.
1925      * @return The logical OR of the two operands.
1926      * @since 1.0
1927      * @javascript Re-compilers must replace the instance invocation of this method with the 
1928      * JavaScript expression:
1929      * <pre>p || other</pre>
1930      * where <tt>p</tt> is the current number instance of the invocation of this method.
1931      */
1932     public final JsObject or(Var<? extends JsObject> other) {
1933         return Js.or(this, other);
1934     }
1935 
1936     /**
1937      * <p>Logical OR operation, resembling that of JavaScript, performs the Boolean OR 
1938      * operation on the two values: it returns <tt>true</tt> if either the first operand or 
1939      * the second operand is <tt>true</tt>, or if both are <tt>true</tt>. If both operands 
1940      * are <tt>false</tt>, it returns <tt>false</tt>.</p>
1941      * <p>In JavaScript, although the || operator is most often used simply as a Boolean OR 
1942      * operator, it, like the && operator, has more complex behavior. It starts by evaluating 
1943      * its first operand, the expression on its left. If the value of this expression can 
1944      * be converted to <tt>true</tt>, it returns the unconverted value of the left-side 
1945      * expression. Otherwise, it evaluates its second operand, the expression on its right, 
1946      * and returns the value of that expression. In JavaScript 1.0 and JavaScript 1.1, if the 
1947      * left-side expression can be converted to <tt>true</tt>, the operator returns <tt>true</tt> 
1948      * and doesn't return the unconverted value of the left-side expression.</p>
1949      * <p>To make the second operand really late-evaluated or not evaluated in JS Simulation 
1950      * mode, resembling what happens in JavaScript, you may have to extend {@link Var} 
1951      * anonymously, returning the actual expression in the method overriding 
1952      * {@link Var#var()}.</p>
1953      * <p>As with the {@link #and(Object)} operation, you should avoid right-side 
1954      * operands that include side effects, unless you purposely want to use the fact that 
1955      * the right-side expression may not be evaluated in JavaScript.</p>
1956      * <p>Even when this operation is used with operands that are not boolean values, it 
1957      * can still be considered a Boolean OR operator because its return value, whatever the 
1958      * type, can be converted to a boolean value.</p>
1959      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1960      * re-compilations. However, in most cases you can use the logical OR operator of the 
1961      * Java language like this:
1962      * <pre>Js.be(var) || Js.be(other)</pre>
1963      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1964      * JavaScript expression since the Java compilers generally used are free to compile 
1965      * the expression into any byte codes they think efficient, making it too hard for the 
1966      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
1967      * @param other A value or object.
1968      * @return The logical OR of the two operands.
1969      * @since 1.0
1970      * @javascript Re-compilers must replace the instance invocation of this method with the 
1971      * JavaScript expression:
1972      * <pre>p || other</pre>
1973      * where <tt>p</tt> is the current number instance of the invocation of this method.
1974      */
1975     public final JsNumber or(JsNumber other) {
1976         return Js.or(this, other);
1977     }
1978 
1979     /**
1980      * <p>Conditional operation, resembling the ternary operator of JavaScript, returns the 
1981      * second operand if the first operand evaluates to <tt>true</tt>; Returns the third 
1982      * operand, otherwise.</p>
1983      * <p>The first operand of the conditional operation must be (or be convertible to) a 
1984      * boolean value. Usually this is the result of a comparison operation. The second and 
1985      * third operands may have any value. The value returned by the conditional operation 
1986      * depends on the boolean value of the first operand. If that operand is <tt>true</tt>, 
1987      * the value of the conditional expression is the value of the second operand. If the 
1988      * first operand is <tt>false</tt>, the value of the conditional expression is the 
1989      * value of the third operand.</p>
1990      * <p>To make the second and third operands really late-evaluated or not evaluated in 
1991      * JS Simulation mode, resembling what happens in JavaScript, you may have to extend 
1992      * {@link Var} anonymously, returning the actual expression in the method overriding 
1993      * {@link Var#var()}.</p>
1994      * <p>Note that, this method is probably useful in emulation codes just for perfect 
1995      * re-compilations. However, in most cases you can use the conditional operator of the 
1996      * Java language like this:
1997      * <pre>Js.be(test) ? var : other</pre>
1998      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
1999      * JavaScript expression since the Java compilers generally used are free to compile 
2000      * the expression into any byte codes they think efficient, making it too hard for the 
2001      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
2002      * @param other A value or object.
2003      * @return The second operand if the first operand evaluates to <tt>true</tt>; Otherwise, 
2004      * the third operand.
2005      * @since 1.0
2006      * @javascript Re-compilers must replace the instance invocation of this method with the 
2007      * JavaScript expression:
2008      * <pre>test ? p : other</pre>
2009      * where <tt>p</tt> is the current number instance of the invocation of this method.
2010      */
2011     public final Object cond(Object test, Object other) {
2012         return Js.cond(test, this, other);
2013     }
2014 
2015     /**
2016      * <p>Conditional operation, resembling the ternary operator of JavaScript, returns the 
2017      * second operand if the first operand evaluates to <tt>true</tt>; Returns the third 
2018      * operand, otherwise.</p>
2019      * <p>The first operand of the conditional operation must be (or be convertible to) a 
2020      * boolean value. Usually this is the result of a comparison operation. The second and 
2021      * third operands may have any value. The value returned by the conditional operation 
2022      * depends on the boolean value of the first operand. If that operand is <tt>true</tt>, 
2023      * the value of the conditional expression is the value of the second operand. If the 
2024      * first operand is <tt>false</tt>, the value of the conditional expression is the 
2025      * value of the third operand.</p>
2026      * <p>To make the second and third operands really late-evaluated or not evaluated in 
2027      * JS Simulation mode, resembling what happens in JavaScript, you may have to extend 
2028      * {@link Var} anonymously, returning the actual expression in the method overriding 
2029      * {@link Var#var()}.</p>
2030      * <p>Note that, this method is probably useful in emulation codes just for perfect 
2031      * re-compilations. However, in most cases you can use the conditional operator of the 
2032      * Java language like this:
2033      * <pre>Js.be(test) ? var : other</pre>
2034      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
2035      * JavaScript expression since the Java compilers generally used are free to compile 
2036      * the expression into any byte codes they think efficient, making it too hard for the 
2037      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
2038      * @param other A value or object.
2039      * @return The second operand if the first operand evaluates to <tt>true</tt>; Otherwise, 
2040      * the third operand.
2041      * @since 1.0
2042      * @javascript Re-compilers must replace the instance invocation of this method with the 
2043      * JavaScript expression:
2044      * <pre>test ? p : other</pre>
2045      * where <tt>p</tt> is the current number instance of the invocation of this method.
2046      */
2047     public final JsObject cond(Object test, Var<? extends JsObject> other) {
2048         return Js.cond(test, this, other);
2049     }
2050 
2051     /**
2052      * <p>Conditional operation, resembling the ternary operator of JavaScript, returns the 
2053      * second operand if the first operand evaluates to <tt>true</tt>; Returns the third 
2054      * operand, otherwise.</p>
2055      * <p>The first operand of the conditional operation must be (or be convertible to) a 
2056      * boolean value. Usually this is the result of a comparison operation. The second and 
2057      * third operands may have any value. The value returned by the conditional operation 
2058      * depends on the boolean value of the first operand. If that operand is <tt>true</tt>, 
2059      * the value of the conditional expression is the value of the second operand. If the 
2060      * first operand is <tt>false</tt>, the value of the conditional expression is the 
2061      * value of the third operand.</p>
2062      * <p>To make the second and third operands really late-evaluated or not evaluated in 
2063      * JS Simulation mode, resembling what happens in JavaScript, you may have to extend 
2064      * {@link Var} anonymously, returning the actual expression in the method overriding 
2065      * {@link Var#var()}.</p>
2066      * <p>Note that, this method is probably useful in emulation codes just for perfect 
2067      * re-compilations. However, in most cases you can use the conditional operator of the 
2068      * Java language like this:
2069      * <pre>Js.be(test) ? var : other</pre>
2070      * which is definitely late-evaluated but not necessarily re-compiled into an expected 
2071      * JavaScript expression since the Java compilers generally used are free to compile 
2072      * the expression into any byte codes they think efficient, making it too hard for the 
2073      * re-compilers to reconvert the byte codes to an expression in JavaScript.</p>
2074      * @param other A value or object.
2075      * @return The second operand if the first operand evaluates to <tt>true</tt>; Otherwise, 
2076      * the third operand.
2077      * @since 1.0
2078      * @javascript Re-compilers must replace the instance invocation of this method with the 
2079      * JavaScript expression:
2080      * <pre>test ? p : other</pre>
2081      * where <tt>p</tt> is the current number instance of the invocation of this method.
2082      */
2083     public final JsNumber cond(Object test, JsNumber other) {
2084         return Js.cond(test, this, other);
2085     }
2086 
2087     /**
2088      * <p>Performs unary negation on a 64-bit integer.</p>
2089      * <p>This operation converts a positive value to an equivalently negative value, and 
2090      * vice versa. If the operand is not a 64-bit integer, it attempts to convert it to one.</p>
2091      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2092      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2093      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2094      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2095      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2096      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2097      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2098      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2099      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2100      * bits involve the invocation of a predefined re-compiler dependent function while 
2101      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2102      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2103      * string representation of the <tt>long</tt> number in full 64-bit precision. </p>
2104      * @return The negation of the 64-bit integer.
2105      * @since 1.0
2106      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2107      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2108      * the same re-compiler would replace the byte codes of a negation operation on a long number, 
2109      * such as the byte codes compiled from the following Java expression:  
2110      * <pre>-((Number)p).longValue()</pre>
2111      * where <tt>p</tt> is the current number instance of the invocation of this method.
2112      */
2113     public final long lneg() {
2114         return Js.lneg(this);
2115     }
2116 
2117     /**
2118      * <p>The 64-bit bitwise-NOT operation, casting the operand to a <tt>long</tt> number 
2119      * if it is not 64-bit, operates by reversing all bits in the 64-bit integer.</p>
2120      * <p>Because of the way signed integers are represented in JavaScript, applying this 
2121      * operation to a value is equivalent to changing its sign and subtracting 1.</p>
2122      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2123      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2124      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2125      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2126      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2127      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2128      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2129      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2130      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2131      * bits involve the invocation of a predefined re-compiler dependent function while 
2132      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2133      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2134      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2135      * @return The bitwise-NOT of the 64-bit integer.
2136      * @since 1.0
2137      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2138      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2139      * the same re-compiler would replace the byte codes of a bitwise-NOT operation on a long number, 
2140      * such as the byte codes compiled from the following Java expression:  
2141      * <pre>~((Number)p).longValue()</pre>
2142      * where <tt>p</tt> is the current number instance of the invocation of this method.
2143      */
2144     public final long lnot() {
2145         return Js.lnot(this);
2146     }
2147 
2148     /**
2149      * <p>Adds two 64-bit integers, casting the operands to <tt>long</tt> numbers if any 
2150      * one of them is not a 64-bit integer.</p>
2151      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2152      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2153      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2154      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2155      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2156      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2157      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2158      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2159      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2160      * bits involve the invocation of a predefined re-compiler dependent function while 
2161      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2162      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2163      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2164      * @param other Any numeric value.
2165      * @return The sum of the two 64-bit integers.
2166      * @since 1.0
2167      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2168      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2169      * the same re-compiler would replace the byte codes of an addition operation on two long numbers, 
2170      * such as the byte codes compiled from the following Java expression:  
2171      * <pre>((Number)p).longValue() + ((Number)other).longValue()</pre>
2172      * where <tt>p</tt> is the current number instance of the invocation of this method.
2173      */
2174     public final long ladd(Object other) {
2175         return Js.ladd(this, other);
2176     }
2177 
2178     /**
2179      * <p>Subtracts the second 64-bit integer from the first 64-bit integer, casting the 
2180      * operands to <tt>long</tt> numbers if any one of them is not a 64-bit integer.</p>
2181      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2182      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2183      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2184      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2185      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2186      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2187      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2188      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2189      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2190      * bits involve the invocation of a predefined re-compiler dependent function while 
2191      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2192      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2193      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2194      * @param other Any numeric value.
2195      * @return The difference between the two 64-bit integers.
2196      * @since 1.0
2197      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2198      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2199      * the same re-compiler would replace the byte codes of a subtraction operation on two long numbers, 
2200      * such as the byte codes compiled from the following Java expression:  
2201      * <pre>((Number)p).longValue() - ((Number)other).longValue()</pre>
2202      * where <tt>p</tt> is the current number instance of the invocation of this method.
2203      */
2204     public final long lsub(Object other) {
2205         return Js.lsub(this, other);
2206     }
2207 
2208     /**
2209      * <p>Multiplies the two 64-bit integer, casting the operands to <tt>long</tt> numbers 
2210      * if any one of them is not a 64-bit integer.</p>
2211      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2212      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2213      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2214      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2215      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2216      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2217      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2218      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2219      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2220      * bits involve the invocation of a predefined re-compiler dependent function while 
2221      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2222      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2223      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2224      * @param other Any numeric value.
2225      * @return The product of the two 64-bit integers.
2226      * @since 1.0
2227      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2228      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2229      * the same re-compiler would replace the byte codes of a multiplication operation on two long numbers, 
2230      * such as the byte codes compiled from the following Java expression:  
2231      * <pre>((Number)p).longValue() * ((Number)other).longValue()</pre>
2232      * where <tt>p</tt> is the current number instance of the invocation of this method.
2233      */
2234     public final long lmul(Object other) {
2235         return Js.lmul(this, other);
2236     }
2237 
2238     /**
2239      * <p>Divides the first 64-bit integer by the second 64-bit integer, casting the operands 
2240      * to <tt>long</tt> numbers if any one of them is not a 64-bit integer.</p>
2241      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2242      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2243      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2244      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2245      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2246      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2247      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2248      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2249      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2250      * bits involve the invocation of a predefined re-compiler dependent function while 
2251      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2252      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2253      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2254      * @param other Any numeric value.
2255      * @return The quotient of the two 64-bit integers.
2256      * @since 1.0
2257      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2258      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2259      * the same re-compiler would replace the byte codes of an division operation on two long numbers, 
2260      * such as the byte codes compiled from the following Java expression:  
2261      * <pre>((Number)p).longValue() / ((Number)other).longValue()</pre>
2262      * where <tt>p</tt> is the current number instance of the invocation of this method.
2263      */
2264     public final long ldiv(Object other) {
2265         return Js.ldiv(this, other);
2266     }
2267 
2268     /**
2269      * <p>Computes the first operand modulo the second operand, casting the operands to 
2270      * <tt>long</tt> numbers if any one of them is not a 64-bit integer.</p>
2271      * <p>The operation returns the remainder when the first operand is divided by the 
2272      * second operand a certain number of times. The sign of the result is the same as the 
2273      * sign of the first operand.</p>
2274      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2275      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2276      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2277      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2278      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2279      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2280      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2281      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2282      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2283      * bits involve the invocation of a predefined re-compiler dependent function while 
2284      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2285      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2286      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2287      * @param other Any numeric value.
2288      * @return The remainder.
2289      * @since 1.0
2290      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2291      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2292      * the same re-compiler would replace the byte codes of a modulo operation on two long numbers, 
2293      * such as the byte codes compiled from the following Java expression:  
2294      * <pre>((Number)p).longValue() % ((Number)other).longValue()</pre>
2295      * where <tt>p</tt> is the current number instance of the invocation of this method.
2296      */
2297     public final long lmod(Object other) {
2298         return Js.lmod(this, other);
2299     }
2300 
2301     /**
2302      * <p>The 64-bit shift-left operation, casting the first operand to a <tt>long</tt> 
2303      * number if it is not 64-bit, moves all bits in it to the left by the number of places 
2304      * specified in the second operand, which should be an integer between 0 and 63.</p>
2305      * <p>A zero is used for the new first bit, and the value of the 64th bit is lost. 
2306      * Shifting a value left by one position is equivalent to multiplying by 2, shifting 
2307      * two positions is equivalent to multiplying by 4, etc.</p>
2308      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2309      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2310      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2311      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2312      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2313      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2314      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2315      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2316      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2317      * bits involve the invocation of a predefined re-compiler dependent function while 
2318      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2319      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2320      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2321      * @param n The number of bits to shift.
2322      * @return The shifted 64-bit integer.
2323      * @since 1.0
2324      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2325      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2326      * the same re-compiler would replace the byte codes of a shift-left operation on a long number, 
2327      * such as the byte codes compiled from the following Java expression:  
2328      * <pre>((Number)p).longValue() << n</pre>
2329      * where <tt>p</tt> is the current number instance of the invocation of this method.
2330      */
2331     public final long lshl(int n) {
2332         return Js.lshl(this, n);
2333     }
2334 
2335     /**
2336      * <p>The 64-bit shift-right operation, casting the first operand to a <tt>long</tt> 
2337      * number if it is not 64-bit, moves all bits in it to the right by the number of 
2338      * places specified in the second operand (an integer between 0 and 63). Bits that are 
2339      * shifted off the right are lost. The bits filled in on the left depend on the sign 
2340      * bit of the original operand, in order to preserve the sign of the result. If the 
2341      * first operand is positive, the result has zeros placed in the high bits; if the 
2342      * first operand is negative, the result has ones placed in the high bits.</p>
2343      * <p>Shifting a value right one place is equivalent to dividing by 2 (discarding the 
2344      * remainder), shifting right two places is equivalent to integer division by 4, and 
2345      * so on.</p>
2346      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2347      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2348      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2349      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2350      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2351      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2352      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2353      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2354      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2355      * bits involve the invocation of a predefined re-compiler dependent function while 
2356      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2357      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2358      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2359      * @param n The number of bits to shift.
2360      * @return The shifted 64-bit integer.
2361      * @since 1.0
2362      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2363      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2364      * the same re-compiler would replace the byte codes of a shift-right operation on a long number, 
2365      * such as the byte codes compiled from the following Java expression:  
2366      * <pre>((Number)p).longValue() >> n</pre>
2367      * where <tt>p</tt> is the current number instance of the invocation of this method.
2368      */
2369     public final long lshr(int n) {
2370         return Js.lshr(this, n);
2371     }
2372 
2373     /**
2374      * <p>The 64-bit shift-right-unsigned operation, casting the first operand to a 
2375      * <tt>long</tt> number if it is not 64-bit, moves all bits in it to the right by the 
2376      * number of places specified in the second operand (an integer between 0 and 63). Bits 
2377      * that are shifted off the right are lost. The result has zeros placed in the high 
2378      * bits.</p>
2379      * <p>This operation is just like {@link #lshr(int)}, except that the bits shifted 
2380      * in on the left are always zero, regardless of the sign of the first operand.</p>
2381      * <p>Shifting a value right one place is equivalent to dividing by 2 (discarding the 
2382      * remainder), shifting right two places is equivalent to integer division by 4, and 
2383      * so on.</p>
2384      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2385      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2386      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2387      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2388      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2389      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2390      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2391      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2392      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2393      * bits involve the invocation of a predefined re-compiler dependent function while 
2394      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2395      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2396      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2397      * @param n The number of bits to shift.
2398      * @return The shifted 64-bit integer.
2399      * @since 1.0
2400      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2401      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2402      * the same re-compiler would replace the byte codes of an unsigned shift-right operation on a long number, 
2403      * such as the byte codes compiled from the following Java expression:  
2404      * <pre>((Number)p).longValue() >>> n</pre>
2405      * where <tt>p</tt> is the current number instance of the invocation of this method.
2406      */
2407     public final long lshru(int n) {
2408         return Js.lshru(this, n);
2409     }
2410 
2411     /**
2412      * <p>The 64-bit bitwise-AND operation, casting the operands to <tt>long</tt> numbers 
2413      * if any one of them is not a 64-bit integer, performs a boolean AND operation on each 
2414      * bit of the 64-bit integers. A bit is set in the result only if the corresponding 
2415      * bit is set in both operands.</p>
2416      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2417      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2418      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2419      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2420      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2421      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2422      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2423      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2424      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2425      * bits involve the invocation of a predefined re-compiler dependent function while 
2426      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2427      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2428      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2429      * @param other Any numeric value.
2430      * @return The bitwise-AND of the two 64-bit integers.
2431      * @since 1.0
2432      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2433      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2434      * the same re-compiler would replace the byte codes of a bitwise AND operation on two long numbers, 
2435      * such as the byte codes compiled from the following Java expression:  
2436      * <pre>((Number)p).longValue() & ((Number)other).longValue()</pre>
2437      * where <tt>p</tt> is the current number instance of the invocation of this method.
2438      */
2439     public final long land(Object other) {
2440         return Js.land(valueOf(), other);
2441     }
2442 
2443     /**
2444      * <p>The 64-bit bitwise-OR operation, casting the operands to <tt>long</tt> numbers if 
2445      * any one of them is not a 64-bit integer, performs a boolean OR operation on each bit 
2446      * of the 64-bit integers. A bit is set in the result if the corresponding bit is set 
2447      * in one or both of the operands.</p>
2448      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2449      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2450      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2451      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2452      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2453      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2454      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2455      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2456      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2457      * bits involve the invocation of a predefined re-compiler dependent function while 
2458      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2459      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2460      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2461      * @param other Any numeric value.
2462      * @return The bitwise-OR of the two 64-bit integers.
2463      * @since 1.0
2464      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2465      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2466      * the same re-compiler would replace the byte codes of a bitwise OR operation on two long numbers, 
2467      * such as the byte codes compiled from the following Java expression:  
2468      * <pre>((Number)p).longValue() | ((Number)other).longValue()</pre>
2469      * where <tt>p</tt> is the current number instance of the invocation of this method.
2470      */
2471     public final long lor(Object other) {
2472         return Js.lor(valueOf(), other);
2473     }
2474 
2475     /**
2476      * <p>The 64-bit bitwise-XOR operation, casting the operands to <tt>long</tt> numbers 
2477      * if any one of them is not a 64-bit integer, performs a boolean exclusive OR operation 
2478      * on each bit of the 64-bit integers. Exclusive OR means that either operand one is 
2479      * <tt>true</tt> or operand two is <tt>true</tt>, but not both. A bit is set in this 
2480      * operation's result if a corresponding bit is set in one (but not both) of the two 
2481      * operands.</p>
2482      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2483      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2484      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2485      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2486      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2487      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2488      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2489      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2490      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2491      * bits involve the invocation of a predefined re-compiler dependent function while 
2492      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2493      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2494      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2495      * @param other Any numeric value.
2496      * @return The bitwise-exclusive-OR of the two 64-bit integers.
2497      * @since 1.0
2498      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2499      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2500      * the same re-compiler would replace the byte codes of a bitwise exclusive OR operation on two long numbers, 
2501      * such as the byte codes compiled from the following Java expression:  
2502      * <pre>((Number)p).longValue() ^ ((Number)other).longValue()</pre>
2503      * where <tt>p</tt> is the current number instance of the invocation of this method.
2504      */
2505     public final long lxor(Object other) {
2506         return Js.lxor(valueOf(), other);
2507     }
2508 
2509     /**
2510      * <p>The 64-bit less-than operation, casting the operands to <tt>long</tt> numbers if 
2511      * any one of them is not a 64-bit integer, evaluates to <tt>true</tt> if the first 
2512      * operand is less than the second operand; otherwise it evaluates to <tt>false</tt>.</p>
2513      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2514      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2515      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2516      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2517      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2518      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2519      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2520      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2521      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2522      * bits involve the invocation of a predefined re-compiler dependent function while 
2523      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2524      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2525      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2526      * @param other Any numeric value.
2527      * @return <tt>true</tt> if the first operand is less than the second operand; 
2528      * otherwise <tt>false</tt>.
2529      * @since 1.0
2530      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2531      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2532      * the same re-compiler would replace the byte codes of a less-than operation on two long numbers, 
2533      * such as the byte codes compiled from the following Java expression:  
2534      * <pre>((Number)p).longValue() < ((Number)other).longValue()</pre>
2535      * where <tt>p</tt> is the current number instance of the invocation of this method.
2536      */
2537     public final boolean llt(Object other) {
2538         return Js.llt(valueOf(), other);
2539     }
2540 
2541     /**
2542      * <p>The 64-bit greater-than operation, casting the operands to <tt>long</tt> numbers 
2543      * if any one of them is not a 64-bit integer, evaluates to <tt>true</tt> if the first 
2544      * operand is greater than the second operand; otherwise it evaluates to <tt>false</tt>.</p>
2545      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2546      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2547      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2548      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2549      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2550      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2551      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2552      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2553      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2554      * bits involve the invocation of a predefined re-compiler dependent function while 
2555      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2556      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2557      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2558      * @param other Any numeric value.
2559      * @return <tt>true</tt> if the first operand is greater than the second operand; 
2560      * otherwise <tt>false</tt>.
2561      * @since 1.0
2562      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2563      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2564      * the same re-compiler would replace the byte codes of a greater-than operation on two long numbers, 
2565      * such as the byte codes compiled from the following Java expression:  
2566      * <pre>((Number)p).longValue() > ((Number)other).longValue()</pre>
2567      * where <tt>p</tt> is the current number instance of the invocation of this method.
2568      */
2569     public final boolean lgt(Object other) {
2570         return Js.lgt(valueOf(), other);
2571     }
2572 
2573     /**
2574      * <p>The 64-bit less-than-or-equal operation, casting the operands to <tt>long</tt> 
2575      * numbers if any one of them is not a 64-bit integer, evaluates to <tt>true</tt> if 
2576      * the first operand is less than or equal to the second operand; otherwise it evaluates 
2577      * to <tt>false</tt>.</p>
2578      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2579      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2580      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2581      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2582      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2583      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2584      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2585      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2586      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2587      * bits involve the invocation of a predefined re-compiler dependent function while 
2588      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2589      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2590      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2591      * @param other Any numeric value.
2592      * @return <tt>true</tt> if the first operand is less than or equal to the second operand; 
2593      * otherwise <tt>false</tt>.
2594      * @since 1.0
2595      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2596      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2597      * the same re-compiler would replace the byte codes of a less-than-or-equal operation on two long numbers, 
2598      * such as the byte codes compiled from the following Java expression:  
2599      * <pre>((Number)p).longValue() <= ((Number)other).longValue()</pre>
2600      * where <tt>p</tt> is the current number instance of the invocation of this method.
2601      */
2602     public final boolean llte(Object other) {
2603         return Js.llte(valueOf(), other);
2604     }
2605 
2606     /**
2607      * <p>The 64-bit greater-than-or-equal operation, casting the operands to <tt>long</tt> 
2608      * numbers if any one of them is not a 64-bit integer, evaluates to <tt>true</tt> if the 
2609      * first operand is greater than or equal to the second operand; otherwise it evaluates 
2610      * to <tt>false</tt>.</p>
2611      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2612      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2613      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2614      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2615      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2616      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2617      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2618      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2619      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2620      * bits involve the invocation of a predefined re-compiler dependent function while 
2621      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2622      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2623      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2624      * @param other Any numeric value.
2625      * @return <tt>true</tt> if the first operand is greater than or equal to the second operand; 
2626      * otherwise <tt>false</tt>.
2627      * @since 1.0
2628      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2629      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2630      * the same re-compiler would replace the byte codes of a greater-than-or-equal operation on two long numbers, 
2631      * such as the byte codes compiled from the following Java expression:  
2632      * <pre>((Number)p).longValue() >= ((Number)other).longValue()</pre>
2633      * where <tt>p</tt> is the current number instance of the invocation of this method.
2634      */
2635     public final boolean lgte(Object other) {
2636         return Js.lgte(valueOf(), other);
2637     }
2638 
2639     /**
2640      * <p>Checks whether the two 64-bit integers are "equal", casting the operands to 
2641      * <tt>long</tt> numbers if any one of them is not a 64-bit integer.</p>
2642      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2643      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2644      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2645      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2646      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2647      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2648      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2649      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2650      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2651      * bits involve the invocation of a predefined re-compiler dependent function while 
2652      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2653      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2654      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2655      * @param other Any numeric value.
2656      * @return <tt>true</tt> if the first operand equals the second; <tt>false</tt>, 
2657      * otherwise;
2658      * @since 1.0
2659      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2660      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2661      * the same re-compiler would replace the byte codes of an equality operation on two long numbers, 
2662      * such as the byte codes compiled from the following Java expression:  
2663      * <pre>((Number)p).longValue() == ((Number)other).longValue()</pre>
2664      * where <tt>p</tt> is the current number instance of the invocation of this method.
2665      */
2666     public final boolean leq(Object other) {
2667         return Js.leq(valueOf(), other);
2668     }
2669 
2670     /**
2671      * <p>Checks whether the two 64-bit integers are not "equal", casting the operands to 
2672      * <tt>long</tt> numbers if any one of them is not a 64-bit integer.</p>
2673      * <p>Note that, although the representation of <tt>long</tt> numbers in JavaScript and 
2674      * the 64-bit operations on them are re-compiler dependent, the re-compilers are expected 
2675      * to express 64-bit integers as JavaScript objects or arrays, with a bitwise or arithmetc 
2676      * operation on <tt>long</tt> numbers converted to the invocation of a predefined global 
2677      * function that is also re-compiler dependent. The <tt>valueOf()</tt> method of the object 
2678      * or array representing a 64-bit integer must return a number representing the <tt>long</tt> 
2679      * number in JavaScript limited bits range, so that a <tt>long</tt> integer in JavaScript 
2680      * naturally evaluates to a normal number without extra casting codes. That is, casting 
2681      * a normal number to a <tt>long</tt> integer, or creating a <tt>long</tt> integer from 
2682      * bits involve the invocation of a predefined re-compiler dependent function while 
2683      * casting a <tt>long</tt> integer to a normal number is expected to be ignored by re-compilation. 
2684      * In addition, the <tt>toString()</tt> method of that object or array must return a 
2685      * string representation of the <tt>long</tt> number in full 64-bit precision.</p>
2686      * @param other Any numeric value.
2687      * @return <tt>false</tt> if the first operand equals the second; <tt>true</tt>, 
2688      * otherwise;
2689      * @since 1.0
2690      * @javascript A re-compiler is expected to replace the instance invocation of this method 
2691      * with the invocation of a predefined and re-compiler dependent function, with an invocation of which 
2692      * the same re-compiler would replace the byte codes of an inequality operation on two long numbers, 
2693      * such as the byte codes compiled from the following Java expression:  
2694      * <pre>((Number)p).longValue() != ((Number)other).longValue()</pre>
2695      * where <tt>p</tt> is the current number instance of the invocation of this method.
2696      */
2697     public final boolean lneq(Object other) {
2698         return Js.lneq(valueOf(), other);
2699     }
2700 }