“split.FromArray(”,“)” is effectively saying Array.FromArray(), which has no way of indicating what the output type would be.
String.FromArray() tells you exactly what you get back. After all you could have other type of output, for example Dictionary.FromArray() could be produced ( I know it doesn’t exist ).
i want this and in case its a object it have to use a ToString Method Interface
dim data as Array = ("One", "Two", "Three", yourobject)
dim joined as string = data.Join(",") or data.ToString(",") or data.FromArray(",")
dim data2 As Array = joined.Split(",") or joined.ToArray(",")
FromArray only ever returns a string and is a method that only takes string arrays.
That’s why it confuses me. I suppose it could return a variant otherwise, but in reality the concept of joining an array really only applies to strings.
Public Function Join(extends stringArray() As String, delimiter As String = ",") As String
Return String.FromArray(stringArray, delimiter)
End Function
I know that’s what exists today, but others could exist in the future. Even your own classes. Having Classname.FromArray() tests you about the return type.
Yes, but for code readability point of view, Array.FromArray doesn’t tell you anything. Where as String.FromArray tells you exactly what is happening you are generating a string from an array. It is part of the String class. Array.Join is all well and good but it really only applies to a String array, what would should it do if it was an Integer array, for example.
Var str1() As String // This type contains the method Join(), should autocomplete
Var int1() As Integer // This type does not contain the method Join(), should not autocomplete
x = str1.Join() // ok
y = int1.Join() // Compiler error Integer array int1.Join() method does not exist
I could easily be wrong, but I think the issue with this is that the Xojo compiler has an Array type that represents all arrays, no matter what is stored inside them. The Array implementation probably has a internal property that identifies the type of the contents but that has nothing to do with the Array object’s class as far as the type system is concerned, and thus it doesn’t support the kind of content type-specific functionality you are describing.
That said - I sorely wish it did. I’ve had plenty of situations over the years where I wish that arrays could be subclassed based on their content type.
That would be a design flaw, so I guess you are wrong.
Var str1() As String
str1.Add 123 // Should fire a compiler error because Xojo knows this is an array of strings
My example above where I do extend an Array of Strings does exactly that
str1.Join() // works, exists
int1.Join() // causes an invalid method compiler error
A Join extension method on an array of strings absolutely works. When API2 was in beta, I proposed this exact thing. String.FromArray(someArray, "separator") was, for some unknown reason, selected over someArray.Join("separator"). Even calling it ToString would have been ok. But I was ignored.
While we’re on the subject, there is zero reason why the separator should be optional. Optional parameters are great when there is a logical default. Joining or splitting an array has no obvious default.
