[Pharo-project] Issue 3329 in pharo: Object>>closeTo:
Status: Accepted Owner: alexandre.bergel Labels: Milestone-1.3 New issue 3329 by alexandre.bergel: Object>>closeTo: http://code.google.com/p/pharo/issues/detail?id=3329 closeTo: is used to compare floats. closeTo: is defined on Object, which really does not make sense.
Comment #1 on issue 3329 by jbaptiste.arnaud: Object>>closeTo: http://code.google.com/p/pharo/issues/detail?id=3329 Not only Float, Point and Number too. The Behavior on Object is just a default Behavior, If the object can be compare and is equal return try, else false. I think is a artifact of defensive programming, "ok we declare the method in Object to be sure it's defined somewhere." Nevertheless that don't really making sense to create this kind of method on Object, what is relevant to decide if a object is "close" of another object. The semantics is completely ambiguous. i think we should remove that crap. I think we can discuss about renaming,remove or Replace the other occurrence of #closeTo: too.
Comment #2 on issue 3329 by alexandre.bergel: Object>>closeTo: http://code.google.com/p/pharo/issues/detail?id=3329 Yeah, I agree. But it is essentially interesting for Float: Float>>closeTo: num "are these two numbers close?" num isNumber ifFalse: [^[self = num] ifError: [false]]. self = 0.0 ifTrue: [^num abs < 0.0001]. num = 0 ifTrue: [^self abs < 0.0001]. ^self = num asFloat or: [(self - num) abs / (self abs max: num abs) < 0.0001] The problem is that you can two float which are the same, but have a different internal representation. But still, having closeTo: on Object does not make sense. Does it make sense to be able to do 'abc' closeTo: 'abc' ?
Updates: Labels: -Milestone-1.3 Comment #3 on issue 3329 by marcus.d...@gmail.com: Object>>closeTo: http://code.google.com/p/pharo/issues/detail?id=3329 (No comment was entered for this change.)
participants (1)
-
pharo＠googlecode.com