Re: Bug with generic methods?
> 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 they implement, and interfaces can only restrict, what types can state that (say, providing signatures for required procs); not satisfying the interface's restrictions results not in rejecting for the type to be considered as being of that interface, but in a compile-time error. E.g., supposing concepts-syntax for interfaces: type I = interface x p(x) T = distinct int implements I # p(t: T) = discard This should result in a compile-time error, unless the last line is uncommented. And at the same time type I = interface x p(x) T = distinct int proc p(t: T) = discard echo T is I # -> false , because `T` here is not intended to be `I`.
Re: Bug with generic methods?
> 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 r(v: A) = echo "r for A" proc r(v: B) = echo "r for B" var c = 5.C d = 7.D r c # -> r for A r d # -> r for B They do not share it. May be I did not understand you correctly...
Re: Bug with generic methods?
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, let's say, duck-signatured, meaning two interfaces or concepts requiring a routine of the same name and arguments either have to share it or, if return type or attributes are in conflict, cannot be fulfilled for the same type.
Re: Bug with generic methods?
> 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 doesn't even have to now that the concept exists. With inheritance, it is explicit: the creator of a derived type explicitly mentions the base type in the type definition. This implies that he is aware of the semantics that cannot be checked by a compiler. A concept match checks that, e.g., a certain proc is defined for the matched type. The creator of that proc never promised that this proc will actually do what we think it will.
Re: Bug with generic methods?
> this language claims to be rather minimalistic does it?
Re: Bug with generic methods?
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 more elasticity as the same type can implement many vertical concepts/protocols.
Re: Bug with generic methods?
> 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 removing methods from the language, but > I'm not aware what the result was. AFAIK, araq favors making methods single-dispatch (only the first parameter determines the method instance called at runtime). Should make fixing this easier.
Re: Bug with generic methods?
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)?
Re: Bug with generic methods?
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) =
echo "Ignoring a Console..."
method draw*(self: ViewportConsole, engine: string) =
echo "Drawing a ViewportConsole on ", engine, "..."
var consoles: seq[Console] = @[]
consoles.add(new(Console))
consoles.add(new(ViewportConsole))
for console in consoles:
console.draw("blah blah")
I will open a bug report.
Re: Bug with generic methods?
Probably an [object variant](https://nim-lang.org/docs/manual.html#types-object-variants). Or maybe wait until concepts are implemented.
Re: Bug with generic methods?
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_.
