Looking at the Scala tour documentation for Trait, I see the sentence traits cannot be instantiated and therefore have no parameters.
Is that really a logical conclusion “therefore” ? Because abstract classes cannot be instantiated either, yet they CAN have parameters. The inability to be instantiated, does not imply inability to have parameters.
What is the real reason traits cannot have parameters? It is an intentional limitation, or is it necessitated by its implementation?
I’m not a Java expert, but as I understand Java interfaces cannot have methods, (maybe I’m wrong), yet traits can have methods. Therefore, it is also the case that the limitations of Java interfaces do not necessarily imply the same limitations in Scala traits.
Not the answer you may be looking for but in Scala 3 (aka Dotty), traits can have parameters. So I suspect that, as you point out, the therefore may not imply a strict logical conclusion.
Java interfaces have methods… That is the whole point of an interface, to define methods; if they couldn’t then interfaces would be useless.
Maybe you meant concrete methods? If so, they can since Java 8 but not before. However, Scala did supported concrete methods on traits before that; but note that, AFAIK, since 2.12 they emit the same byte code as they Java counterpart.
I am not exactly sure why traits do not have parameters, it was indeed an implementation limitation and I would guess not an easy one to fix.
Nevertheless, the Scala team never finish to amaze me, and as @hmf said, Scala 3 will support it; which is amazing!
In C++, a class can extend multiple classes, so a class C could extend classes A and B and then the constructor of C calls the constructor of both A and B, passing parameters to both as applicable.
In Java/JVM, a class can only extend one other class, and only classes have constructors, while interfaces do not, and if there is no constructor, then you cannot pass parameters to it.
In Scala, a trait can contain constructor code. I’m not sure where exactly that code ends up, but once you have the ability to include such code, I can’t think of a fundamental obstacle to also include parameters. Looks like an implementation detail.
Actually, that makes a lot of sense. In Java (as I understand) construction is a special case. I’ve never understood why the Java specification makes initialization a special case with its own special caveats.
I’m much more familiar with CLOS in which a class can inherit from as many other classes as it likes and any and all may have initialization code and initialization arguments. Initialization is done by a specially named method which any class can implement. The rules for calling this method are exactly the same as any other method, it is not a special case.
yes, sorry for using the wrong terminology. I meant to say that interfaces could have declarations but not implementations of methods. I guess the terminology is that an interface “has a method” even if that method has no code body. To me that’s doesn’t really seem like a method, but just a method declaration. But OK, I’ll defer to the experts on this point.