Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 359293

Summary: JS: Generic "number"
Product: z_Archived Reporter: Scott Greer <greer>
Component: EDTAssignee: Project Inbox <edt.javascriptgen-inbox>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: mheitz, svihovec
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Scott Greer CLA 2011-09-28 15:05:46 EDT 
In RBD, it's possible to declare functions that accept a generic number;  this is like "any" but restricted to the various numeric types. 

Matt will be scheduling a meeting to discuss exactly how we implement this in EDT given that "number" is now a formally-defined type and given that we'd like as much similarity in results between Java and JavaScript.
Comment 1 Scott Greer CLA 2011-09-28 16:15:18 EDT 
There are several relevant FVT tests:  FVT.primitives.TestNumber, FVT.operators.extensiveIsaTests, FVT.librarySupport.extensiveMathLibTests
Comment 2 Scott Greer CLA 2011-10-31 15:06:25 EDT 
Number support required these changes

* Previously, JS generated all type conversion ops as "from<sourcetype>" whereas Java gen allows each defined type op to be used-as in the runtime (making it easier to add new type ops since you don't have to change the generator). However, Java can do that because it can take advantage of overloading.  JS could do the same, but then it would require some mechanism to support overloading in external types.  We have that now, however, the resulting "name mangling" makes these external function names less maintainable.   We also didn't want to overhaul the function names in edt_runtime.js at this late point in the cycle 

Given all that, I've implemented a compromise in which JS gen preserves the existing convention for conversion ops but allows additional type ops to work as-is.

* Updated various genConversion template methods to take advantage of the change above.


* Re-named the JS RT type for ENumber from AnyNumber to ENumber (and removed the erroneous declaration of a primitive type for ENumber), and finished the work that Ji Yong had started to add the various type ops.

* Removed the genConversion routine from AnyTypeTemplate, since the logic was already duplicated in TypeTemplate.

* Since RBD's runtime represents ENumber as essentially boxing the actual numeric type, I changed the various needsConversion functions in the type templates (e.g., DecimalTypeTemplate) to ensure that conversions to ENumber would not be ignored.

* Created a proper NumberTypeTEmplate;  previously, the ENumber type was incorrectly mapped to NumTypeTemplate (which I've left in place as an empty template).

* Runtime changes
  *  Added various asNumber and fromENumber functions.
  *  Renamed AnyNumber to ENumber
Comment 3 Lisa Lasher CLA 2011-11-04 11:48:04 EDT 
Closing this work item