Close search
Hoa

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, if 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.

Property access

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 still relevant.

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.

Conversions

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:

PrefixCostConsumes convertee
asFreeNo
toExpensiveNo
intoVariableProbably

Example:

  • Let's $x be a float. asInteger() will be (almost) free.
  • Let's $x be 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).
  • Let's $x be an object. intoArray() will not be that expensive, it might reference all attributes into an array, so that's just one allocation.

Conversions prefixed as and into typically decrease abstraction, either exposing a view into the underlying representation (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 to conversions are likely to be cached because they might be expensive).

Comments

menu