DateTime.Today Error - vb.net

In VS2010 for a VB.NET 4.0 project, the IDE puts a green line under the last line in the following code:
Dim cityLocal As DateTime
cityLocal = externalFunction()
cityLocal.Today()
The suggested code replace is to update 'cityLocal' with 'Date'. The reason is:
Access of shared member, constant member, enum member or nested type through an instance; qualifying expression will not be evaluated.
But it does compile and does work correctly. Is this just a bug in the VS2010?

Today is a shared member, thus should not (but can) be accessed through an instance of DateTime change your code to.
DateTime.Today
Although Visual Studio gives you suggestions to correct the "Error" it is infact a compiler warning, warning you that there is no need for an instance to access the shared member. You'll find that it is not listed as an error in the error list. Which is why it compiles correctly.
The Visual Basic language specification states
9.2.4 Shared Methods
The Shared modifier indicates a method
is a shared method. A shared method
does not operate on a specific
instance of a type and may be invoked
directly from a type rather than
through a particular instance of a
type. It is valid, however, to use an
instance to qualify a shared method.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=01EEE123-F68C-4227-9274-97A13D7CB433:
More information on the warning can be found in the documentation.
http://msdn.microsoft.com/en-us/library/y6t76186.aspx

Date.Today is a static (Shared in VB.NET) property. You are able to use it from an instance because the compiler knows to make the proper call, but it is not the expected usage pattern, which is both unnecessary and undesirable to use directly from an instance.
As a static variable, you should use Date.Today rather than variable.Today.

Today is a shared/static member. Normally you would use DateTime.Today not your instance variable.
http://msdn.microsoft.com/en-us/library/system.datetime.today.aspx

Related

How serious is BC42020 in an upgraded VB .Net project?

Consider the following line of code which used to compile without warnings.
Public SetUpDone = False
After upgrading a project to Visual Studio 2017 from Visual Studio 2005 over a hundred of these BC42020 warnings exist. The MSDN description of the warning simply states that the variable defaults to type object. I don't have a good idea of the seriousness of this type of warning. The debugger indicates that the code executes as I expect. Is it merely a performance type of issue?
Secondly, I thought that Visual Basic supported some form of Type Inference so I'm not clear about why it wouldn't be able to deduce that the type should be Bool.
Another example is the following where the function returns a String
Dim dayTxt = " " & GetTextFromIni("General", "Var50")
I would have thought that type inference would work here and deduce that dayTxt is a String.
This:
Public SetUpDone = False
Is equivalent to this:
Public SetUpDone As Object = False
As suggested, type inference is only for local variables, not fields. With Option Infer On, this inside a method:
Dim SetUpDone = False
would indeed be equivalent to this:
Dim SetUpDone As Boolean = False
There are a couple of issues with the code as you have it. Firstly, it means that every use of that False value requires unboxing which makes your code slower. That's the case for any value types, i.e. structures. Value types are normally stored on the stack but, when boxed, are stored on the heap.
Secondly, it means that any member access will require late binding. That's not an issue for Boolean values because they have no members of interest anyway but if it was, say, a DateTime then the IDE would never provide Intellisense for that type because al it would see would be type Object and the existence of the specified member would have to be confirmed at run time, making the code less efficient again.
Thirdly, it means that the compiler can never confirm that you're passing the correct type as a method argument. For instance, if you have a method with a Boolean parameter, the compiler won't know that you're passing a Boolean if you pass that field because it's type Object. That also means that if you pass some other Object variable that doesn't contain a Boolean, the compiler can't warn you.
As suggested, you should turn Option Strict On in the project properties. That will flag every instance of you're not specifying the appropriate type for something. Fixing those errors will, at the very least, make your code a bit more efficient. It may even draw your attention to situations where exceptions will or could be thrown at run time. Having Option Strict On enforces strict typing so it makes you think more about the types you're using. Even if you're conscientious about that with Option Strict Off, you can still make mistakes that Option Strict On will prevent.

A Roslyn bug? On non-shared member, I'm getting error that I'm using 'shared member initializer'

Have the following trivial code:
Class A
Private value As Integer = 1
Sub Action(Optional param1 As Integer = value)
End Sub
End Class
Visual Studio complains about default value (value) with error BC30369:
Cannot refer to an instance member of a class from within a shared method or shared member initializer without an explicit instance of the class.
Is this really the right error for this case? The method is not shared.
In Visual Studio 2012 or 2013, the error in the same case is
Constant expression is required.
what absolutely makes sense.
After additional research I think that there is a problem in order of checks made by compiler.
If I change the code, making value member Shared, I get correct result: Error BC30059
Constant expression is required.
Since nothing except constants can be placed into default value of Optional clause, check for the above BC30059 ("Constant expression is required.") should be obviously made "earlier" than the check for BC30369 (shown in question).
I created bug report at Microsoft Connect.

'System.Delegate._methodPtr' is not accessible in this context because it is 'Friend'

While trying to access the methodptr property of a delegate object, I am getting the error:
"System.Delegate._methodPtr' is not accessible in this context because it is 'Friend'
,is there some method through which I can access this value and assign it to a variable?
is there some method through which I can access this value and assign it to a variable?
You can use reflection1 to retrieve the value. However, you probably don’t want to do this: this value is Friend for a reason. It’s an implementation detail and you as a consumer of the framework have no right to access it directly: it may work, or it may break suddenly (e.g. when Microsoft distributes an update of the library). Your code also won’t work on alternative .NET implementations, such as Mono.
In particular, this member is not documented in the MSDN and as such its presence or behaviour can’t be relied on.
1 The following should do the trick:
Dim delegateType = yourDelegateObject.GetType()
Dim field = delegateType.GetField("_methodPtr", _
BindingFlags.Instance Or BindingFlags.NonPublic)
Dim methodPtr = DirectCast(field.GetValue(yourDelegateObject), IntPtr)
Untested, since I only have Mono and (as mentioned above) it won’t work here anyway.

VBA: how to test for object equality (whether two variables reference the same object)

What is the operator or function to test whether two variables of the same custom object type refer to the same object? I've tried
If myObject = yourObject Then
But get a runtime error 438 object doesn't support this property or method. I'm guessing that's telling me to override the '=' operator to test if all the fields of the two objects have the same value. But what I want is to test whether they are the same object.
I'm guessing that's telling me to override the '=' operator to test if all the fields of the two objects have the same value.
No, it tells you the objects don't have a default property which would have been called otherwise, and the returned results compared.
You test reference equality with Is
If myObject Is yourObject Then
You need to serialize the objects somehow and then compare attribute by attribute values. The "is" operator is as dumb as it gets, it only matches if another object is the same instance assigned to the compared variable.
I suggest using a jsonStringify library. I adapted one for my DexTools.xlam open source project https://github.com/dexterial/Dextools/tree/master/Main starting from the Parsing JSON in Excel VBA post. It has much more added features since I added quite a few other excel objects serialization/hashing options and it is made using the vba test driven development that DexTools incorporates. It is still work in progress so dont expect miracles

Java: Why method type in .class file contains return type, not only signature?

There is a "NameAndType" structure in the constants pool in .class file.
It is used for dynamic binding.
All methods that class can "export" described as "signature + return type".
Like
"getVector()Ljava/util/Vector;"
That breakes my code when return type of the method in some .jar is changed, even if new type is narrower.
i.e:
I have the following code:
List l = some.getList();
External .jar contains:
public List getList()
Than external jar changes method signature to
public ArrayList getList().
And my code dies in run-time with NoSuchMethodException, because it can't find
getList()Ljava/util/List;
So, I have to recompile my code.
I do not have to change it. Just recompile absolutely the same code!
That also gives ability to have two methods with one signature, but different return types! Compiler would not accept it, but it is possible to do it via direct opcoding.
My questions is why?
Why they did it?
I have only one idea: to prevent sophisticated type checking in the runtime.
You need to look up to the hierarchy and check if there is a parent with List interface.
It takes time, and only compiler has it. JVM does not.
Am I right?
thanks.
One reason may be because method overloading (as opposed to overriding) is determined at compile time. Consider the following methods:
public void doSomething(List util) {}
public void doSomething(ArrayList util) {}
And consider code:
doSomething(getList());
If Java allowed the return type to change and did not throw an exception, the method called would still be doSomething(List) until you recompiled - then it would be doSomething(ArrayList). Which would mean that working code would change behavior just for having recompiled it.