SpriteBatch:setg are abbreviated, and not-so-obvious, and generally don't seem to fit with the names of other things.
They're concise though, which could be a good reason for leaving them as they are.
They could be renamed to
SpriteBatch:setGeometry. I didn't like this naming at first because it's more verbose, but now I think it's worth it. It's more descriptive, pronounceable and nicer to read. If it were named
drawGeometry in the first place, I think it would be hard to argue that it should be renamed
drawg. It would be like saying "hey, I think
setColor should be renamed to
setc, it's so concise!"
I thought of
drawGeom briefly, but this doesn't have the niceness of
drawGeometry or the conciseness of
drawg. (That kind of rhymed!)
love.graphics.geometry was another thought. After all,
love.graphics.rectangle isn't called
love.graphics.drawRectangle. It was pointed out in a previous issue that
drawq shouldn't be named too differently because they're in the same "family", which makes sense, but they're not exactly related in that besides using a Geometry,
drawg can only draw a subset of what
draw can, and being named similarly to
draw isn't really a convention to be upheld because
drawg is the only other member of the family.
On a different but related topic, what if
SpriteBatch:set could optionally accept a Geometry, basically combining
setg? I don't know what people think about overloading functions like this, but it seems kind of reasonable, maybe?
And what if
draw was combined with
drawg? This might be confusing though because
drawg can only draw Drawgables.