I am occasionally writing specs for functionality and I’ve noticed that there are - at least - two forms to writing them, using when (btw why when and not where?):
-spec obtain_columns(
AllRows,
FirstRowIsHeaderRow
) -> Result when AllRows :: list(),
FirstRowIsHeaderRow :: boolean() | <<>>,
Result :: {list(), [list()]}.
the second form, which I prefer because there is less repetition:
Isn’t there a way to convert format 1 to format 2 when generating documentation? Or better said, is it possible to add a step into the edoc process that does this conversion?
Format 2 - for me - has unnecessary duplication of parameter names and also when does not fly with me (perhaps my slight autistic nature) - I want to write where not when!
Nominals and opaques must be placed in the .erl file with -export_type. Putting it in .hrl will lead to multiple different and incompatible nominals being defined as the current module name is significant.
Assuming that these types are exported from module 'mod', you can refer to them from other modules using remote type expressions like the following:
mod:my_struct_type()
mod:orddict(atom(), term())
So if I defined a single module - something like -module(project_types) - then I could define all my types there and reference them all over my specs.
Is that something that is done in Erlang projects?
The larger aim - for me - is not to get bogged down in typing when refactoring code, i.e., I want the advantages of “strict typing” but still being able to refactor code easily … if that makes sense.
I really like the fact that the compiler does not enforce types but I see the advantage of knowing that function signatures match usage.
Yes, but usually it shares the name with your app.
So, if you are building an app to… let’s say… …I don’t know… …maybe… play 4-in-a-row…
Let’s say you call your app fiar, for instance. Then you may want to have a facade module called fiar that exposes the app main API, with functions like start, stop, etc… In that case, you would put your types in that module and you would export them (unlinke what those links show )… So you can later use them from the outside as fiar:match() or fiar:user().
Creating module types via a form of “type aliasing”.
Going off-topic: I like what you did with fiar:
For a procedural learning, fiar is divided into small and separate issues, grouped by iterations.
Iteration 1: learn the basic estructure of an erlang application, tests, process as a gen_server, and supervisor with the simple_one_for_one strategy.
Iteracion 2: create the fiar application module, README.md and conecting to MySQL with sumo_db.
Iteration 3: Provide a RESTful API to let users play, adding a basic authentication.
Iteration 4: Add SSE support and create a basic website with standard SSE support to let users play the game using already existing RESTful API.
I’m trying to promote breadboard programming which is kind of the same (iterating over code) but done visually. So that you start with one solution and then copy it and modify it to make it work better and then you repeat that, each time refining the solution but you keep the old versions around. Something like you would do when working with a breadboard.
The whole idea is based on Erlang-Red, hence ered_
I.e. am I over thinking this!
…I don’t know… 
…maybe… 
)… So you can later use them from the outside as 