The naming of drawg, addg and setg

Issue #639 resolved
created an issue, SpriteBatch:addg and 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:addGeometry and 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 drawGeo or drawGeom briefly, but this doesn't have the niceness of drawGeometry or the conciseness of drawg. (That kind of rhymed!) was another thought. After all, isn't called It was pointed out in a previous issue that draw and 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:add and SpriteBatch:set could optionally accept a Geometry, basically combining add with addg, and set with 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.

Comments (2)

  1. Anders Ruud repo owner

    I agree. seems very strange to me now. I think it's probably OK to merge into one? I think I prefer that slightly over

  2. Log in to comment