2016-02-24 17:18 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:Hi Nicolai,On Wed, Feb 24, 2016 at 3:28 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:2016-02-24 12:04 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:2016-02-24 11:15 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:2016-02-24 11:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:2016-02-24 10:02 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:2016-02-24 9:31 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:2016-02-23 8:48 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:2016-02-23 3:55 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:Hi Nicolai,there is a hairy script that moves methods around the hierarchy. IIRC Float is renamed to BoxedFloat64, then a new Float is introduced, then BoxedFloat64 made to inherit from it. It's likely that the last step of this script, which replaces the methodClassAssociations in the moved methods (makes those BoxedFloat64 methods that used to be Float or maybe vice verse) with the right association, didn't work.I don't know how the Pharo 5 image is built. If it is incremental then just write a script to fix the associations. But if the image is produced by a bootstrap you'll need to track down the script that creates the revised Float hierarchy and fix it to work properly in Pharo.
_,,,^..^,,,_ (phone)Thanks Eliot,The methods for c lass Float and BoxedFloat are looking fine. Whats wrong is, that some other methods referring to class Float in there source, now havingBoxedFloat in its compiled method literal array,
#BoxedFloat64->BoxedFloat64 instead of #Float->Float.But it looks like recompiling the whole image fixes this.nicolaiWould it makes sense ifBoxedFloat64 species returns Float ?This is because I am about to fix some failing tests in pharo.Tests likeself assert: result class = Floatcan be replaced byself assert: result isFloatYes good.
But for tests likeself assert: resultClass = FloatI don't want to writeself assert: resultClass = BoxedFloat64What's this test about???Is it for testing that extreme exponent (very big and very small Float) cannot be represented by an immediate float?
and looking for an easy way to check if the result class is "like" Float
self assert: resultClass species = Float species ?
self assert: resultClass isFloatClass ?self assert: resultClass new isFloat ?No because not all floats will be represented as a BoxedFloat64Some will be represented by an immediate float (it depends both on VM Spur-64 bits/ and float range)
any ideasNot without the intention of the test...One failing test is about completion and the "context" for searching possible completions for messages, for example#(1 2 3) anMessage...would recognize #(1 2 3) as an array and search completions starting with "anMessage" in class (and superclasses) of Array
2r1.1e2 anMessagewould recognize "2r1.1e2" as a Float, but this test now fails because the class for the literal 2r1.1e2 is not Float but BoxedFloat64.As I consider BoxedFloat64 as an implementation detail, I would like to make this test independent of the actual Float class andjust make an assert that the context class, is "like a " Float. (The completion menu would still show BoxedFloat64, but thats ok)The second test is
tally := MessageTally
tallySendsTo: nil
inBlock: [ 3.14159 printString ]
showTree: true
closeAfter: false
openResultWindow: falseself assert: (tally receivers second theClass == Float).which is now BoxedFloat64 instead of FloatFor these usages, testing class = BoxedFloat64 will fail in a 64 bit Spur
But isFloat sounds OK for me.Because if it quakes like a Float...
All Float subclasses should support the same public API.If you fear a fake isFloat (defensive programming?) then you could eventually test superclass = Float, but it's more fragile than isFloat
(your test is entering into the implementation details).So, you mean, put isFloat on the class side of BoxedFloat64 (and SmallFloat64)? Or maybe isFloatClass ?I would write eitherself assert: ({Float. BoxedFloat64. SmallFloat64 } includes: tally receivers second theClass)orself assert: (tally receivers second theClass includesBehavior: Float)I much prefer the second.I don't like isFloatClass just for a test. Introducing protocol just for tests is suspect.Yes, I was thinking to send isFloat to the instance and let the class alone.If you really want to assert the class, then all you can safely/portably test is the class hierarchy as I tried to tell with superclass, but as Eliot much more accurately expressed with includesBehavior:
Because we have compiled methods with BoxedFloat64 associations in themethods literals, but the source code still shows only "Float".
17638 Browsing calls on BoxedFloat64 shows methods with reference to BoxedFloat64 in the code_,,,^..^,,,_best, Eliot