There are plenty of other examples I can think of where having the various Love objects be a bit more intelligent.
Of course I could build some Lua wrappers around the objects to do this stuff, but it makes sense from an OO perspective to have the objects do these things natively.
love.graphics.draw("text string", x, y [,someFont])
This would allow folks to define fonts, and use them or not as they see fit. I'd like to see the default text and some default size (12pt?) available without a setup call, and expand the functionality of draw.
The difficulty I see with the OO approach (and it's a minor difficulty, not a huge deal) is that instead of empowering users, it actually throws up another barrier to entry. Overloading the existing text draw function to accept a font as an option input, on the other hand, doesn't impede greenhorn users at all. One function for one action.
That's an interesting option too, Strange. Might be easier to code with the font first.
Apart from the added redundancy, I don't see any major problems with having all options available to fit different styles. After all Lua is all about being flexible, so should Love be any less?
Oh, and I'm so lazy that I end up doing this early on in my code:
Yeah, I do similar things myself. I totally support free-wheeling adjustment of one's personal environment-space.
Today's soapbox, however, is all about making sure that (to the extent possible) love has a clear boundary with standard lua. I think the presence of all those "love.graphics." and "love.mouse." calls in my scripts make it very explicit what work love is doing, and what work is part of the regular lua workhorse. I'm trying to keep my scripts runnable under a variety of environments, so being able to flag and replace the love-specific calls is a blessing.
This has also been discussed, of course, and we chose the "clear boundary" approach. When reading source code, this quickly identifies which calls are in-Lua and which aren't (or quicker, at least). Ideally, every call would be love.something.awesome(), but that isn's always practical or logical.
emonk wrote:Apart from the added redundancy, I don't see any major problems with having all options available to fit different styles. After all Lua is all about being flexible, so should Love be any less?
You mean use both styles for the same functions? If Mike lets that pass, I'm Justin Timberlake.
rude wrote:You mean use both styles for the same functions? If Mike lets that pass, I'm Justin Timberlake.
Am I the Mike you're referring to here? If so, I'm all for flexibility but you ARE aware that this will mean a lot more work for us, yeah? Or will it? </cliffhanger>
Couldn't the functions be extremely simple to implement multiple times?
Just implement one function, and the other functions reference it, possibly they could even be inlined.
Take off every Zigg for great rapist.
Now, outgay that!