3 ms·
> No annotations are required. I appreciate the intent, but man is this like a minefield waiting to be walked over. Anyone who looks at the code will scratch t
by haspok 3y ago
> No annotations are required.
I appreciate the intent, but man is this like a minefield waiting to be walked over. Anyone who looks at the code will scratch their head and will not understand what is going on. An annotation would perhaps make it clearer.
Also, how about IDE support? I would argue it is at least as important as the feature itself.
- rogerkeays 3y agoYes, IDE support would help developers find the method that is being called. This is already quite a problem given we have complex class hierarchies and interfaces with default methods. I'm not sure I see the need for an annotation though.
- haspok 3y agoA compile-time annotation could at least control whether your plugin is allowed to transform the ADT in the given context (say: for a class). Otherwise is it not possible that it transforms the ADT even when the user did not intend to? Can this be a source of mysterious bugs?
- rogerkeays 3y agoThe syntax tree is only transformed when instance method lookup fails. i.e. when your code doesn't compile in standard java form. You would be doing pretty well to accidentally call an extension method seeing as you either have to write them or import them.
- Etheryte 3y agoThis whole what-if scenario is a complete non-issue. Many other languages do this out of the box and have no issues with it.
- tsimionescu 3y agoThe key point is that they do it out of the box, so everyone is aware of it. As it is, it could easily interfere with some other non-standard extension plugin, for example.
- Etheryte 3y agoLiterally any code you write could interfere with some non-standard extension plugin, this is all pointless hot air.
- tsimionescu 3y agoWhich is one of the reasons not many use non-standard extension plug-ins for their compilers.
- kitd 3y agoI appreciate the intent, but man is this like a minefield waiting to be walked over. Anyone who looks at the code will scratch their head and will not understand what is going on. An annotation would perhaps make it clearer. That is the generic argument against extension methods wherever they appear. They are very confusing, until you get used to remembering their existence, then you know what to search for. Also, how about IDE support? I would argue it is at least as important as the feature itself. This is mentioned in TFA.
- pdpi 3y agoExtension methods in a language that explicitly supports them and with good IDE support are perfectly fine. I love them in Kotlin. Extension methods as a compiler plugin that rewrites the AST... not so great. Great IDE support is a large part of what makes Java worth using, the last thing I need is to break that.
- hardware2win 3y agoIn C# world they somehow manage to do it without all of this annotation oriented programming
- deleted 3y ago[deleted]
- rogerkeays 3y agoJust to make it clear, Fluent does not use any annotations.
- stanac 3y agoNot really. First argument (the object you are extending) needs to be marked with `this`, which is an annotation.
- hardware2win 3y agoEhh, ive been talking about whole lang and ecosystem But I agree about "this" being similar concept
- whizzter 3y agoThere are tons of annotations over the hood. The "this" that GP mentions is for for extension methods similar to the article to be regcognizeed as such (never done if the annotation isn't present), they're written such as: static int Foo( this Bar bar, int biz) => bar.xyz+biz; Bar bar = new Bar() { xyz=123; }; int result = bar.Foo(456); // Works even if Foo wasn't a part of Bar initially Elsewhere annotations(called attributes in C# land) can often be used in the same way as in Java to document serialization behaviour,etc. So in practice there aren't much differences apart from how library authors haven't embraced it entirely as much for automagic bindings (partly due to philosophy, partly due to other facilities being more appropriate).
- dtech 3y agoThere is a massive difference between a feature universally offered by the language and something only supported by using a specific library of compiler plugin...
- skybrian 3y agoYes, it’s a slightly different language and should have a different extension, like js versus jsx.
- erik_seaberg 3y agoSome languages allow declaring things like this per file "use strict"; from __future__ import annotations {-# LANGUAGE TemplateHaskell #-} which probably scales better than 2^n filename patterns.
- skybrian 3y agoOfficial upgrades to languages don't result in that kind of combinational explosion of language extension combinations because the features eventually become standard. They do result in a combinational explosion of language feature combinations, though, so there's still a problem with languages just getting big. IDE's and other language tools need to support it too. In JavaScript there is .js, .ts, .jsx, and .tsx. I hope that doesn't become a lot more, but for low amounts of variation, it's reasonable. I think Haskell is a good example of what happens when a language supports too many extensions. Why are there so many? How do people deal with them all? Needing to pick another file extension seems like pressure to do this more sparingly?
- _a_a_a_ 3y ago> is this like a minefield waiting to be walked over "This looks odd to me so no one else can possibly understand it"is not a rigorous argument. Both Scala and C# have this. I've used it in my own code to clean things up. It's fine.