3 ms·

Traits are not interfaces, or they would be interfaces. They include a concrete implementation (the mixin part).

eternalban 4y ago
Traits are behaviors. But they are not called behaviors as that would be too clear. For example, we know that traits are personal "uniquely identifying characteristics" and that behaviors are general cross-cutting categories, but for this "mixin" we opt to use the personal 'trait'. We also know we're not just describing something but also have "implementation", but hey let's not call it behavior and give the game away! One of the biggest headaches in software (historically) is how things have been named. ("Dynamic programming" says hello). What is a trait? Traits: Composable Units of Behavior, 2002 https://scg.unibe.ch/archive/papers/Scha02bTraits.pdf https://scg.unibe.ch/archive/papers/Scha02bTraits.pdf -- "A trait contains a set of methods that implement the behaviour that it provides. In general, a trait may require a set of methods that parameterize the provided behaviour. "Traits cannot specify any state, and never access state directly. Trait methods can access state indirectly, using required methods that are ultimately satisfied by accessors (getter and setter methods). "The purpose of traits is to decompose classes into reusable building blocks by providing first-class representations for the different aspects of the behaviour of a class."
- Supermancho 4y ago
  > Traits cannot specify any state, and never access state directly That's descriptive of 2002 and is a long time ago, as far as I'm concerned. Traits can modify state with the syntax to modify memory, so this definition is of limited use, imo.
coldtea 4y ago
The trait itself is not the concrete implementation, since a trait can have many different concrete implementations. A trait is, for all, or at least most, intents and purposes, an interface that can have an optional default implementation of some of the functions inside it. Traits, interfaces and types can also, for all, or at least most, intents and purposes, play the same role. Define a contract of stuff implemented by a code entity. Of course any added special semantics depend on the language.

Traits are behaviors. But they are not called behaviors as that would be too clear. For example, we know that traits are personal "uniquely identifying characteristics" and that behaviors are general cross-cutting categories, but for this "mixin" we opt to use the personal 'trait'. We also know we're not just describing something but also have "implementation", but hey let's not call it behavior and give the game away! One of the biggest headaches in software (historically) is how things have been named. ("Dynamic programming" says hello). What is a trait? Traits: Composable Units of Behavior, 2002 https://scg.unibe.ch/archive/papers/Scha02bTraits.pdf https://scg.unibe.ch/archive/papers/Scha02bTraits.pdf -- "A trait contains a set of methods that implement the behaviour that it provides. In general, a trait may require a set of methods that parameterize the provided behaviour. "Traits cannot specify any state, and never access state directly. Trait methods can access state indirectly, using required methods that are ultimately satisfied by accessors (getter and setter methods). "The purpose of traits is to decompose classes into reusable building blocks by providing first-class representations for the different aspects of the behaviour of a class."

Supermancho 4y ago
> Traits cannot specify any state, and never access state directly That's descriptive of 2002 and is a long time ago, as far as I'm concerned. Traits can modify state with the syntax to modify memory, so this definition is of limited use, imo.

coldtea 4y ago

The trait itself is not the concrete implementation, since a trait can have many different concrete implementations. A trait is, for all, or at least most, intents and purposes, an interface that can have an optional default implementation of some of the functions inside it. Traits, interfaces and types can also, for all, or at least most, intents and purposes, play the same role. Define a contract of stuff implemented by a code entity. Of course any added special semantics depend on the language.