The Crystal programming language | http://crystal-lang.org | Fund Crystal's development: http://is.gd/X7PRtI | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/
That was suggested in this chat quite a few days ago by someone, because 99% of use cases are going to be in the form of a binary operator, not the method call syntax...and can only use a whitelisted set of symbols there
I'm not sold on it either, but
Origin::Vector3.nearly_equal? v1, v2 user code calling Origin::Util.nearly_equal? f1, f2, rel_tol, abs_tol internal code isn't too bad I suppose
why not
v1 =~ v2
or is that how it was?
Or did I misunderstand?
oh sorry no, looking at the code https://git.mfiano.net/mfiano/origin.cr/src/branch/master/src/origin/scalar.cr
it looked like it was used as
Origin::Scalar.=~ v1, v2
due to the
extend self
It is internally, because you cannot use the method call notation without a module prefix
The extend self was needed too
id also look into
def ===
which is used for case equality, which could forward to
=~
You pretty much never want to use
== on two floats, let alone 2 aggregates of floats, so == calls out to =~ incase the user didn't use the more explicit approximation method, which would clearly be an error. The problem is, == must take exactly 1 receiver and 1 argument, so the defaults for rel_tol and abs_tol must be used in that case.
Which is also an error, albeit a lesser one
So there is no good solution that I know of
The reason for using the
=~ symbol over == to begin with is because of this...the parser treats all = suffixed method names as setters, and errors on arity overloading away from that.
I think we discussed this already though :)
I personally don't think an operator should be used for a variadic function, and also because
=~ doesn't mean the usual to Crystal programmers.
So I will more than likely move to
nearly_equals?
I might even go as far as to
def ==; {{ raise ... }; end for vector types.
err with an
other in there somewhere :)
Hmm, so with inheritance those pesky class methods are giving me issues again
It's saying that a .new method with 2 arguments doesn't exist when calling .rand...but i can call .new manually with 2 args...i haven't quite figured it out yet...
Shoved everything in 1 file for now, sorry if it's hard to read like that
I dunno though
def self.zero : self
new 0.0
end
def self.one : self
new 1.0
end
but if they're expected to be a singleton. I.e. each call to
V2::ZERO returns the same instance then you could use a lazily initialized class getter
They are constants to prevent allocation during tight loops when comparing instances against common values, etc
They exist purely for having stable values that cannot change or needing to be allocated
nvm, these are structs