3 ms·
(your formatting got a little lost but I get the gist) I've done a little langdev and I've found that UFCS interferes with stuff like field access (person.name
by camgunz 3y ago
(your formatting got a little lost but I get the gist)
I've done a little langdev and I've found that UFCS interferes with stuff like field access (person.name) or things like interfaces. Let's say you have a person struct like { name: str } but then also a Label interface like Label { name: fn () -> str }.
It's kind of a broader problem of being able to extend things in any place you might imagine, like I'll implement a trait on this struct here, I'll implement a function on this struct here, etc. etc. and before you know it your code is extremely nonlocal. There are ways to temper this, e.g. Rust combats this a little by having to have traits in scope for them to apply, but that's annoying in its own way.
I'm just saying it's not a free lunch, I think anyway.
- FireInsight 3y agoSorry about the formatting, typing this on my phone. The preview looked alright, but ig that didn't translate. For the function-field interference, I'd probably just work it based on situation. And usually naming functions clearly as actions with verbs and fields/variables with nouns.
- camgunz 3y agoSure yeah but like, you gotta deal with clashes. The problem itself isn't hard, but trying to get the ergonomics right is pretty tough, especially when you're talking about multiple dependencies that didn't coordinate at all with each other (this trait adds a "name", this one adds a "getName", this one adds a "display_name", this one adds a "get_name").
- FireInsight 3y agoThe mixing of snake_case and camelCase is solved by Nim by ignoring capitalization and underscores. This feature is often controversial when talked about on HN, but I love it. I like camelCase, but I understand why a python user would be more comfortable with snake_case. Of course one codebase should set its internal style to prevent faults in control-f.