Describe what plus() does without using the word “add”.
“Hello, my brain works by this quirky convention that is not at all universal so I want the engine changed to be that.” Be careful of these traps.
Describe what plus() does without using the word “add”.
“Hello, my brain works by this quirky convention that is not at all universal so I want the engine changed to be that.” Be careful of these traps.
========================================================
addConvert, multConvert, divConvert, subConvert
addModify, multModify, divModify, subModify
addTransform, multTransform, divTransform, subTransform
addAlter, multAlter, divAlter, subAlter
addMorph, multMorph, divMorph, subMorph
addReplace, multiReplace, divReplace, subReplace
If i saw 2 methods, add and plus, i would think there was an error and assume both did the same operation and simply pick one to use 100% of the time. I may, eventually read the doc and realise they are different. When i see add and addlocal i realize immediatly they are similar, both say add, but one is obviously different. Ill immediately consult the doc and see the difference.
Me and a friend of mine are doing a multi-purpose framework written in D, envolving math modules too. To implement a Vector and the add
and addLocal
methods, we decided to do it like this:
vec.add(3)
adds scalar 3 to the vector and returns a new instance of it, keeping the original untouched (jme: add()
)vec += 3
adds scalar 3 to the vector (jme: addLocal()
)Now if only Java had operators…
Actually, the whole idea for changing this functions was to use Kotlin operators
Why isn’t that possible with addLocal?
in Kotlin you can’t define an operator function, they all already defined well most of them.
like a said plus for + minus for - …
mhh can’t you make those methods as extention methods then?
you mean we add a new plus function and keep add
yeah in a kotlin app
Isn’t that possible?
divAssign is better than divAndAssign and it’s not longer than divideLocal
in a nutshell:
when it will be a redesign for the engine consider this
addLocal-> plusAssign
add->plus
multLocal->timesAssign
mult->times
divideLocal->divAssign
divde->div
subtractLocal->minusAssign
subtract->minus
negate->unaryMinus
if you want to use this functions now in Kotlin
No, never ever ever ever will I condone using “times” as multiply. It’s retarded. It would sound like a first grader wrote the API. I would be embarrassed to show the API to anyone who has ever taken a university math course.
Java already sort of has a convention for these sorts of methods and that would be AndSet in these cases. addAndSet(), subtractAndSet()… I personally don’t care much about method length and I actually type out all of mine. Most of you probably let the IDE finish it for you anyway.
Seriously, using methods like “plus()” have a real disadvantage for exactly the reason you want it… because languages that use operator overloading would automatically pick this up… and you’d have no choice about what it did without overriding it. Might as well just implement it like you want it. For example, the groovy extensions I wrote take Double as arguments because that makes them play nicer in groovy… but is otherwise useless in JME. (Hint: we won’t be changing the engine just to make some other language happier.)
“What does ‘plus’ do?” It adds two numbers together. Oh, “add” then.
“What does ‘times’ do?” It returns the list of times from the profiler… oh, wait, no, it’s doing child math “2 times 2 = 4”
In JME 9001, probably there will be addAndSet(), multAndSet(), divAndSet(), etc… Other language integrations will just have to integrate the way that they always have and wire plus() (and/or whatever specific wiring they require… note that groovy does not use anything as silly as ‘times’ and opts for ‘multiply’ like sane people) the way they’d wire anything else.
But if you come to me and say “I want to name his method farbingar and it adds two numbers together” then I’m always going to say “call it ‘add’ then”. Mathematics already has words for these things and it’s fine if we use them.
In ancient times programmers who suggested to change methods names during work ,were lifted on the rope by balls just to make them feel what most people would feel like if this happens .Fortunatelly we are living in civilized world , but plz plz dont do it . Please i beg you ,just dont .