Having just spent the past several hours trying to work out why my Xml Serialization code was not working. Consider the following:
<DefaultValueAttribute(False)>
Public Property UserName() As String
Why is this allowed regardless of option strict being on (or not)?
Quite simple. The DefaultValueAttribute has an overload which accepts boolean values so it will work with or without Option Strict on.
Check this page for more information DefaultValueAttribute Class.
The answer is that VS does not type check default values for VB.NET, regardless of OptionStrict or not.
<DefaultValueAttribute(False)> is valid because the attribute definition is really a constructor and not a type definition, as such it's type is DefaultValueAttribute and not a return type of boolean. Furthermore the .Value property of the DefaultValueAttribute is of type Object and hence it's type cannot be compared either, as such the very existence of DefaultValueAttribute violates Option Strict On and hence Option Strict ignored for the scope of DefaultValue Attributes.
Related
From what I have read so far, late binding is defining a variable as Object and then assigning it to the actual object later which is actually done at run time. I don't understand the point to that. Maybe this is the Java in me, but doesn't that limit the functionality to what is just in Object? It is like saying, "I want the potential of the extra stuff, but I don't want to have access to it." Is there an actual purpose for late binding in VB, or Java for that matter, that I'm overlooking?
You have it backwards. By using early binding you are limiting yourself to just the members of the type of the variable. With Option Strict On, a variable declared as type Object will only allow you access to members of type Object, regardless of the type of the actually object it refers to. With Option Strict Off, you can access a member of any name on a variable of type Object and the compiler won't complain. It's only at run time that any type checking is done so, as long as the actual object assigned to the variable has a member with that name, the code will run.
Probably the most common use for late binding is Office Automation. There are other options now but, in the past, if you referenced an Office library and used the specific types it contained, facilitating early binding, then you were limited to that specific version of Office. In order to support multiple versions, you had to forgo the reference, declare all your variables as type Object and use late binding. As long as the version of Office present at run time included the specified members on the objects used, the code would run without issue.
By the way, late binding doesn't require using type Object, although it is probably the most common. It just means that the reference is a less derived type than the object and you use a member of the object's type that the reference's type doesn't have, e.g. you use type Control and then use a member specific to type Button.
What I seen - some early .NET adapters-developers were doing is - they were using late binding instead on interfaces. They would declare two or more types
Public Class Handler1
Public Sub Execute()
' do something
End Sub
End Class
Public Class Handler2
Public Sub Execute()
' do something else
End Sub
End Class
And they would stick this thing into session object
If someting = 1 Then
Session("Handler") = New Handler1()
Else
Session("Handler") = New Handler2()
End If
And then, to process something they would do
Session("Handler").Execute()
There we go. This is not pretty or smart. But that was instead of proper programming like this (Imagine handlers implement IHandler interface with method Execute)
Dim h As IHandler = TryCast(Session("Handler"), IHandler)
If h IsNot Nothing Then
h.Execute()
End If
Here is where downfall of late binding starts: In the case of late binding, someone, somewhere, can rename a method Execute and compile code nicely. Release. And only then, at runtime, get a problem.
Late binding was good when we used to deal with interop and COM. Other than this, it is detrimental.
I have a class call CalcArray that has an array of doubles called Amounts(), and two ints, StartPeriod and EndPeriod.
The user almost always wants to interact with the items in the array, not the Periods or the object itself. So ideally, I'd like:
property AnAmount() as CalcArray 'So the user can talk to the object if they need to
property AnAmount(i as Integer) as Double 'So the user can just get the value directly
This seems to work sometimes and not others. Is this simply a syntax issue? or is such an overload not possible?
You can do this with a function returning a different based on how it is called. Especially since you have a param, a function might be more appropriate:
Public Function AnAmount(Of T)(parm As SomeType) As T
to use it:
Dim n as Decimal
n = AnAmount(Of Decimal)(foo)
Its very useful as a way to avoid returning an object and then have to use CType to convert the return. In this case, an amount implies a value type, but the function would accept Point, Rectangle etc as T, so you might need to check valid type requests.
You may be bumping into the limitation that a function or property cannot vary by only the return type. In general if the signature has changed, the output type can change also on an overload. Look out also for the limitation for using default properties requires an argument. In some cases class inheritance is the issue, properties and functions being shadowed may explicitly be required to nominate Shadows, Overloads, Overrides etc. or the shadowing will be disallowed by the language.
If these don't cover the cases you've seen, try to catch an example of the problem and study all locations of the same named property in your solution, reporting the results here.
I remember coming across some way to declare multiple Set handlers in a property but now I can't figure out how it's done. It's useful in that one can assign different data types and the Set handler does the conversion, but I get the error
'Set' is already declared
thoughts anyone?
It's not possible
It would be nice to be able to write both
sQuantity = "1234"
and
sQuantity = 1234
with two setter functions, but trying to write even one setter function with the wrong parameter type seems doomed to failure:-
error BC31064: 'Set' parameter must have the same type as the containing property.
If Visual Basic doesn't allow conversion between setter parameter type and property type then there is no way it would be possible to have two setter functions. If setter functions are forced to have the same type as the property, then it could not know which to run if there were more than one!
So I'd argue 'not only does it not seem possible, but it is actually not possible!'
There is a workaround
What you can do however, is have two properties of different types changing the same underlying variable, so that you can write
sQuantityFromString = "1234"
and
sQuantityFromInt = 1234
using
Public Shared WriteOnly Property sQuantityFromInt () As Integer
with a setter function that takes an integer as a parameter and with both properties setter functions modifying the same underlying string member variable.
Private Shared m_sQuantity As String = Nothing
As far as I know, you cannot have multiple Set statements for a class property. A property cannot be overridden.
You can use a setter functions (this is mostly a paradigm in Java) and overload that if you need to. Then I would also suggest making the property readonly.
One other option is to have the property be defined as an Object and in the set check the TypeOf of the value being used to set the property and do whatever business logic you want. The only problem with this approach is that then your property doesn't have type checking.
I am generally not one to engage in subjective arguments over matters like variable naming, code formatting, etc. So I have no intention of starting an argument here.
I just came across this (old) blog post which recommends not prefixing member variable names:
Do not use a prefix for member
variables (_, m_, s_, etc.). If you
want to distinguish between local and
member variables you should use
"this." in C# and "Me." in VB.NET.
For C#, yeah, I get it: member variables can be lower camelCase, and public properties/methods can be PascalCase. But VB.NET is case-insensitive, so you can't really give a private member the same name as a public property except with a lower case first letter.
I've generally prefixed member variables with an underscore, but I've been told that's not idiomatic.
So really I'm just curious: how do you name your member variables in VB.NET? And is there a "standard" way?
I'm not asking because I believe there's a "right" way or because I particularly want to change my style, and certainly not because I have any desire to tell others they're "wrong." Like I said, I'm just curious.
It's personal preference, although there's widespread support for having some distinction. Even in C# I don't think there's one widely used convention.
Jeff Prosise says
As a matter of personal preference I typically prefix private fields with an underscore [in C#] ... This convention is used quite a lot in the .NET framework but it is not used throughout.
From the .NET Framework Design Guidelines 2nd Edition page 73.
Jeffrey Richter says
I make all my fields private and I prefix my instance fields with "m_" and my static fields with "s_" [in C#]
From the .NET Framework Design Guidelines 2nd Edition page 47. Anthony Moore (BCL team) also thinks using "m_" and "s_" is worth consideration, page 48.
I personally use m_ for member variables.
Although with automatic properties in VS 2010 I haven't needed to for any new code I've written recently.
I don’t like starting a line/name with an underscore since that always looks as if the line were indented by an additional space: it just makes the code unbalanced. Additionally, a lonely underscore is too inconspicuous for my taste: I prefer the identifiers to be clearly distinct.
Therefore, I periodically cycle between suffix underscore (e.g. example_) and prefix m_. I can’t decide which of those I prefer since I actually like neither. But the argument against prefix underscores partially also applies to suffix underscores.
But as you’ve remarked, some kind of distinction is necessary.
And as I’ve remarked elsewhere, I’ve had very bad experiences with case-only distinction in C# as well – it’s just too easy to confuse the names, and hence write into a private variable instead of the property. This matters if the property either checks or transforms the set value.
For that reason, I prefer to use some kind of prefix in C# as well.
I'm doing it like you.
Private _myVar as Object
Public Property MyVar() As Object
Get
Return Me._myVar
End Get
Set(ByVal value As Object)
Me._myVar = value
End Set
End Property
And in constructor
Public Sub New(myVar as object)
Me._myVar = myVar
End Sub
But I think that's a matter of taste.
The only time I use a prefix is with the private backing store for a public property. In these cases, the names are otherwise identical and most of the time the only place I'll ever reference the prefixed name is inside it's associated property. When I can finally use auto-implemented properties with VB.Net I won't even need to do that.
I do this in C# as well, on those instances when I can't just use an auto-implemented property. Better the _ prefix than varying the names only by case.
We use _ (underscore) to prefix our variables names. It's short and to the point...
Private _ID as integer
Public Property ID() As Integer
Get
Return _ID
End Get
Set(ByVal value As Integer)
_ID = value
End Set
End Property
Although a lot of the MS code seems to use m_* for private declarations, I save myself a character and just use _name for private members. My rules:
Private members are preceeded by an underscore
Public members (methods and properties) are PascalCase.
Parameters are camelCase.
Since I work in C#, having a parameter name with the same name as a property with different case is no problem. That won't work in VB, though.
In the code base I'm working in there have a method that has the signature
Public Sub SetDropDownValue(Of T As Structure)(ByVal target As ListControl, ByVal value As Nullable(Of T))
The method I am writing is passed a parameter of type object.
How can I cast the object into something that can be passed into the SetDropDownValue method?
No, you won't be able to cast a reference type as a value type (which is what the Structure constraint signified). The CLR does allow you to cast a value type as a reference type (this is known as boxing) but the nature of the difference between the implementation (and semantics) of these two different types makes the reverse impossible.
The only think you could do would be to create a value type that held a reference to your object as a field, but perhaps this problem may be a hint that you are going about the whole thing in the wrong way.
This should work if you know T:
something.SetDropDownValue(target, DirectCast(value, Nullable(Of T)))
See this article for details.
If you don't know the type T, you're in trouble and would have to start futzing around with reflection at runtime. This is complex, dangerous, and has awful performance.