Introduce data conversion naming
Written the .
For 2017, we defined a roadmap composed of Request For Comments (RFC) that are discussed and implemented. One of these RFC is about naming convention and simplification inspired by the Rust coding convention.
So far, we use this formalism:
getFoo to name a method
that returns the value
foo. This can be a direct attribute, or a
computation. To get this data within another form, i.e. to convert this
data into another type, we don't have any formalism yet. For instance,
foo is an array, and we would like to get it as a string,
we will probably name a method like
getFooAsString but this
is not deterministic.
Initially we decided to remove the
get prefix from getter
methods because it's not mandatory to understand the code. Also in many
languages this prefix has been dropped/is not present so we can ask if it's
After receiving some community feedbacks it seems that this prefix is too present in the PHP world. Removing it will make the code harder to understand for most PHP developers.
We don't want to hurt Hoa projects adoption so we prefer
staying with the
get prefix at the moment.
A conversion have a computing cost. Some of them can be expensive, so the method prefix must be clear enough to know operation cost directly by reading the code.
We have decided to introduce 3 methods prefixes:
$xbe a float.
asInteger()will be (almost) free.
$xbe an array.
toString()will be expensive because we have to iterate over the array, to allocate a string, and to convert every pairs in the array as a string (like a serializer).
$xbe an object.
intoArray()will not be that expensive, it might reference all attributes into an array, so that's just one allocation.
decrease abstraction, either exposing a view into the underlying
as) or deconstructing data into its
underlying representation (
into). Conversions prefixed
to, on the other hand, typically stay at the same level of
abstraction, but do some work to change one representation into another.
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
conversions are likely to be cached because they might be expensive).