Simplify getter naming, introduce data conversion naming #54
Hello fellow @hoaproject/hoackers and users!
In this RFC, I would like to simplify and standardize the API to get data.
So far, we use this formalism:
Shorten getter methods
First proposal is to remove the
The meaning is strictly the same, but I think the former is easier and shorter to read.
I would like to introduce 3 method prefixes:
This is not something we will use often, but it is important to have a strict naming here. Based on this naming, the user will be able to choose if the resulting data must be cached or not (for instance, all
The text was updated successfully, but these errors were encountered:
Okay, but why exactly? What's wrong with the current approach? I think it's more consistent, predictable, and fits in well with the setter naming.
How does this work with multi dimensional arrays? Would this conversion be predictable / clear / standardized? The method name does not accurately convey the nature of the conversion - I wouldn't be sure what to expect in the final string.
@Swader Why removing the
is strictly equivalent to:
The former is more readable from my point of view. The API is unified more importantly.
What's wrong: It's heavy, and not necessary. The
Now, about the
The goal is to define a naming convention to indicate the cost of conversions, and the abstraction changes. I think this is useful.
Helping developers knowing the cost of an operation by convention naming is a very nice idea
Also the collaboration with RFC #56 and getter naming simplification make the code simpler to read for me.
But what about existing code ? Once implemented this will introduce a BC break for most of the getter methods... Do you think the code must be compatible for some time ?
Since we choose to don't remove the