I'm no VBA coder so just a few minor things:

1. Is there a particular reason to useByRef for the parameter toTransformIndex? It doesn't seem exactly necessary and I usually prefer methods without side effects.

2. collec reads clumsy. I would rename it to something likeunderlying orunderlyingCollection.

3. You should take a bit more care naming method parameters. Parameter names form an important part of the method documentation and should convey their intent clearly. For example here it is not exactly clear whata andb mean:

   Public Sub Clear(ByVal a As Long, ByVal b As Long)

4. ForClear it is not entirely clear if for example the end index is included or not for the removal. C# usually follows the convention of specify the start index and the count of how many elements should be removed (i.e.Clear(start, count)). I found that approach more robust in the long run.

5. I don't think dumping the entire list content inToString() is all that useful, especially if the list can grow larger it could be problematic.

• \$\begingroup\$My rational for usingByRef forTransformIndex was that the alternative was to make it a function, but then it would look likeindex = TransformIndex(index), which seems redundant. Otherwise great points, especiallyClear(start, count).\$\endgroup\$

  cheezsteak

  – cheezsteak

  2014-09-16 13:49:46 +00:00

  CommentedSep 16, 2014 at 13:49

Only a a couple of minor notes. It looks pretty good (but admittedly, I've not run the code).

1. Single letter argument names obfuscate their meaning.

   Public Property Get Slice(ByVal a As Long, ByVal b As Long, Optional ByVal s As Long = 1) As List

2. I find it a little odd to initialize a bool to true, then set it to false if the code doesn't exit early. I would rewrite yourExists method just a little bit.

   Public Function Exists(ByVal sought As Variant) As Boolean    Dim element As Variant    For Each element In collec        If element = sought Then             Exists = True            Exit Function        End If    Next element    Exists = FalseEnd Function

   It's semantically the same, but the intent is a little clearer IMO.

In addition to what was already said, I'll add these points:

Public Sub Extend(ByVal sequence As Variant)    Dim element As Variant    For Each element In sequence        collec.Add element    Next elementEnd Sub

Here the only clue the calling code has about the expected type, is the parameter's name (sequence) - that reinforces what was already said about meaningful parameter names, but I find the way you've implemented this forces the client to add boilerplate code just to be able to pass values to this method.

A much more convenient (and self-documenting) way of taking in an arbitrary number of parameters, is to use aParamArray, and iterate its indices instead:

Public Sub Extend(ParamArray items())    Dim i As Integer    For i LBound(items) To UBound(items)        collec.Add items(i)    NextEnd Sub

That way the client code can do this:

Dim myList As New ListmyList.Extend 12, 23, 34, 45, 56, 67, "bob", 98.99

Notice a VBACollection doesn't enforce any kind of type safety, so the item at index 1 could be aString while the item at index 2 could be aDouble, or even anObject of any given type.

I know nothing ofpython, so maybe that isn't an issue, but if your list is meant to only contain one type of items, you have a problem here.

Speaking of which:

Public Property Get ToString() As String    ToString = "[" & Join(seq.ToArray(collec), ", ") & "]"End Property

I don't seeseq.ToArray anywhere, but whatever it's doing, it's not accounting for the fact that yourList can takeObject items, and doing that would break yourToString implementation, while every other method would seemingly work as expected. You should verify whether an itemIsObject before attempting to do something with it that wouldn't work on an object.

You might have seenthis post, where I solved these issues in a .net-typeList<T> (although myToString doesn't list the contents).

• \$\begingroup\$I don't see howParamArray is a functional solution. It prevents the client from extending aList with anotherList or any other iterable. The only benefit is the syntactic sugar for initialization of not wrapping the args inArray(. -- Also aTypedList would be a subclass.\$\endgroup\$

  cheezsteak

  – cheezsteak

  2014-09-16 14:05:40 +00:00

  CommentedSep 16, 2014 at 14:05
• \$\begingroup\$...and an unambiguous function signature: itdocuments that you're expecting more than one value. Taking in aVariant says nothing, you're relying on the user's knowledge thatExtend should take an array of values, and you're not validating whether the parameter's type is actually an array. This is VBA, aVariant could beanything. I've been using a similarList class for quite a while now, and for me at least, thesyntactic sugar has been much more valuable than thepossibility for hypothetical eventual extensibility.\$\endgroup\$

  Mathieu Guindon

  – Mathieu Guindon

  2014-09-16 14:18:07 +00:00

  CommentedSep 16, 2014 at 14:18
• 1
  \$\begingroup\$I disagree that it's an unneeded functionality. Otherwise you have no way of dynamically initializing or concatenating Lists other than writing for each loops everywhere.\$\endgroup\$

  cheezsteak

  – cheezsteak

  2014-09-16 14:56:19 +00:00

  CommentedSep 16, 2014 at 14:56
• \$\begingroup\$How about dealing with objects? Multiple types in wrapped collection? Let it blow up as well?\$\endgroup\$

  Mathieu Guindon

  – Mathieu Guindon

  2014-09-16 14:58:16 +00:00

  CommentedSep 16, 2014 at 14:58
• \$\begingroup\$lets take it to second monitor. I agree thatsequence should be declared as something more descriptive thanVariant but I would want it to beIterable which doesn't exist in VBA. And I am willing to take that hit for the dynamic.\$\endgroup\$

  cheezsteak

  – cheezsteak

  2014-09-16 16:14:21 +00:00

  CommentedSep 16, 2014 at 16:14

• vba