> Please note the biggest problem of inheritance-based interfaces: you cannot
> add one to a type already in existence when you define the interface
Certainly you cannot; that is the point - not interfaces state, what types
satisfy (implement) them, but the other way round, types state, what
> two interfaces or concepts requiring a routine of the same name and arguments
> either have to share it
type
A = concept x
p x
B = concept x
q x
C = distinct int
D = distinct int
proc p(v: C) = discard
proc q(v: D) = discard
proc
Well, for me the BEST "interfaces" would be explicit, namespaced concepts,
actually (hello, Rust!). Please note the biggest problem of inheritance-based
interfaces: you cannot add one to a type already in existence when you define
the interface. Also, both interfaces and Nim's concepts are,
> These are two models, inheritance and type classes, which are different
> answers to the same problem. I can see no good reason to provide both in the
> same language..
I see one difference: with concepts the type match is an implicit one, the
person creating the matching concrete type
> this language claims to be rather minimalistic
does it?
It seems to me that concepts' vtables make methods obsolete. These are two
models, inheritance and type classes, which are different answers to the same
problem. I can see no good reason to provide both in the same language if this
language claims to be rather minimalistic. Also, vtables give
> At least Nim would have to instantiate all methods that could be called at
> runtime.
I see. Calculating the minimal set of necessary method instances at compile
time looks hard-to-impossible to me though, at least with multiple-dispatch
methods.
> I think there were suggestions about
Thx for your answers guys.
@def: Does that mean that in order to make methods work with generics, Nim
would have to be able to instantiate methods for generic parameters after
dynamic dispatch (at runtime)?
That's obviously supposed to work and it's a bug when using methods in
combination with generics. Without generics it works fine:
type
Console* = ref object of RootObj
ViewportConsole* = ref object of Console
method draw*(self: Console, engine: string) =
Probably an [object
variant](https://nim-lang.org/docs/manual.html#types-object-variants). Or maybe
wait until concepts are implemented.
That's because of the sequence. If you would store the objects in two separate
sequences for _Console_ and _ViewportConsole_ instead, you would get the
expected result. Apparently, _var consoles: seq[Console]_ sets the runtime type
of the elements to **exactly** _Console_.
types, but it seems to be only calling the base one. It only calls the
ViewportConsole implementation if I explicitly cast **console**.
Is that a bug with generic methods, or am I doing this the wrong way? I was
storing a reference to an **Engine** in the **Console** itself before, but
**Engine
12 matches
Mail list logo
