Skip to content

Inconsistency in the type/function signature #98

@smoothprogrammer

Description

@smoothprogrammer

A minor feedback from me in term of the type/function signature, not sure about how big the changes and how breaking it is, but is it possible if we swap the order of msg and state for the actor loop just for sake of consistency?

/// This data structure holds all the values required by the `start_spec`
/// function in order to create an actor.
///
/// If you do not need to configure the initialisation behaviour of your actor
/// consider using the `start` function.
///
pub type Spec(state, msg) {
Spec(
/// The initialisation functionality for the actor. This function is called
/// just after the actor starts but before the channel sender is returned
/// to the parent.
///
/// This function is used to ensure that any required data or state is
/// correct. If this function returns an error it means that the actor has
/// failed to start and an error is returned to the parent.
///
init: fn() -> InitResult(state, msg),
/// How many milliseconds the `init` function has to return before it is
/// considered to have taken too long and failed.
///
init_timeout: Int,
/// This function is called to handle each message that the actor receives.
///
loop: fn(msg, state) -> Next(msg, state),
)
}

Into:

pub type Spec(state, msg) {
  Spec(
    init: fn() -> InitResult(state, msg),
    init_timeout: Int,
    loop: fn(state, msg) -> Next(state, msg),
  )
}

I know the compiler can warn us if the order is wrong, but just like Context in Go that always be the first parameter consistently, it makes the language even more friendly I think.

Lustre also use these order:

https://github.com/lustre-labs/lustre/blob/925f71b6c24a936a2636d6ea247f59b95531b3a9/src/lustre.gleam#L320-L334

pub fn application(
  init: fn(flags) -> #(model, Effect(msg)),
  update: fn(model, msg) -> #(model, Effect(msg)),
  view: fn(model) -> Element(msg),
) -> App(flags, model, msg)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions