Overloaded Properties in VB.NET?

I'm getting ready to finish up the marketing on a product I've recently acquired and am ready to release, but before I can, I need to ask a question. Hopefully all you intelligent developers out there can give me an answer. This question applies to VB.NET developers only. (Yes I realize the looping syntax below is in C#, the product is written in C#, the code is targeted at VBers.)

Are there any legitimate reasons to overload a property definition?

The reason for this question is that there are several bugs in the VS.NET CodeDom that create a problem for this situation, and I will try to outline them as I understand them here. Basically, if you try to loop forwards or backwards through all the members of the CodeType object, you will always get back the first position in the collection. It happens if you use either looping syntax:

  • foreach (CodeElement mem in ct.Members)
  • for (int i = 1; i <= ct.Members.Count; i++)

...Same response every time. Now, I'm not a terribly advanced coder. So, without going into details about this product (because most of the details are not final yet), I feel that we can leave it as a known issue in the current version, make it clear that we don't support this particular situation, and work with Microsoft to get it repaired in Whidbey. Personally, I don't see it as an issue, because I never overload properties. But I want to understand what others deal with, and the kinds of situations (hopefully with real-world code, not a contrived example) where this methodology would be effective. Then I can understand the needs of those that might be using the product, and decide what to do from there.

Thanks in advance.

7 Comments

  • Wow Mr Mc Laws you start to be modest person now. Amazing the change ! ' I'm not a terribly advanced coder', 'Hopefully all you intelligent developers'.

    What's up doc ?

  • LOL. Is that you, Lord? ;)



    I never said I knew a lot about more advanced coding. I'm just taking my first steps into advanced architectures (GenX.NET being the most advanced piece of code I've ever written). I know what I use properties for, and how I write code. I know that the way I code right now, I'd never need to overload a property. That'd be fine if I was the only coder on the planet. But there are coders out there that are far more advanced than me, therefore I might not be able to get by by just blaming the problem on Microsoft.



    Look, I don't mean to come off as a know-it-all. Many times, I know what I'm talking about, and confidence gets mistaken for arrogance. Part of the whole &quot;youth&quot; thing I guess. I'll be the first to admit it when I don't know what I'm talking about. So I'm asking all the people out there that know more than I do to educate me so I can make an educated decision.

  • The *VS.Net* CodeDom or the *.Net* CodeDom (ie System.CodeDom)? There's no such thing as a CodeType or a CodeElement in that namespace, which is why I ask. If it's System.CodeDom, I can't find any such bug - the following works fine for me:



    CodeTypeDeclaration someType = new CodeTypeDeclaration(&quot;SomeType&quot;);



    CodeMemberMethod foo = new CodeMemberMethod();



    foo.Name = &quot;Foo&quot;;

    foo.ReturnType = new CodeTypeReference(&quot;System.String&quot;);

    foo.Parameters.Add( new CodeParameterDeclarationExpression(&quot;System.String&quot;, &quot;foo&quot;) );

    foo.Statements.Add( new CodeMethodReturnStatement( new CodeArgumentReferenceExpression(&quot;foo&quot;) ) );



    CodeMemberMethod bar = new CodeMemberMethod();



    bar.Name = &quot;Bar&quot;;

    bar.ReturnType = new CodeTypeReference(&quot;System.String&quot;);

    bar.Parameters.Add( new CodeParameterDeclarationExpression(&quot;System.Int32&quot;, &quot;bar&quot;) );

    bar.Statements.Add( new CodeMethodReturnStatement( new CodeArgumentReferenceExpression(&quot;bar&quot;) ) );



    someType.Members.Add(foo);

    someType.Members.Add(bar);



    foreach(CodeTypeMember member in someType.Members)

    {

    Console.WriteLine(member.Name);

    }



    Aside from that, one good reason I can think of for the need to overload members is to avoid the versioning problems of optional parameters (which are resolved at compile-time rather than at run-time).



    Jim

  • I'm talking about overloading properties. For example:



    Public Overloads ReadOnly Property Color As String...



    Public Overloads ReadOnly Property Color As String...



    It looks to me like the problem exists when you're trying to read existing code, not create new code. I'll see if I can get someone to clarify for me.

  • Ah, are you *shadowing* properties? Overriding a member from a base class with the same name/return type/parameters? In which case, the CodeDom will probably only return members declared *on the type you are enumerating*, and not on any base types. You'll probably have to travel the inheritance hierarchy to find all overridden members.



    Jim

  • This is a sample of the overloaded property that is not handled correctly by EnvDTE.CodeElements



    Default Public Overloads ReadOnly Property Item(ByVal Index As Integer) As Room

    Get

    End Get

    End Property



    Default Public Overloads ReadOnly Property Item(ByVal Key As String) As Room

    Get



    End Get

    End Property

  • When you perform a foreach (EnvDTE.CodeElement element in Elements)



    The first overloaded Property is returned for each instance of the property.



    Another words, the count is 2 but each of the EnvDTE.Elements returned in the loop are the first item, the second + item is never returned.



    Joe

Comments have been disabled for this content.