Use LÖVE's love.math.random when available

[slime73]

love.math.random should always be preferred instead of math.random when LÖVE is used.

[jaythomas]

Just a question in ignorance as I don't know the difference between the functions, but what's the reason to use love's math function as an override? Additionally, shouldn't that be an override you set outside of the lume library rather than expecting lume itself to be aware of another library being present?

[EntranceJew]

@jaythomas love.math.random and love in its entirety is meant to be cross-platform, whereas lua's math.random can vary by platform. This can complicate situations where two games are sharing a random seed and generating information or making decisions side-by-side. @slime73 knows better than me, though.

[jaythomas]

Thanks, @EntranceJew. That answers my first question.

The reason I asked the second question is because my concern is that by making it the library's responsibility to have an awareness of love's random function, you are introducing a bias towards using this library in conjunction with love. As a user of this library, I may be using lume inside a service where love is not defined globally, or perhaps I'm not using love at all. Personally, I think it makes more sense to implement a "mixin" function where you can register new functions or override existing top-level functions like math_random. Psuedo code:

  lume.mixin('math_random', love.math.random)

This way if I wanted to use a completely different random function, or if love decided to move the random function somewhere else, the library wouldn't care. Not its job to be responsible for other librarys' APIs.

Again, just my opinion.

[rxi]

Agreeing with several for @jaythomas's points, mainly:

... my concern is that by making it the library's responsibility to have an awareness of love's random function, you are introducing a bias towards using this library in conjunction with love.

So I won't be including this, nor merging the corresponding pull request (#13).

That being said, I do like the idea of supporting a mechanism for the user to supply their own random() function. I'm aware of the short comings of Lua's math.random(), on Windows, for example, last time I checked its implementation of rand() would return a 15bit integer which is at best not ideal.

I'll have to think about the best way to go about this (in terms of naming, and exactly how the provided random() function is expected to act) before adding it in.