Hi folks, moderator here. I’m calling it for this discussion. No further discussion is called for, IMO, although I’m sure Brett and I would be happy to be overridden by private request.
Stephen, thank for providing an excellent summary post on which to lay this thread to rest :) :)
On Feb 15, 2020, at 7:57 AM, Stephen J. Turnbull firstname.lastname@example.org wrote:
All: If you're not interested in the back and forth, read my parallel post with a different subject.
Soni L. writes:
I'm just gonna say learn rust since you actively refuse to accept my explanation of rust traits. don't reply again until you've learned rust.
you don't want me to be rude
I don't actually care (cf. http://www.jwz.org/gruntle/rbarip.html), except that we've all agreed to the Code of Conduct, and I hate to see folks ignored, or worse, banned, for non-conformance.
but when I literally explain rust traits
So far, from what you've written, they seemed to be what in Python I would call "zope.interface interfaces." And in fact, both you and the 3 Rust-specific sources cited below emphasize this aspect of traits. Sadly, you did a very poor job of explaining what Rust traits are, and their advantages over strait. Possibly because there aren't any advantages that aren't strait implementation details. At least, I can't find any.
you throw me an "that's not traits"
No, I'm throwing you an "I don't understand what you want." I was not going to say "they're not traits" until I understood them. I told you what I understood them to be *from your descriptions*, which turned out to be incomplete in rather important ways.
Now that I understand them better, they do seem to be traits à la Schärli et al., except that arbitrarily nested traits are allowed in Rust, and Rust allows unimplemented methods. (This is not a restriction in Schärli et al's version of traits: the implementation of a trait method can simply call a method provided by the class incorporating the trait.)
In the TOSWidget example, as I understand it, in Rust:
- In the trivial case where exactly one of TOSWidget, Pack, and Place implements 'config', you get that implementation, and any code that's not happy with that is incorrect.
- In the case TOSWidget implements 'config', and Pack or Place or both implements it, you get TOSWidget's implementation, but anything expecting Pack or Place behavior will not get it, and is incorrect.
- If both Pack and Place implement 'config', but TOSWidget does not, you get a compile-time error.
I still don't understand your comment implying that the fact that
something that expects Place behavior will get Pack behavior from TOSWidget
means strait is inferior to Rust's version. I don't see how Rust can do better that that -- any code that expects Place behavior from the 6 methods defined in TOSWidget is just plain incorrect code in Rust as well as in strait. I guess you're implicitly appealing to Rust's UFCS (universal function call syntax)? That's kind of unfair: it should be easy to implement a UFCS for strait traits, although it might need a clumsy syntax. As pointed out in Rust documentation and bug reports, UFCS is only rarely needed, so clumsy syntax is not such a problem.
"and fuck you for ..."
Not at all. I was mostly inviting you to correct my understanding by explaining the details of Rust's implementation and pointing out where it differs. I gather you aren't interested in trying, but I'm always happy to help.
"... trying to get me to think."
I put 2 hours into composing that post, and another 2 into this one. If that's your definition of "refusing to think," you're wrong.
Good luck, anyway.
Regards, _______________________________________________ Python-ideas mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/CPFW6C... Code of Conduct: http://python.org/psf/codeofconduct/