Variable initialization

[gavio]

This is somewhat a theoretical question.

I had this:

Private _oFields As ListEx(Of FieldStruct) = New List(Of FieldStruct)

ListEx is my "extension" for List. How can this compile really? It's true that ListEx inherits from List, but still. Should it compile or do I have some wrong settings?

It took me like two hours to find this...

[techgnome]

it should compile... no reason it shouldn't. you're taking something generic (List) and putting it into something more specific (ListEx) ... it'll fit just fine... what you CAN'T do (or more to the point, what you SHOULDN'T do) is put something more specific into something generic.


Think of it like this - List is like Form... it's generic and somewhat meaningless on its own. ListEx is like Form1 ... a Form that has had some customization to it, tasking it for a specific purpose. It's still a Form under the hood though. Your ListEx is still a List underneath, so what you've done there is perfectly valid. May not be right but it's valid.

Is there any reason you just didn't do it like this:?

Private _oFields As New ListEx(Of FieldStruct)

-tg

[gavio]

In my case, ListEx still is completely generic. I just like to redefine most of system classes I use in case I need to extend theme later. I KNOW I shouldn't put something specific into something generic, that's why ListEx is only but this more then List:

Public Sub New()
  ' Empty constructor.
End Sub

Public Sub New(ByVal oFirstItem As T)
  Me.Add(oFirstItem)
End Sub

This is for the purpose of creating an object of ListEx "on the fly" (e.g.: for a parameter), where you only need one item quickly.

I've heard about extensions, but didn't find the time to dig more into theme. Perhaps another time.

Anyhow, a little bit off topic...

I still don't think what I've done (and compiler let me) is valid. Type is a type, except in case of interfaces.

Is there any reason you just didn't do it like this:?

Private _oFields As New ListEx(Of FieldStruct)

No reason really. Just a VB6 legacy

[jmcilhinney]

Your code will compile with Option Strict Off but it will fail at run time. With Option Strict On (as it should always be) it will refuse to compile.

If you derive the ListEx class from the List class then you can assign a ListEx object to a List variable because every ListEx is a List. You can't assign a List object to a ListEx variable though, because not every List is a ListEx. As is always the case with OOP, just look at the real world for examples. Every Dog is an Animal so you can assign a Dog object to an Animal variable but you can;t assign an Animal to a Dog variable because it's not necessarily a Dog.

Quite frankly, this:

I just like to redefine most of system classes I use in case I need to extend theme later.

is silly. If you need to extend them later then extend them later. Why put wings on your car just in case you might want to fly later? Put the wings on if and when you want to fly. A far more sensible approach would be to simply create a helper class, e.g.

Public Class ListHelper
 
    Public Shared Function Create(Of T)(ParamArray items As T()) As List(Of T)
        Dim list As New List(Of T)
 
        list.AddRange(items)
 
        Return list
    End Function
 
End Class

Now you are still going to be dealing with vanilla List objects.

[formlesstree4]

Alternately, a List could be initialized with an array [or it can in VS2010, not sure about VS2008]:

Dim _array() As String = {"dog", "cat", "fish"}
Dim _list As New List(Of String)(_array)