Bugzilla – Full Text Bug Listing
| Summary: | XTend Expressions don't respect floating point cast operations | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] M2T | Reporter: | Miles Parker <milesparker> | ||||
| Component: | Xpand | Assignee: | Project Inbox <m2t.xpand-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | sven.efftinge | ||||
| Version: | 1.0.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 184088 [details]
Test for Cast Issue
Workflow expects test to be work directory.
Hi Miles, casts do not have any effect on expressions. They are not used to choose the right operation or function to call. That is because Xtend as well as Xpand do polymorphic dispatch at runtime based on th actual runtime types. Casts are just a static type thing and do not coerce values. You need to invoke a real coercion function. Note that the type double does not exist and what you ware looking for is the type "Real". But that still wouldn't change any objects when used in casts. (In reply to comment #2) > Hi Miles, > > casts do not have any effect on expressions. They are not used to choose the > right operation or function to call. Thanks Sven, I probably knew that in some other part of my brain.. > That is because Xtend as well as Xpand do polymorphic dispatch at runtime based > on th actual runtime types. Casts are just a static type thing and do not > coerce values. You need to invoke a real coercion function. Like...? I mean I think my deeper question is given the way that dispatch is handled, and given how input parameters are handled, how can we let runtime know that we want to treat a provided value *as if* it were the upcast (or in the case of XTEnd, downcast) value? Or basically just to say "I want this value to be of this type." I tried casting form the GLOBALVAR, thinking this would force the appropriate type to be selected at parse time, but that didn't either. So there is some kind of magic going on there where if the global var is defined like "4", it is assumed to be an Integer whereas if it is "4.0" it is assumed to be a Real. I can do something silly like take the value, convert it to a string, add ".0" and convert it back, but it would be nice to be able to just coerce it directly. > Note that the type double does not exist and what you ware looking for is the > type "Real". But that still wouldn't change any objects when used in casts. Yes, I did a test case with Real as well.. (In reply to comment #3) > (In reply to comment #2) > > That is because Xtend as well as Xpand do polymorphic dispatch at runtime based > > on th actual runtime types. Casts are just a static type thing and do not > > coerce values. You need to invoke a real coercion function. > > Like...? A Java extension which converts a long or int into a float or double should work. """ 4.real()/4.1 """ |
[Please see enclosed test project] In attempting to write a sampling method, such that for example of the list {0,1,2...} I could get list.sample(4) {0,3,7..} I came across an apparent problem with how XTend appears to coerce doubles, or rather that it doesn't. I thought this might have to do with bringing global vars in, but it actually happens even with coerced values in straight math. IOTW the following: «1 / 3 != 0» //expect false «1.0 / 3.0 != 0» //expect true «((double) 1) / ((double) 3) != 0» //expect true Returns: false //expect false true //expect true false //expect true Perhaps this is the known and intended behavior, but I've never come across it before and I don't see it covered in manual, except: "Casting The expression language is statically type checked. Although there are many concepts that help the programmer to have really good static type information, sometimes. One knows more about the real type than the system. To explicitly give the system such an information casts are available. Casts are 100% static, so you do not need them, if you never statically typecheck your expressions! The syntax for casts is very Java-like: ((String)unTypedList.get(0)).toUpperCase()"