Issues

Issue #573 new

Fix callback naming

Bart van Strien
created an issue

We should really find a better way of naming callbacks, just look at the joystick ones, the function names are getting long, and are hard to read. Related, why are they not camelCase?

Ideas are welcome!

Comments (53)

  1. hahawoo

    Non-camelCase names just... feel nicer to me... I like them even though they're inconsistent... and I freakin' love consistency. One logical-esque reason for them being lowercase is that they "look" different from non-callback functions. But maybe I'm just used to them. :D

    I really like how most LÖVE functions aren't abbreviated, their meaning is obvious and you can read them nicely. I think love.joystickpressed would be a much nicer name than love.joyp or something. Also I think the format of callbacks are important for recognising them, so I also don't think something like love.joystick.pressed would be so great.

    There could be a single love.joystick callback which is given an extra argument for whether a button was pressed or released, but I'd suggest that would end up with recreations of the two callbacks using an if-else.

    function love.joystick(joystick, button, pressed)
        if pressed then
            ...
        else
            ...
        end
    end
    

    This is basically what love.focus does however. So, should love.focus be split into love.focusreceived and love.focuslost? (Wow, those names really are a case for camelCase. :P) Edit: Maybe some better names: love.focuson and love.focusoff. I think it depends on whether it would be inevitably be completely divided with an if-else, like input callbacks would be.

    Just to recap from #503, I currently think that love.errhand(msg) and love.releaseerrhand(msg) should be combined into love.error(msg, release) (or love.errorhandler, or something), with "release" being whether the game is in release mode or not.

    I assume that error handilng may have enough similarities in release mode and non-release mode to have the same function with an argument. Perhaps the error messages are the same, perhaps they prepare the error message the same but display it differently, etc.

    I also assume (and I'm not so sure of this), that checking for release mode is something that a lover would almost only want to do in the error callback. If checking for release mode is something which a lover would want to do elsewhere as well, then they would be checking the global variable love._release, and having this as an argument to the error callback would be redundant.

    Speaking of arguments-to-callbacks-made-redundant-by-global-variables, perhaps the command-line arguments givent to love.load are a bit redundant and presumptuous because of the global variable arg? If there is already a global variable, what's the point of the argument, and why for love.load, perhaps I want command-line arguments to change the window dimensions in conf.lua, or to toggle debug info in love.draw. And if I only knew that it was an argument to love.load, I'd probably assume that it wasn't a global variable, and therefore be confused as to how to use it in conf.lua. Is the global variable arg documented by the way?

    INHALE!

    So, in summary:

    • Should love.focus be split into two functions?
    • I'm still thinking love.(release)errhand should be something like love.error(msg, release).
    • Consider removing the arg argument from love.load.
    • I like lowercase callbacks for some reason. :P
  2. Minh Ngo

    I think adding camel cases to the callbacks would be consistent with the rest of the API. Everything else has function names with camel cases! Although keeping the names lowercase would imply that they're callbacks.

    I'm opposed to shortening names and would rather keep as much complete words as possible. I like that the devs changed the event names to full words as well. Function name shortening should be left to the individual like the popular lg = love.graphics.

    With regards to love.errhand and love.releaseerrhand, I agree that they should be combined into one function like love.errorhandler(msg,release) with release as a boolean.

    With regards to all the joystick callbacks added (love.joystickaxismoved, love.joystickballmoved, and love.joystickhatmoved), I think they should all be combined into love.joystickinputted(joystick,type,...). The ... are additional parameters according to the type string (button,hat,axis,ball).

  3. Alex Szpakowski

    Perhaps event callbacks could have an "on" prefix, and reside in their respective modules, e.g. love.joystick.onPress, love.graphics.onFocus, etc. (past-tense works as well).

    I'm not sure how love.load/love.update/love.draw would fit into that new scheme though, and it still has potential for some awkward names (love.joystick.onAxis? love.joystick.onAxisMoved?)

    It might also present a problem if the modules aren't loaded when the callback functions are declared (confusing errors! yay!)

  4. Robin Wellner

    I disagree on the love.errorhandler(msg, release), because errhand and releaseerrhand have radically different purposes, even though they are called in similar situations:

    errhand has the purpose of delivering debugging information as fast as possible to either the lover who made the game or a playtester (who is often a lover as well).

    releaseerrhand has the purpose to explain something (not what) went wrong, and who to contact so it'll get fixed. They might see some debug information as well, but they're not expected to understand it or do anything with it except pass it on to the lover who made the game.

  5. Alex Szpakowski

    In practice, the two end up being pretty much identical in most cases. It usually makes much more sense for game creators to have the error message and traceback displayed to end users than to omit them.

  6. Landon Manning

    After discussing this with Alex on IRC, I think we both agree on the following convention:

    -- Run cycle, not "events" per se
    love.load
    love.draw
    love.update
    
    -- System events    
    love.onFocus
    love.onJoystickPressed
    love.onJoystickReleased
    love.onKeyPressed
    love.onKeyReleased
    love.onMousePressed
    love.onMouseReleased
    love.onQuit
    
  7. Alex Szpakowski

    Yeah, although I think whatever happens, the callbacks should have consistent tenses. If we have love.onFocus then we should have love.onJoystickPress rather than love.onJoystickPressed.

  8. hahawoo

    love.onFocus wouldn't really be on focus though... it would be more like "on change of focus", right? love.onFocusRecieved and love.onFocusLost could resolve this.

    Would the event names also change to have the "on" prefix?

    What about love.joystickaxis etc.? love.onJoystickAxisMoved I guess? In this case, it isn't really necessarily a more readable name though.

    Regarding combining the error callbacks, even though they have different purposes, do they have that much different code in them? A lot of the default error handlers seem to be copy and pasted from one to the other.

    But, I'm not sure if release mode is actually an elegant way to change the error message and save directory (#579).

  9. hahawoo

    Here's what I'm thinking currently:

    • Callbacks should be easily distinguishable from other functions. Simply not having them in modules achieves this.

    • I don't think it's necessary to differentiate the system events from the run cycle events by name. I'm not such a fan of the "on" prefix.

    • Having camelCase and present tense is pretty cool. It's consistent, after all.

    • I don't think there is another name which makes as much sense for the error function as love.error. After all, you can say "The love.x callback handles the "x" event" meaningfully for everything else.

    What do people think of these?

    love.load
    love.draw
    love.update
    love.quit
    love.error
    love.windowFocus
    love.windowBlur
    love.windowMouseOn
    love.windowMouseOff
    love.windowResize
    love.joystickPress
    love.joystickRelease
    love.joystickHat
    love.joystickAxis
    love.keyPress
    love.keyRelease
    love.mousePress
    love.mouseRelease
    
  10. Minh Ngo

    Thinking about it again, the current naming convention is fine as it makes functions stand out as overridable. I'd be pretty OK with adding present tense, but adding "on" would make it superfluous

  11. rude repo owner

    A tense-consistent version of karai17's is a pretty good suggestion. However, what looks more correct than anything else is something like what slime (sometimes incorrectly referred to as "Alex") suggested:

    -- Non-events. Thus no "on" prefix. We are not
    -- notifying the game about something which happened,
    -- we are demanding that something takes place.
    love.load
    love.draw
    love.update
    
    -- Events
    love.window.onFocusReceived
    love.joystick.onJoystickPressed
    love.joystick.onJoystickReleased
    
    -- "Key" and "Button" could potentially be dropped.
    love.keyboard.onKeyPressed
    love.keyboard.onKeyReleased
    love.mouse.onButtonPressed
    love.mouse.onButtonReleased
    
    love.window.onClosed -- Alternative to onQuit?
    

    As you can see I would argue for a past tense version, because in most cases at least, the thing which we are describing has already happened.

    The only "problem" is that this would establish a new pattern of operation (POO) in LÖVE: the events originate from love.event, but are forwarded to special user-defined functions residing in the tables of other modules, presumably by love.run. I think this is OK. It's certainly not that much worse than forwarding to love.whatevereventtookplace.

  12. hahawoo

    Is the quit event dependent on the window module? If not, perhaps it shouldn't be in that module, lest someone want to do something on exit but not load the window module.

    Also, I'm wondering where the error callback would go? Edit: And what would it be called? I guess onErrored would be consistent, although it's not so pleasant grammatically.

  13. Landon Manning

    rude the only problem with the way you have set up, and I think slime mentioned this at some point, is if you write code for all modules (keyboard, joystick, etc) but dynamically load them, then your code will crash (wtf is love.joystick? BSOL) unless love.joystick is loaded. This disallows slimming of unneeded modules, or pre-writing code.

    On the other hand, if we leave them all as events, then we can code them up and dynamically use them when needed.

  14. Alex Szpakowski

    There might be some xtreme metatable fudgery that could be done to make it not error if a callback function is written for a module that isn't loaded, but... I don't think I want that kind of really hackish behaviour. :p

  15. Landon Manning

    Well, if these are all events, why not just leave them in love.event and maybe add an alias to them from the other modules for semantic purposes?

    love.joystick.onPressed = love.event.onButtonPressed

  16. hahawoo

    I'm unsure about the benefit of having callbacks in modules. I guess there's "disabling a module also disables the callback", but, like, I don't think anyone will disable the joystick module and then wonder why joystick callbacks aren't being called. :P

    It's more verbose, which makes it harder and take more time to read, contrast love.keyboard.onKeyPressed with love.keyPressed.

    I also think it makes the distinction between callbacks and functions-that-you-call less visually and conceptually clear.

    Currently it's "Functions which start with love. are callbacks and functions which start with love.module. are functions you call".

    If the callbacks were in modules, it would be "Functions which start with "on" are callbacks, as well as love.run which also calls love.load and love.update and love.draw, and functions in modules not starting with "on" are functions you call".

  17. rude repo owner

    Yeah, I'm not sure I like the in-module callbacks myself when I actually have to use them in code.

    function love.keyboard.onKeyPressed(key)
        -- Stuff.
    end
    

    Meh.

    If not in the modules, then I also suggest this:

    -- Present tense, because these (non-)events are taking
    -- place *now*.
    
    love.load
    love.draw
    love.update
    love.quit
    love.err
    
    -- Past tense, because these events already happened.
    
    love.keyPressed
    love.keyReleased
    love.mousePressed
    love.mouseReleased
    love.windowFocused
    love.windowBlurred
    love.windowResized
    love.joystickPressed
    love.joystickReleased
    love.joystickAxisMoved
    love.joystickHatWTFed -- Because WTF is a joystick hat.
    -- etc
    

    So in general love.nounVerbed for events which already happened.

    I actually wanted an "on" prefix on the callbacks:

    love.onKeyPressed
    love.onKeyReleased
    -- etc
    

    But then it would also "require" a prefix for load, update and draw, for consistency:

    function love.onLoad()
    end
    
    function love.onUpdate()
    end
    
    function love.onDraw()
    end
    

    And that is clearly much uglier than the "trademark":

    function love.load()
    end
    
    function love.update()
    end
    
    function love.draw()
    end
    
  18. Landon Manning

    Differentiating between events and non events could allow for some leeway in naming, no? Since load/update/draw aren't events, they are things that just happen, it could be read "this is happening, do it now", but with events, "on" is appropriate because it can be read "WHEN this happens, do this".

  19. Bart van Strien reporter

    Hmm, but 'onPoop' also kind of maybe suggests it registers something to happen when a poop occurs, not that it is the thing called when that happens. Like: love, on Poop, do this. Yet it's not a command, it's something you create, which is.. weird.

  20. rude repo owner

    karai17: I thought so at first too, but then I discovered that it's perfectly logical to prefix "on" for load, update, draw, error and quit (LUDEQ) too. The fact that they are taking place now does not really free them from having a prefix if the other callbacks have it, it only allows us to use the present tense on those names, so we would not need onUpdated, but we would need onUpdate, in my opinion.

    At least to me onUpdate looks perfectly correct (in principle), and suggests that something else should happen while an update is happening.

    But I don't like how onLUDEQ looks in the code, and I don't think anyone else does either.

  21. Landon Manning

    Yeah I'm honestly just trying to rationalize it away since onLUDEQ is ugly (though technically correct). I'm not really sure what the best course of action is at this point but I think we all agree that onLUDEQ is a no-go, on onEvent is still desirable as an outcome of this discussion.

  22. hahawoo

    I think love.verb* for LUDTEQ** and love.nounVerbed for all else might be quite nice.

    However, are error and quit actually happening now, or have they already happened and now they're being handled?

    * "error" is totally a verb now.

    ** Including "threadError".

    love.load
    love.update
    love.draw
    love.error
    love.threadError
    love.quit
    love.gamepadAxisMoved
    love.gamepadPressed
    love.gamepadReleased
    love.joystickAxisMoved
    love.joystickHatMoved
    love.joystickPressed
    love.joystickReleased
    love.joystickAdded
    love.joystickRemoved
    love.keyPressed
    love.keyReleased
    love.mousePressed
    love.mouseReleased
    love.textEdited
    love.textInputted
    love.windowFocusGained
    love.windowFocusLost
    love.windowMouseFocusGained
    love.windowMouseFocusLost
    love.windowResized
    love.windowVisibilityGained
    love.windowVisibilityLost
    

    (love.windowVisibilityGained is exactly the same length as love.windowDidBecomeVisible. :D)

    And here are some names which make no sense. Which I kind of like.

    love.load
    love.update
    love.draw
    love.error
    love.threadError
    love.quit
    love.gamepadAxis
    love.gamepadDown
    love.gamepadUp
    love.joystickAxis
    love.joystickHat
    love.joystickDown
    love.joystickUp
    love.joystickAdded
    love.joystickRemoved
    love.keyDown
    love.keyUp
    love.mouseDown
    love.mouseUp
    love.textEdit
    love.textInput
    love.focus
    love.unfocus
    love.mouseOver
    love.mouseOff
    love.resize
    love.visible
    love.invisible
    
  23. rude repo owner

    love.textEdited seems OK, but love.textInputted sounds quite bad to me.

    "Inputted" and "input" are both valid past tense forms, so perhaps we should use love.textInput instead.

  24. Alex Szpakowski

    However, are error and quit actually happening now, or have they already happened and now they're being handled?

    quit is triggered after the game has been requested to quit (either via love.event.quit() or the user pressing the close button on the window.) error is triggered after an error occurs.

  25. hahawoo

    How about this?

    love.[ time to ]load
    love.[ time to ]update
    love.[ time to ]draw
    
    love.[ program has ]errored
    love.thread[ has ]Errored
    love.[ program was ]quit
    
    love.gamepadAxis[ was ]Moved
    love.gamepadButton[ was ]Pressed
    love.gamepadButton[ was ]Released
    love.joystickAxis[ was ]Moved
    love.joystickHat[ was ]Moved
    love.joystickButton[ was ]Pressed
    love.joystickButton[ was ]Released
    love.joystick[ was ]Added
    love.joystick[ was ]Removed
    love.key[ was ]Pressed
    love.key[ was ]Released
    love.mouse[ was ]Pressed
    love.mouse[ was ]Released
    love.text[ was ]Edited
    love.text[ was ]Input
    love.windowFocus[ was ]Gained
    love.windowFocus[ was ]Lost
    love.windowMouseFocus[ was ]Gained
    love.windowMouseFocus[ was ]Lost
    love.window[ was ]Resized
    love.windowVisibility[ was ]Gained
    love.windowVisibility[ was ]Lost
    

    The Button in joystickButtonPressed etc. might not be necessary... does joystickPressed make sense? Does mousePressed make sense?

    Also these names assume that "mouse focus" is a thing, via hasMouseFocus.

  26. rmcode

    In my humble opinion it is more important to choose meaningful names, rather than forcing some convention on them.

    Therefore my suggestion looks like this (if I had to choose, I'd go for camel casing btw.):

    -- Do something 'on' occurence of the callback
    -- load, draw and update would also work nice w/o the 'on' prefix
    onLoad
    onDraw
    onUpdate
    
    onErr
    onQuit
    onResize
    
    -- Apply the same pattern to joystick callbacks
    onKeyPressed
    onKeyReleased
    onMousePressed
    onMouseReleased
    
    -- Ask löve if it 'has focus' or 'is visible'
    hasMouseFocus
    hasFocus
    isVisible
    
    -- 'get' user's textinput
    getInput
    

    That's what would make the most sense to me.

  27. rmcode

    I know that they aren't questions, it's just how I read them when going over my code - but I see how that may be strange to other people.

    If I had to vote, I'd go for hahawoo's suggestion then.

  28. Aesthete

    I would have to say I find using on before actions to be most natural. The tense can really depend on what you're describing, and as rmcode mentioned, it's more important to choose meaningful names. The ultimate goal is to be as explicit as possible for the end user.

    I agree with on the format Landon and Alex spoke about previously:

    love.onFocus
    love.onJoystickPressed
    love.onJoystickReleased
    love.onKeyPressed
    love.onKeyReleased
    love.onMousePressed
    love.onMouseReleased
    love.onQuit
    

    With the following suggestions:

    • onFocus should be either onFocusGained or onFocusLost.
    • onQuit could possibly be onQuitRequested assuming the game hasn't quit yet, and the application is still running.

    Another thing that irks me about keypress formats is anything with pressed in it. There is always confusion between implementations on what this actually means. It can be interpreted as meaning "The key went down and it then went up", or of course it can just mean "the key is down". In past experience I have found the following to be more expressive of the actual action:

    -- A key went down
    onKeyDown
    -- A key went up.
    onKeyUp
    

    If a user wants to go ahead and write an onKeyPressed function that manages various key states, so be it.

  29. Landon Manning

    love.focus is a change in focus, not a specific focus. It passes in a bool to determine if focus is gained or lost.

    function love.focus(f)
        if f then
            print("Focus gained!")
        else
            print("Focus lost!")
        end
    end
    
  30. Aesthete

    Right, well then onFocusChanged, or something similar makes more sense to me, making it explicit about when it's being called. focus sounds like I should be calling it.

    Either that or just make two functions for focus gained and lost.

  31. Anonymous

    im all for camelCase. think because it will make it easier, in the long run. ive only just started with LOVE, but things like the keypressed etc can be a bit confusing.

    completely agree with the landon and alexs

    love.onFocus
    love.onJoystickPressed
    love.onJoystickReleased
    love.onKeyPressed
    love.onKeyReleased
    love.onMousePressed
    love.onMouseReleased
    love.onQuit
    

    that to me is what it should be.

    anyhow, just wanted to share what i feel would be better from a guy just coming to the language. it does make it easier to read as well

  32. OttoRobba

    prepositionCallback

    I believe this is a bad idea for a couple of reasons:

    1 - In some cases, it is nonsensical. Like Landon points out, the focus callback is not used on focus, but rather to function depending on where focus is.

    2 - If pretty much every callback ends up using "on", then is it really needed? It just becomes a bit of noise. Reminds me of the Python talk about the evolution of the language and how 'xrange' is that much uglier than 'range' simply because of one character.


    is, has, get

    Using 'is', 'has' and 'get' for callback is another issue:

    1 - I would say it is bad practice to have a love.isVisible callback for the simple fact that the expect return would be a boolean (either it is or it isn't). Same problem with 'has'.

    if isVisible() then doSomething() end --read this out loud
    
    function love.isVisible(w) --now try reading this
      if w then doSomething() end
    end
    

    2 - Using 'get' means you are merely expecting it to return something and makes no sense in a callback. image:getWidth makes sense, love.windowGetVisibility doesn't.

    w = image:getWidth --this looks fine
    function love.windowGetVisibility()
        --I don't even...
    end
    

    I honestly believe that code convention is extremely important (when sensible) because it decreases the learning curve. So creating a rule like love.verb and love.nounVerb using past tense is very sane. Basically, what hahawoo and rude suggested.

    For reference on a very clean API, there is always Processing - which, again, is pretty much what hahawoo suggested.

  33. Aesthete

    The purpose of having on isn't to differentiate the callbacks from one another, it's to differentiate them from other functions.

    It's to make it obvious that onFocusChanged is a callback, whereas focus would appear to be called to invoke some sort of focus functionality. I can immediately tell what's going to be called for me, and what I need to call.

    Using is, has, or get before the callback name is a terrible idea, for the reasons mentioned.above, and I totally agree with that.

  34. Landon Manning

    My latest proposition:

    love.load
    love.update
    love.draw
    love.quit
    
    love.onError
    love.onThreadError
    
    love.onGamepadAxisMoved
    love.onGamepadButtonDown
    love.onGamepadButtonUp
    
    love.onJoystickAxisMoved
    love.onJoystickHatMoved
    love.onJoystickButtonDown
    love.onJoystickButtonUp
    love.onJoystickAdded
    love.onJoystickRemoved
    
    love.onKeyDown
    love.onKeyUp
    
    love.onMouseDown
    love.onMouseUp
    
    love.onTextEdited
    love.onTextInput
    
    love.onWindowFocusGained
    love.onWindowFocusLost
    love.onWindowMouseFocusGained
    love.onWindowMouseFocusLost
    love.onWindowResized
    love.onWindowVisibilityGained
    love.onWindowVisibilityLost
    
  35. OttoRobba

    Aesthete True, focus vs onFocusChange makes sense.

    Landon Manning Seems pretty good for the most part.

    This seems rather verbose and a bit hard to read:

    love.onWindowFocusGained
    love.onWindowFocusLost
    love.onWindowMouseFocusGained
    love.onWindowMouseFocusLost
    love.onWindowResized
    love.onWindowVisibilityGained
    love.onWindowVisibilityLost
    

    How about:

    love.onFocusChanged
    love.onMouseFocusChanged
    love.onWindowResized
    love.onVisibilityChanged
    
  36. hahawoo

    Just reiterating here, but in regards to focus, mouse focus and visibility changes being 1 function or 2, having them as 1 function leads to this:

    love.change(b)
        if b then
            ...
        else
            ...
        end
    end
    

    rather than this:

    love.on()
        ...
    end
    
    love.off()
        ...
    end
    

    and I'd say the latter is nicer (especially, perhaps, if only one of the on/off functions is needed).

    In regards to differentiating callbacks from other functions, I'd say they're already differentiated enough by being love.function instead of love.module.function, and I'd assume they wouldn't often be confused in practice.

    But love.getVersion exists so I can't really say that. ;)

    And since I think they're already differentiated, I'd say the "on" prefix is a bit noisy.

    And as Rude mentioned, the onLUDEQ names are consistent with the onEverythingElse names, e.g. if there is onKeyPressed, it's consistent to have onUpdate.

  37. Alex Szpakowski

    And as Rude mentioned, the onLUDEQ names are consistent with the onEverythingElse names, e.g. if there is onKeyPressed, it's consistent to have onUpdate.

    love.update, love.draw, and love.load are different from the rest because they are more "this draws things" than "this gets called when things are drawn" (/ updated / loaded).

    love.quit is triggered when the user wants the game to quit though, so it might be better named love.onQuitRequested or similar, although that's a bit wordy.

  38. hahawoo

    They are indeed different in that way, but this is how I'm thinking about it:

    I thought so at first too, but then I discovered that it's perfectly logical to prefix "on" for load, update, draw, error and quit (LUDEQ) too. The fact that they are taking place now does not really free them from having a prefix if the other callbacks have it, it only allows us to use the present tense on those names, so we would not need onUpdated, but we would need onUpdate, in my opinion.

    At least to me onUpdate looks perfectly correct (in principle), and suggests that something else should happen while an update is happening.

    But I don't like how onLUDEQ looks in the code, and I don't think anyone else does either.

  39. OttoRobba

    I think part of the problem and the noise is that we are looking at the names as one big list. So, for the sake of comparison:

    love.onQuitRequested = function()
    end
    
    love.onError = function()
    end
    
    love.onThreadError = function()
    end
    
    love.onKeyPressed = function(key)
    end
    
    love.onKeyReleased = function(key)
    end
    
    love.onFocusGained  = function()
     unpauseGame()
    end
    
    love.onFocusLost  = function()
      pauseGame()
    end
    
    love.quitRequested = function()
    end
    
    love.error = function()
    end
    
    love.threadError = function()
    end
    
    love.keyPressed = function(key)
    end
    
    love.keyReleased = function(key)
    end
    
    love.focusGained  = function()
     unpauseGame()
    end
    
    love.focusLost  = function()
      pauseGame()
    end
    

    I honestly don't know anymore - 'on' makes sense but it just seems uglier.

  40. Pablo Mayobre

    I hate writing the same thing many times... writing "on" in every single callback would be a pain.

    Except for the Joystick callbacks I like the rest of them just as they are, they are easily understood. Keypressed is really easier to read and understand that onKeyPressed. I think of callbacks like "When a key has been pressed do this" so onKeyPressed doesn't fit in there.

    Just my thoughts

  41. hryx

    I like the onX naming since it makes it easy to identify a function as a callback.

    Additionally, the camel case makes it obvious they are functions. I used to have a hard time telling if e.g. love.keyboard was a callback or a main LÖVE module.

    I hate writing the same thing many times... writing "on" in every single callback would be a pain.

    Most functions are already verb-prefixed to make them clear: newFont(), getDimensions(), setLineWidth(), and so on. Arguably, people will be writing on far less than any of these -- callbacks are only defined once.

    love.update, love.draw, and love.load are different from the rest because they are more "this draws things" than "this gets called when things are drawn" (/ updated / loaded).

    Maybe, but does the user need to know that?

    Finally note regarding ugliness: I'm fond of tiny, all-lowercase naming, but LÖVE is leaning toward consistency, hence my above comments.

  42. Log in to comment