Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Independent VB development team? #492

Open
WolvenRA opened this issue Feb 5, 2020 · 74 comments
Open

Independent VB development team? #492

WolvenRA opened this issue Feb 5, 2020 · 74 comments

Comments

@WolvenRA
Copy link

WolvenRA commented Feb 5, 2020

I'm beginning to wonder if maybe the VB community needs to create an independent VB development team. The team would need to consist of sub teams that work on the various components of the entire development tool chain. If I'm not mistaken, (although I could be), it seems like pretty much the entire tool chain for .Net and .Net Core is supposedly Open Source... but I don't know about the Visual Studio IDE. VS Code is open source but it doesn't contain a number of the components needed to create the entire solution\package.

In any case, why couldn't we make a Fork of the entire development tool chain and control our own destiny? Including incorporating VB into the new .Net Core web development pieces (MVC, Web API, Razor, WebForms, etc.) as well as other portions of .Net Core. In short, Actually Fulfilling the promise Microsoft gave us at the beginning of .Net to keep VB essentially equal to C# through their "Co-Evolution" strategy.

The reason I think we might need to do this is because Microsoft is clearly bailing out of their commitment to VB. While I think this is complete cowardice and blatant treachery on Microsoft's part, we have to face the facts. Just as they shafted the original VB developers, they are now heading down the same path with the VB.Net developers. And just as it cost them thousands of loyal VB developers, I have no doubt it's going to cost them thousands more loyal VB.Net developers. But apparently Microsoft doesn't need the VB.Net developers or the millions of business clients using applications written in VB.Net... (Python anyone?)

I think one of the reasons we don't see as much participation in this Github VBLang community is because most VB.Net developers are business application developers... not system developers. i.e. we don't write Compilers, OS's, Runtimes, Drivers, etc... Consequently most of us (myself included) don't have the background or experience to be able to actively participate in the development of Roslyn, the Framework, the CIL, the Runtime, the VB Compiler etc.. Nor the time. We counted on Microsoft for that. Hard to imagine why we feel stabbed in the back...

Apparently we will have to step up and do it ourselves. While I'm sure I could learn how to help write all these development chain tools, I quite frankly don't have the time or desire. BUT! Since I'm sick and tired of being dependent on an unreliable Microsoft, I would be willing to pay a reasonable annual fee to an INDEPENDENT, DEDICATED, COMPETENT, VB Development team to do it for me.

So, How many others would be willing to support such a team?

Question for Kathleen or one of the other top MS people... How many developers does MS actually have working on the various .Net components specifically for VB?

@WolvenRA
Copy link
Author

WolvenRA commented Feb 5, 2020

P.S. I want to make clear that I'm not trying to disrespect, discourage or blame the current Microsoft developers working on VB.Net. I don't think Microsoft's quietly shoving VB.Net to the side is their fault. I'm sure it's a decision being made higher up the corporate ladder.

@paul1956
Copy link

paul1956 commented Feb 5, 2020

My biggest concern was the closing of VB Prototype "Checked expressions"
#41104 by Jared Parsons with the comment. Who is the "We" in the statement below?

We do not accept unexpected language feature pull requests. Please follow the documented policy for adding features to the language.

I don't want to see a fragmented VB language and comments like that and this topic will lead to that.

@WolvenRA
Copy link
Author

WolvenRA commented Feb 5, 2020

I don't want to see a fragmented VB language either... But if Microsoft is not going to keep it current with new technologies, then what choice do we have? As I see it, the only other options are to A: learn another language, or B: accept being relegated to merely supporting what will become "legacy" applications. I don't find either of those acceptable when we have a third option... the one I outlined above.

Ideally MS would wake up and realize they can't afford to keep losing developers and all of the businesses those developers provide software for. Unfortunately, big profits cloud their thinking...

@Padanian
Copy link

Padanian commented Feb 5, 2020

I actually don't mind see VB being fractured to pieces.
It already happened elsewhere in the past: from ashes of a project, new and more fruitful ones blossom.

@RevensofT
Copy link

Why not modular model ? when we import (maybe call it plugin) dll, it add new language feature from community.

Plugin Recursion.dll

Function Factorial(Input As Int32) As Int32
      Dim Output = 2
      Recur Until Input < 3
            Output *= Input
            Input -= 1
      End Recur
      Return Output
End Function

Harmony project maybe a good example to do this.
https://github.com/pardeike/Harmony/wiki

@tverweij
Copy link

tverweij commented Feb 5, 2020

I think one of the reasons we don't see as much participation in this Github VBLang community is because most VB.Net developers are business application developers... not system developers. i.e. we don't write Compilers, OS's, Runtimes, Drivers, etc... Consequently most of us (myself included) don't have the background or experience to be able to actively participate in the development of Roslyn, the Framework, the CIL, the Runtime, the VB Compiler etc.. Nor the time. We counted on Microsoft for that.

I agree 100% - that is why I contacted others that can do it; with already 5 other langugaes with a shared compiler, the only work they have is to add the language syntax and the specific VB things.
Instead of starting blank, my idea was to start with professionals that know what they are doing.
No for free, but at this moment I am paying Microsoft too (and for what?).

@tverweij
Copy link

tverweij commented Feb 5, 2020

I don't want to see a fragmented VB language

Is there another choice?
No request is accepted, Core does not work proper (yet?), mobile development is impossible, web development has been taken away.
If I look at our PM's twitter, I see C# instead of VB. (look at our previous PM's twitter; it is all about VB as you would expect from our PM).

So my hopes are gone. Microsoft won't help us.

@TeddyAlbina
Copy link

I don't want to see a fragmented VB language

Is there another choice?
No request is accepted, Core does not work proper (yet?), mobile development is impossible, web development has been taken away.
If I look at our PM's twitter, I see C# instead of VB. (look at our previous PM's twitter; it is all about VB as you would expect from our PM).

So my hopes are gone. Microsoft won't help us.

No one want to do mobile apps with VB.net

@Padanian
Copy link

Padanian commented Feb 5, 2020

I do, why not?

@tverweij
Copy link

tverweij commented Feb 5, 2020

No one want to do mobile apps with VB.net

As I see your profile, you are doing only C#, so it's just YOU don't want to do mobile (or whatever) with VB.

@StefanDirnberger
Copy link

StefanDirnberger commented Feb 5, 2020

We develop mobile apps with VB.Net, too.
But a much better support with Xamarin and VB.Net would be very helpful

@Hamenopi
Copy link

Hamenopi commented Feb 5, 2020 via email

@AdamSpeight2008
Copy link
Contributor

From my experience the Roslyn developers can be downright hostile, to potential contributors, who have little experience with the codebase. Documentation is lacking, especially "internal" tools, for example the "syntax.xml" and "BoundNodes.xml" has little explanation. Often having to use trial-error to make any changes or progress. The tools that is to build the syntax and bound nodes for the languages, doesn't produces, contextually meaning diagnostic error messages. Instead it produces errors when you compile the resultant outputs.
An historical record of design decision, would help to understand the rationale behind them, at the time.

I have and do, implement prototypes of feature, would use and like. Yet don't yet have the skill or knowledge to convert them into a viable feature, That could be added to a "official" version of the language. Tried to follow their procedure of submit proposals, and it feels like shouting into a dark empty office. The computer power lights are on, but nobodies in. It is not an environment the cultivates the small number of programmers interested in compilers. Encouraging them and helping them to learn. Eventually it becomes "whatever", disinteresting and murders to passion that they had for both languages VB.net and C#.

@WolvenRA
Copy link
Author

WolvenRA commented Feb 5, 2020

Isn't it interesting that a number of the more popular "new" languages have a VB style syntax? Specifically, NO CURLY BRACES! Python, Nim, Julia, and others. Isn't it also interesting that Microsoft is spending a LOT of effort to support and promote Python which is very similar to VB.Net, while at the same time trying to sideline VB.Net which is far superior to Python... Why? If they would support and promote VB.Net with .Net Core which will enable VB.net to be used cross platform, I believe VB.Net would become more popular than Python.

@tverweij
Copy link

tverweij commented Feb 5, 2020

I am afraid they just did the math.
Beginners go to VB - and a lot of people just stayed there because VB could do almost anything.
source: https://devblogs.microsoft.com/dotnet/the-net-language-strategy
it states that:

An interesting trend we see in Visual Studio is that VB has twice the share of new developers as it does of all developers. This suggests that VB continues to play a role as a good, approachable entry language for people new to the platform and even to development.

and:

However, outside of VB’s core scenarios many undoubtedly switch to C#

So the less VB can do, the more users will switch to C#.

Tiobe index this month:
VB: 5.8%
C#: 5.9%
Together: 11.7%

This will make C# the third language instead of the fifth.
And the less VB can do, the less they have to support, so they can put the resources on C#.

@tverweij
Copy link

tverweij commented Feb 5, 2020

And if you read this: https://devblogs.microsoft.com/vbteam/digging-deeper-into-the-visual-basic-language-strategy/
Yes, from Anthony, not Kathleen, you read that everything outside Windows development is off limits for VB. They DID communicate it. We did not (want to) see it.

VB is Winforms and WPF. And that's it. For everything else, you need C#.

@WolvenRA
Copy link
Author

WolvenRA commented Feb 5, 2020

Why should anyone switch from VB to C#? Up until recently there wasn't anything you could accomplish in C# that you couldn't do in VB. Yes, I realize you could play with toy pointers (not REAL pointers like C or C++), but you don't need pointers to accomplish the task... which is why they're not in VB in the first place.

Not only could you do anything you needed in VB, but once compiled there wasn't any difference anyway. Why use ugly syntax if you don't have to?

@tverweij
Copy link

tverweij commented Feb 5, 2020

Those are the words of Mad (nice name in this context btw), not mine.
Microsoft thinks VB is just an entry level language, and when you want more you switch to C#.
Again, not my words.

@paul1956
Copy link

paul1956 commented Feb 6, 2020

VB has always been more than a compiler. Microsoft is going a good job making sure the IDE (codefixes) continues to have parity between VB and C#. A lot of work is going on getting WinForms to work for VB which is a lot more complex then C# because the IDE and WinForms and VB are all tangled together. I don't need many new features in VB except to make sure it can consume all Core libraries. I would like to see unchecked math built in and a few other things but I'm OK with the language being behind C#, VB should not be a "pioneer" here.

@paul1956
Copy link

paul1956 commented Feb 6, 2020

BTW it look 18 months from the time I proposed adding "Comments after Line Continuation" until it was in VB 16. Microsoft added another feature at the same time (one I have no idea why it was added and I have seen no document about). I am working with someone to improve VB formatting which I started mid-2019 and some day it will get integrated. Because there is little documentation on the formatter I can't make progress myself and that will be the problem just splitting the language. If you want a feature following the painful process does work.

@WolvenRA
Copy link
Author

WolvenRA commented Feb 6, 2020

Personally, I want the option of developing cross platform and mobile apps in VB.Net. I find it interesting that at the same time that VB.Net has been climbing in popularity over the past few years we began hearing more howling and hating from the C# crowd. Did someone see the writing on the wall and realize that if they didn't do something VB.Net would become the #1 preferred .Net language?

@vbcodec
Copy link

vbcodec commented Feb 6, 2020

MS pushed VB into 'discourage phase'. Reason for this is not language itself, but tools. Making VB tools for each platform (Xamarin, ASP NET, Azure, Blazor, etc) require heavy investment, new teams and more complex structure of these tools, to handle two different languages. Keeping in mind that tools for C# now require all possible resources, and these tools are far from mature / polished, it is highly unlikely that MS will split these resources for two languages. Current policy for VB is to enable it in platforms only where tooling requirement is minimal.

if some Independent VB development team will take risk and create (paid) VS extensions with tools, then MS could eventually transfer some newest features from C# to VB, IMO.

@WolvenRA
Copy link
Author

WolvenRA commented Feb 6, 2020

MS had 39.2 Billion in Net Income last year (2019). They certainly have the money to add VB.Net to the new platforms. If they need to add new developers for those tools, they certainly have the resources to hire them. It's not a matter of lack of "resources". It's simply a matter of will, and honoring your commitments.

@Hamenopi
Copy link

Hamenopi commented Feb 6, 2020 via email

@paul1956
Copy link

paul1956 commented Feb 6, 2020

@Hamenopi Interesting, I have posted resumes looking for VB.Net jobs and all I get are C# sometimes when I look at other .Net jobs they want VB experience. The .Net confuses the search engines.

@WolvenRA
Copy link
Author

WolvenRA commented Feb 6, 2020

@Hamenopi What kind of application are you building?

@zspitz
Copy link

zspitz commented Feb 6, 2020

VS Code is open source but it doesn't contain a number of the components needed to create the entire solution\package.

What pieces are missing? I think having a cross-platform, .NET Core-based toolchain leveraging open parts like VS Code would be a great first step, much like OmniSharp pushed forward the development of .NET Core.

@WolvenRA
Copy link
Author

WolvenRA commented Feb 6, 2020

I'm not sure what all of the pieces missing from VS Code are... I'd have to find the article that I read explaining which pieces were missing. Basically it said you could Edit, Run and Debug your code but things like creating an install file and a number of others weren't there. I did read another article saying that pieces are being added and it's getting closer all the time. Although I don't think the added pieces were for VB.Net in particular.

I do agree with Paul1956, it would be MUCH nicer if MS would just add the functionality we're looking for. They can hire the developers and play nicer with the open source developers to do the work.

@Padanian
Copy link

Padanian commented Feb 6, 2020

Yes, from Anthony, not Kathleen, you read that everything outside Windows development is off limits for VB. They DID communicate it. We did not (want to) see it.

You mean the same article where I read: "bridge existing applications into mobile and [...]new services optimized for the cloud from the ground up [...] align very strongly with F#[...]"

And yes, they communicated it, but they publicly denied allegations (or minimised to avoid concern) while privately regretting that choice.

@vbcodec
Copy link

vbcodec commented Feb 6, 2020

MS had 39.2 Billion in Net Income last year (2019). They certainly have the money to add VB.Net to the new platforms.

Business do not work this way. Every department have his budget, goals, agendas, and their primary task (management level) is make profits, maintain / expand marketshare and fully exploit every opportunity that currently exist or will exist in foreseable future. Seems that current model (expanding C# with tools / maintain VB with current tools) is best from organisational / financial POV.

Making perfect world is not target for business

@zspitz
Copy link

zspitz commented Mar 17, 2020

@WolvenRA

Wouldn't it be nice if things would just auto-initialize to the non-null defaults, unless we specified otherwise?

What's the non-nullable default for System.Random? Or SqlConnection? We can get close enough for government work by saying "This variable must be initialized right away, and assigning Nothing -- or something that might be Nothing -- to it is not allowed".

@tverweij
Copy link

@WolvenRA
Wouldn't it be nice if things would just auto-initialize to the non-null defaults, unless we specified otherwise?

Just use a property instead of a field that sets the default?

@zspitz
Copy link

zspitz commented Mar 17, 2020

@tverweij You mean the property should set the default?

Class Foo
    Dim bar As Random

    Property Bar As Random
        Get
            If bar Is Nothing Then bar = New Random
            Return bar
        End Get
    End Property
End Class

That's all well and good until some other member within the class calls the field directly instead of the property. And I don't think there's any way to prevent that kind of access. Having nullable reference type handling would allow a compiler warning.

  • If the field has been defined as allowing Nothing, then there would be a warning on the usage of the field, that you need to check that the field isn't Nothing.
  • If the field has been defined as not allowing Nothing, there would be a warning at the declaration that the field needs to be initialized; but after that initialization the field could be used freely.

@Happypig375
Copy link
Member

That's all well and good until some other member within the class calls the field directly instead of the property. And I don't think there's any way to prevent that kind of access.

Semi Auto Properties?

@tverweij
Copy link

Local properties and Non Nullable References are implemented right now. But not In Microsoft VB.

@zspitz
Copy link

zspitz commented Mar 17, 2020

@Happypig375 Semi Auto Properties?

@tverweij Local properties?

@tverweij
Copy link

@zspitz

Properties defined in the method body. Just like local functions (That Microsoft VB doesn't have either, but C# does).

@Happypig375
Copy link
Member

@Happypig375
Copy link
Member

which is a better solution to

That's all well and good until some other member within the class calls the field directly instead of the property. And I don't think there's any way to prevent that kind of access.

@Happypig375
Copy link
Member

@tverweij I don't think C# has local properties, only local methods.

@tverweij
Copy link

@Happypig375 : That is what I meant to say.

@WolvenRA
Copy link
Author

@zspitz

Wouldn't it be nice if things would just auto-initialize to the non-null defaults, unless we specified otherwise?

What's the non-nullable default for System.Random? Or SqlConnection? We can get close enough for government work by saying "This variable must be initialized right away, and assigning Nothing -- or something that might be Nothing -- to it is not allowed".

When the object is created, unless overridden, all fields and properties would be set to whatever the base type default value is. 0 for Integers, Floats, Decimals, etc. An empty string for String, a blank for Char. So for SqlConnection the Connection String value would be a blank string, the Connection Timeout would be 0, etc..

Gettting a Null Reference Exception because we try to access an object that hasn't been Created yet makes sense (actually the error should be "'Object' doesn't exist"). But other than that, I shouldn't ever have to worry about some value being Null. Unless I SPECIFICALLY defined something as Nullable... which I would never do.

@Happypig375
Copy link
Member

@WolvenRA Ahh yes, a Person with name and age 0 is definitely a valid object.

@Happypig375
Copy link
Member

Or a table with color 0x00000000 (transparent) and 0 legs.

@zspitz
Copy link

zspitz commented Mar 17, 2020

@WolvenRA

When the object is created, unless overridden, all fields and properties would be set to whatever the base type default value is.

What about fields whose type is not a value type? The default value for these is generally Nothing.


@Happypig375

Ahh yes, a Person with name and age 0 is definitely a valid object.

Isn't it generally more appropriate to store the date of birth in the object and have age calculated from the date of birth? Assuming Date defaults to Date.MinValue, the default person would be really, really old. 😊

@Padanian
Copy link

@WolvenRA post is the one that makes more sense in this whole thread. And yes a person with no name and 0 age is a perfectly acceptable object in a neonatal ICU, or as far as the programmer instantiate a person without initialising its properties. That's a mistake of the programmer and as such shall remain. For all other objects without a default value, Nothing is a perfectly acceptable value.
Dim ToSeeHere as Object = Nothing 'move along.

@zspitz
Copy link

zspitz commented Mar 17, 2020

@Padanian Consider the following code:

Dim ToSeeHere As Object = Nothing
Console.WriteLine(ToSeeHere.GetType.Name) ' falls with a NullReferenceException

Where was the programmer's mistake? Was the mistake in originally assigning Nothing, and that should have been prevented? Or was the mistake in trying to access something that might have had Nothing without checking that ToSeeHere IsNot Nothing first? We don't know the author's original intention when declaring ToSeeHere.

Now, if there's some way to separate between the two (either explicitly declaring the null-allowed, or explicitly declaring the null-disallowed), the compiler can warn either on the inappropriate assignment ("You're trying to assign Nothing to something which isn't supposed to take Nothing) or on the potentially unsafe usage ("You're trying to use a property or method of something that might be Nothing").

Just as the compiler prevents the mistake of trying to add two instances of System.Random, because Operator '+' is not defined for types 'Random' and 'Random'., if the compiler can warn about Dereference of a possibly null reference. it should certainly do so.

@Padanian
Copy link

Objects needs to be declared, instantiated and then initialised.
Anything declared, instantiated but not initialised OR purposefully initialised to Nothing have value Nothing.
That's all there is about this matter.
Oh no, there is a thing: the exception message is wrong. It shall read NothingReferenceException.

@zspitz
Copy link

zspitz commented Mar 18, 2020

@Padanian The error message comes from the CLR; Nothing is used by VB to represent the concept of a reference that doesn't point to anything.

Anything declared, instantiated but not initialised OR purposefully initialised to Nothing have value Nothing.

Except that somewhere in the intervening code you changed the Nothing-ed variable it to another object. Or you changed a previously initialized variable to Nothing. Or your code usually intializes the variable, except on alternate Tuesdays, when it gets set to Nothing. Or your JSON result returns Nothing when you expect it to return something. And I've forgotten that this previously non-Nothing variable was set to Nothing and try to call a property or method on a non-existent object.

Variables can vary; that's why they're called variables.

My point is, with null reference type handling, the compiler can identify and warn about such potential problems, making it easier to fix them.

@WolvenRA
Copy link
Author

@zspitz

@Padanian Consider the following code:

Dim ToSeeHere As Object = Nothing
Console.WriteLine(ToSeeHere.GetType.Name) ' falls with a NullReferenceException

Where was the programmer's mistake? Was the mistake in originally assigning Nothing>

I would argue that IF the programmer assigned Nothing then, yes, it's their responsibility to check for that (and having the compiler give a Warning is fine). But if the programmer did this:

Dim ToSeeHere As New Object

Then ANY and ALL properties, fields, etc. SHOULD be set to either some predetermined value OR to the base default value for that property\field type... NOT NOTHING!

If they did this:

Dim ToSeeHere As Object

Then it's up to them to instantiate it before they try to use it (and again having the compiler give a Warning is fine).

And @Happypig375

Ahh yes, a Person with name and age 0 is definitely a valid object.
Or a table with color 0x00000000 (transparent) and 0 legs.

Whether it's valid or not is irrelevant. That's the programmers responsibility. BUT, it SHOULDN'T be Null\Nothing, (unless the programmer SPECIFICALLY set it to Null\Nothing).

Other than an un-instantiated object, NOTHING should be Nothing or Null... :) (Again, unless the programmer SPECIFICALLY set it to that.)

I forget who the guy was that originally came up with the idea of Null (originally as a string terminator I believe), but I read an article where HE said it was the biggest mistake in the history of computer science. I agree with him. Nulls are just *&^%$ stupid.

@Happypig375
Copy link
Member

Happypig375 commented Mar 18, 2020

@WolvenRA

Class A
   Public O As Object ' Uninitialised, so Nothing
End Class
Class B
   Public A As A ' Uninitialised, so Nothing
End Class

Dim A1 As A ' Nothing
Dim A2 As New A ' Now A2.A.O is initialised?

@Happypig375
Copy link
Member

Happypig375 commented Mar 18, 2020

And this:

Public Class C
    Public A As Console ' Yes, System.Console
End Class
Dim c As New C ' What is the value of c.A?

@Padanian
Copy link

@zspitz

Dim ToSeeHere As New Object

        Dim ToSeeHere As Object = New Object
        Console.WriteLine(ToSeeHere.GetType.Name)

In fact correctly returns

Object

I think the whole discussion here is about good programming practice.
There are times where objects have default properties set, like e.g. System.IO.Ports.SerialPort , but can be instantiated and uninstatiated at runtime.
Trying to open or close a SerialPort that hasn't been instantiated, or that in the meantime has been disposed of or the underlying hardware removed, eg. a disconnected USB port, will cause a NullReferenceException.
In the above specific case, an object with default values, related to a no longer underlying hw resource would be detrimental.
In general, I always check for "IsNot Nothing" for non-value type objects.
Whether it would require to seed nothing-ness checks everywhere, it's just a matter of proper code factoring.
This is MHO: YMMV.

@zspitz
Copy link

zspitz commented Mar 18, 2020

@Padanian

I think the whole discussion here is about good programming practice.

The ideal of "good programming practice" would say that you obviously shouldn't attempt to add two instances of System.Random. But we're all human, so when we try to write the following either by mistake, or because we're trying to accomplish something specific:

Din rnd As New Random, rnd1 As New Random
Console.WriteLine(rnd + rnd1)

the compiler complains that there is no such operation defined for the Random type. But an essential prerequisite for the compiler to be able to catch this, is that we indicate that rnd and rnd1 are of type Random; the following code would compile just fine (with Option Strict Off):

Dim o As Object = New Random, o1 As Object = New Random
Console.WriteLine(o + o1)

and would only fall at runtime.

This is what null reference type handling brings to the table: a way to indicate that a variable can be Nothing or not, and then preventing operations that might violate that contract.

@Padanian
Copy link

@zspitz
Forbidding alcohol to everybody because a minority could get drunk sounded a good idea at first.
Been there, done that.

@Happypig375
Copy link
Member

Which is why nullable reference types is opt-in: you can choose not to use this feature entirely.

@zspitz
Copy link

zspitz commented Mar 18, 2020

@Padanian Were you in the forbidden? Or in the minority? 😊

But I don't quite understand what you're trying to say. Nobody is proposing that Nothing be disallowed; only that a variable that might contain Nothing be declared as such, and prevented from being misused. By (really bad) analogy, you're not allowed to sell alcohol to minors, therefore you don't have to give them a breath analysis test; and someone who is not a minor must take such a test before operating heavy machinery.

@Padanian
Copy link

Alright, we made our point clear. No need to further discuss the matter. Thanks for your patience.
As for the breath test to minors, oh god you're so wrong.

@WolvenRA
Copy link
Author

@Happypig375

Obviously neither Object O nor Console A are initialized or instantiated... but I'm not sure what the point is. Furthermore I'm not clear how the "Nullable Reference Types" (a HORRIBLE name for something that's actually supposed to enable NON Nullable types) feature being added to C# would change anything in your two scenarios. As I understand it (and could definitely be wrong) so the compiler will give you a warning about EVERY possible access of something that COULD be Null\Nothing.

Dim A as Decimal = 10
Dim B as Decimal
Dim C as Decimal

C = A / B

Would we want the compiler to give us warning EVERYTIME we do a division about POSSIBLY dividing by zero?

As I understand it (and again could definitely be wrong), the feature being added to C# is to enable types that CAN'T be null\nothing so you don't have to bother adding code for null\nothing checks. While that makes sense, it seems you're still going to have lots of un-instantiated objects that will still need the checks soooo... ?

@zspitz
Copy link

zspitz commented Mar 19, 2020

@WolvenRA I think @Happypig375 's point is that there is no default value to which reference types can be initialized. Even after you've initialized your immediate variable with an an instance of an object, the individual properties also have the same problem -- if those properties are of reference types, they also need to be initialized. IOW, the following:

Then ANY and ALL properties, fields, etc. SHOULD be set to either some predetermined value OR to the base default value for that property\field type... NOT NOTHING!

is impossible.


Furthermore I'm not clear how the "Nullable Reference Types" ... feature being added to C# would change anything in your two scenarios.

Because the compiler warns on a class with uninitialized fields. In the A class there would be a warning about O; in the B class, about A; and in the C class, about A.


the compiler will give you a warning about EVERY possible access of something that COULD be Null\Nothing.

Actually, it only warns about the first access of a given variable within the current scope; once you fix that warning, the next warning lights up. And the compiler detects many cases (there may be others) where even though the CLR type can contain Nothing, the variable will (usually) not be Nothing:

  • If the variable has been declared without the nullable annotation (?) -- the compiler will warn on missing initialization, or possible Nothing assignment to the variable; but there will be no warnings on any member access from the variable itself.

    Dim rnd As Random                                   ' warning
    Dim rnd1 As Random = Nothing                        ' warning
    Dim rnd2 As Random = (Function() Nothing).Invoke    ' warning
    
    Console.WriteLine(rnd.Next, rnd1.Next, rnd2.Next)   ' no warning
    
  • Even with the annotation, if the variable has been assigned to in the current scope with a presumed non-Nothing instance

    Dim rnd As Random?
    rnd = New Random
    Console.WriteLine(rnd.Next)       ' no warning
    
  • With the annotation, if the variable has been tested as not Nothing

    Dim rnd As Random?
    ' some code
    If rnd IsNot Nothing Then Console.WriteLine(rnd.Next)  ' no warning
    

Would we want the compiler to give us warning EVERYTIME we do a division about POSSIBLY dividing by zero?

Perhaps. However, I would suggest division by zero is a little different, because

  1. it's a far less common error than NullReferenceException, by an order of magnitude at least; and

  2. 0 has possible meaning in almost every other context that an Integer can be used -- addition, multiplication, use in a default property, ToString. In contrast if I have a variable of type Random which points to Nothing, I cannot do all the stuff I could do with a Random; the only thing I can safely do is check that the variable doesn't point to Nothing. It's reasonable to think of Nothing as a different type than Random, particularly since the following prints True:

    Dim o As Object = Nothing
    If TypeOf o IsNot Object Then Console.WriteLine(True)
    

the feature being added to C# is to enable types that CAN'T be null\nothing so you don't have to bother adding code for null\nothing checks. While that makes sense, it seems you're still going to have lots of un-instantiated objects that will still need the checks

Only for those places where your design mandates the possibility of Nothing, which is something you should be doing anyway. The feature only encourages you to write those null-checks.

Also (as I noted above) there is a warning on classes with fields which aren't supposed to contain Nothing but aren't initialized in the constructor or the field declaration. This prevents classes from having fields with a non-nullable type that are uninitialized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests