On 04/11/2017 6:13 PM, bauss wrote:
On Saturday, 4 November 2017 at 13:27:29 UTC, rikki cattermole wrote:
On 04/11/2017 2:14 PM, jmh530 wrote:
[...]
Okay so:
A signature when it is initiated is aware of the implementation it is
referencing. Allowing it to change how it behaves for compatibility
reasons.
An interface is designed so that a class/interface must know of the
interface to inherit from.
While signatures can and probably will inherit from others, this is
not how it is used unlike with interfaces. Because this is a massive
change in how we view them and their usage, extending interfaces is
not appropriate. Luckily an already existing concept exists in the
literature which does solve most of the goals and that is signatures
from the ML family.
I will make a mental note to rewrite that section.
It reminds a lot of traits in Rust.
https://doc.rust-lang.org/1.8.0/book/traits.html
Rust traits are a variant of ML's signature. Only they decided to add a
whole new concept which is 'impl' to it.
While it is a nice idea, it would be a pain to use in real life and
defeat the purpose of a signature. Which is to act as more of a
'concept' abstraction to other items.
Because we have such powerful meta-programming features I see no reason
to separate out the two. We can do it all in one which makes it nice and
consistent between all the different implementations for a signature
type. So far its starting to feel right at home against our structs and
class support, I think.
