vblang
vblang copied to clipboard
dotnet
[Proposal] Auto extend shared members and vice versa
I usually loose some time trying to use char and string methods as I forget if they are member or shared methods. I also don't know why most of the Char methods are shared not member methods. Why:
Dim res = Char.IsLetter(c)
not:
Dim res = c.IsLetter
So I am thinking, since we are familiar with extension methods, why can't VB consider each shared method an extension one if it starts with a param of the same class type?
This way the c.IsLetter can be lowered to Char.IsLetter(c).
I also suggest the opposite (but it is less important to me): allow to use every member method to be used as a static one:
Dim x = String.Replace(x, " ", "")
which can be lowered to:
Dim x = x.Replace(" ", "")
Maybe we can make it interesting if we treat the shared form as a byRef Sub:
String.Replace(x, " ", "")
So, x is affected in a compact form, as it will be lowered also to:
x = x.Replace(" ", "")
Any way, I am interested most in the auto extension part of this suggestion.
This would make it far harder for anyone not you reading your code and understanding it. Like, if you're having trouble now remembering if a method is shared or not, think of the poor sod new to programming who stumbles upon your code on GitHub and is wondering why none of the methods you are using matches the documentation.
Plus, I think your real issue here is with the .net framework design, and that isn't something that should be fixed at the compiler level
your real issue here is with the .net framework design
.NET Core inherited it as is. Backward compatibility prevents fixing anything, and asking to duplicate methods in many classes is something that will not happen. The compiler is there to give smart solutions for such bad designs. It's not practical to waste resources on issues you can fix programmatically. Besides, such sheared methods have exactly the extension methods signature, except for the <extension> attribute, which is not necessary as the methods belong to the class they extend! This answers the confusion part, and of course documents will add a note of the second possible syntax, which can be auto generated and added to the documents.
Finally, I disagree will any argument involving reading code out of the editor. Apps are too complex to comprehend code viewed as a plain text, where you can't know what user-defined types, methods and params mean.
.NET Core inherited it as is. Backward compatibility prevents fixing anything, and asking to duplicate methods in many classes is something that will not happen.
And you think changing how VB resolves methods won't have any backwards compatibility issues? Your code might not have an issue with such a change, but can you guarantee that the the millions of lines of code written by others won't?
The compiler is there to give smart solutions for such bad designs.
The compiler already issues a warning/error when you try calling a class method on an instance variable, which is really the most it should do.
It's not practical to waste resources on issues you can fix programmatically.
It's also not practical to constantly extend the compiler to solve issues that could be more easily fixed by programmers actually learning the platform they're using. Besides, bad library design is "fixed" by writing a wrapper library, not changing the compiler. This has the added bonus of being a cross language solution, as I'll note that C# suffers the same issues here.
Besides, such sheared methods have exactly the extension methods signature, except for the
attribute, which is not necessary as the methods belong to the class they extend! This answers the confusion part,
The <Extension> attribute is literally what turns a normal class method into an extension method. Turning every class method with the right method signature into an extension method will just end in tears.
and of course documents will add a note of the second possible syntax, which can be auto generated and added to the documents.
Except a lot of documentation doesn't even bother generating any VB syntax. Json.NET, an extremely popular library, doesn't for example.
Finally, I disagree will any argument involving reading code out of the editor. Apps are too complex to comprehend code viewed as a plain text, where you can't know what user-defined types, methods and params mean.
So you admit that you don't care about making the language easier to understand for beginners. It might surprise you, but the vast majority of code you see when learning a new language (or a technique/library/etc.) isn't in an editor.
This suggestion will not break any code so what ever. The compiler will try to find a normal method then an extension method, and finally a static method that can be treated as extension, and intellisense will offer completion in the same order. This is the most efficient general solution instead of writing endless 3rd party wrappers, that too few developer will hear about. The purpose of Extension Attr is to tell the compiler that the methods extends the type of the first param. When the method is already inside the type, there is nothing more to tell the compiler.
Note: All my suggestions aim to design a Fluent Basic (FB.NET), where the language exists to serve the programmer, not the opposite. This is the sprite that made the BASIC language and VB.NET should obtain it back.