Array to List conversion

[_Gold_Fish]

I've noticed that the way to convert an object from an Array to a List is via the .toList method. It seems to me that it would make more sense if it was done via to "to" keyword, so that instead of:

list = foo.toList

it would be

list = foo to List

or

list = foo to List<of *>

Is there any particular reason that this is not the case?

[hopscc]

I'll take a stab.

Probably cos 'to' was chosen in cobra to act as the 'casting' operator ( from VB ?) to retype an object to something else up or down its inheritance or implementation hierarchy.

Personally I wouldnt say its advantageous to provide a language construct/operator to provide a mapping to a public library class conversion method unless you want to mask the Library access in some way especially given that language evolution has tended to be in the opposite direction (toward providing such capability via libraries directly rather than language builtins/RunTime Support systems)
and the range of possible conversions is arbitrarily large while the range of valid conversions is bounded.

Code: Select all

# Invented examples and syntax...

a = foo to Window
# Cannot convert foo which is Type Array (of ?) to Type Window
a = foo to CheeseBurgaz
# Cannot convert foo which is Type Array (of ?) to Type CheeseBurgaz

a = foo to List


Note that you can get something close to your conversion (array to List) using a cast from an array to an IList (interface) since an array implements IList (directly or indirectly)

Code: Select all

an = @[10,20,30]   # array
al = an to Collections.IList
for item in al
   print item


[Charles]

Hops is correct. In general, "obj.toFoo" is making a new Foo object from the contents of "obj". Another example is .NET's own "obj.toString".

"obj to Type" is a typecast which generally does not change "obj" and will throw an exception if "obj" is not already compatible with "Type" at run-time. There is a "to?" operator if you would prefer nil instead of such an exception.

But a notable exception to the above rules are numeric casts like "someInt to decimal" and "someInt32 to int64" which do in fact produce new values. This was basically inherited from .NET and other languages although I wonder why it shouldn't have been "someInt.toDecimal" and "someInt32.toInt64". Under the hood of the VM, I think a numeric cast must be radically different than the other casts.

[hopscc]

Yeah - It falls back to casting just like pre OO languages... 1/2

[_Gold_Fish]

Ok, thanks for the clear-up!