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 having >> BoxedFloat in its compiled method literal array, >> #BoxedFloat64->BoxedFloat64 instead of #Float->Float. >> >> But it looks like recompiling the whole image fixes this. >> >> nicolai >> > > > Would it makes sense if > BoxedFloat64 species returns Float ? >
This is because I am about to fix some failing tests in pharo. Tests like
self assert: result class = Float can be replaced by
self assert: result isFloat
Yes good.
But for tests like
self assert: resultClass = Float I don't want to write self assert: resultClass = BoxedFloat64
What'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 BoxedFloat64 Some will be represented by an immediate float (it depends both on VM Spur-64 bits/ and float range)
any ideas
Not 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 anMessage would 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 and just 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: false
self assert: (tally receivers second theClass == Float).
which is now BoxedFloat64 instead of Float
For 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 either
self assert: ({Float. BoxedFloat64. SmallFloat64 } includes: tallyreceivers second theClass)
or
self 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:
>>> On Feb 18, 2016, at 2:47 AM, Nicolai Hess nicolaihess@gmail.com >>> wrote: >>> >>> Because we have compiled methods with BoxedFloat64 associations in >>> the >>> methods literals, but the source code still shows only "Float". >>> >>> 17638 >>> https://pharo.fogbugz.com/f/cases/17638/Browsing-calls-on-BoxedFloat64-shows-methods-with-reference-to-BoxedFloat64-in-the-code >>> Browsing calls on BoxedFloat64 shows methods with reference to BoxedFloat64 >>> in the code >>> >>>
_,,,^..^,,,_ best, Eliot