Discussion: better naming choices for the Attributes API

[khamusa]

On #22, @silvabox raised the fact the term attribute presents a strong semantic overlap with existing technology we use.

In ActiveModel, there is an instance method attributes, which is backed by and returns a Hash (not an Array), and an attribute macro that is used to define an attribute with both a name and a type. That mechanism uses hashes and getter/setter helper methods, whereas here you're using instance variables and attribute readers.

Taken in isolation, defining a completely different attributes API for Tabasco might not be problematic, but when you put together that we're already employing ActiveSupport class_attribute, the similarity (but not) with the ActiveModel Attributes API, Ruby attributes, and possibly also HTML attributes (this is HTML adjacent) - that's five different concepts of attribute all potentially competing within the same space. It certainly confused me.

To me (perhaps because of Rails and Ruby) an attribute is something that's intrinsically part of the thing it's defined against. e.g. a person intrinsically has a name. It doesn't feel to me that a page or section intrinsically has - say - a company or engagement. It might intrinsically have a form or fields or buttons, but an engagement or company seem orthogonal - these are the context in which the page or section is rendered. For want of a better term, they are variables.

I feel we should consider alternatives and rename that API if we can agree on a better term (preferably before releasing our 0.1)

[khamusa]

I'm open to alternatives.

• variables
• arguments
• parameters
• inputs
• dependencies

However, similar arguments could be made against variables and arguments. The same for parameters, yet it seems the best fit: we're talking about the page parameters that even help us define the url params. One caveat, though, is that URL params would be plain strings (or simple scalar values converted to string), while this API supports injecting any kind of dependency to customize the behavior of the page object. So inputs or dependencies do seem appropriate, but they also have their own set of semantic clashes.