interfaced

interfaced copied to clipboard

See here: https://github.com/nim-lang/Nim/issues/7497#issuecomment-378652626

@andreaferretti whay are there ref types? I made sure that you don't need ref types for the interfaces.

Aparently the inteface libary has been spoiled with ref types, I would like to point you to the original version that I wrote in the forum that does not need any ref types at all: https://forum.nim-lang.org/t/2422

I desigend the interfaces carefully, so that they can be used without any GC active. I am very careful about this, I don't want any ref types in my rendering thread.

ah, I didn't thought that way. The original thread was about Go like interfaces and that's why I edited the wrapper so that it works the same way they do in Go or Java. There it's quite common to pass an interface object upwards on the stack, to save it somewhere(maybe in a registry of some sort), without keeping a reference to the original object around.

Also nobody ever said that they are unsafe, so I thought it would be better to make the interface safe. Of course, if there's a way to ensure that the interface doesn't outlive the scope of the object it's originating from, then this would be the better way to make it safe.

Well I don't think that that Nim offers anything to ensure that Interface objects will never outlive the object it is originating from. I think creating interface objects in local scope is safe, as well as passing them down to functions. But assigning Interfacing to anything outside the function or returning them is not safe at all.

@krux02 I have to admit I was not too familiar with your original design, so I accepted @RSDuck changes without much thought. After this small discussion, the trade-offs are much more clear.

Now, in general I don't think that interfaces that cannot outlive the scope they are created are very useful. Generally, when I feel the need to use interfaces, it is because I want to be able to store different possible implementations of something inside some kind of context. This is useful to make interfaces composable, which is kind of the point for me.

If something does not outlive the scope it's created in, it is much more convenient for me to use concepts instead, at least if the type is statically known. But when something outlives the scope it's created in, the only way to avoid interfaces is to use generics, which then infect everything.

For a typical example, say I have a Logger interface with various implementations. I may have a Server object which needs a logger. If I use static dispatch, I end up with a Logger concept and a Server[L: Logger]. This approach does not scale when the things whose implementations may vary are a lot. In this case, I'd rather go for a Logger interface and a monomorphic Server.

Since this is my typical use case, interfaces that are limited to a static scope are not that useful to me.

On the other hand, I like that your original approach allowed to avoid references at least for certain uses. Can you tell more about some example of use case where interfaces are useful in this more limited setting? Do you think there may be a way to combine the two approaches?

Well to be honest I haven't used this kind of interfaces outside of Go, and in go they also need to substitute generics, otherwise I would have noticed this change earlier. I just thought interfaces like I knew them from Go are not provided in Nim, so I thought that could be a nice way to learn macro programming. Your points are valid, when something doesn't outlive the local scope then generics already solve the problem. The only advantage of this interface type here would be less code generation, and therefore a smaller binary.

let's talk about your Logger use case. Can I imagine you have a logger that is basically a global variable that can be changed at any time to change the effect of logging?