String to array

[Yuuta Kirishima]

I request the help of this community on how to properly convert a string into an array, A bunch of confusing code that ultimately returns a variable named team from the server, inside this team variable is the value: 


"[9, 27, 32, 112, 4]"


I need this turned into the array


[9, 27, 32, 112, 4]


I've tried the following:


aTeam = team.tr('[]', '')
vTeam = aTeam.split


did not work, Ruby must have inherently included quotes or something.


Any help would be greatly appreciated

 

[??????]

def stringToArray(aString)
  return aString.tr('[]','').split(',').map{|e|e.to_i}
end

print stringToArray("[9, 27, 32, 112, 4]");

 

[Hudell]

JSON.parse('[9, 27, 32, 112, 4]');

 

[??????]

@Hudell Ruby bro

 

[Hudell]

@Hudell Ruby bro

Ooops

 

[Yuuta Kirishima]

def stringToArray(aString)
return aString.tr('[]','').split(',').map{|e|e.to_i}
end

print stringToArray("[9, 27, 32, 112, 4]");

Lovely! You just saved a stressful battle system

 

[Adventurer_inc.]

Ultimately, you could just eval() since ruby is a OOP. Same applies Javascript in MV as JS is also OOP.


https://rubymonk.com/learning/books/5-metaprogramming-ruby-ascent/chapters/24-eval/lessons/63-eval

aTeam = eval('[9, 27, 32, 112, 4]')
return aTeam[2] # this returns 32

 

[Yuuta Kirishima]

Ultimately, you could just eval() since ruby is a OOP. Same applies Javascript in MV as JS is also OOP.


https://rubymonk.com/learning/books/5-metaprogramming-ruby-ascent/chapters/24-eval/lessons/63-eval



aTeam = eval('[9, 27, 32, 112, 4]')
return aTeam[2] # this returns 32

I thought about something like this but the array is not stored locally and it would just take too much

 

[Sixth]

Why not simply use:


def string_to_array(string)
ary = []
string.scan(/\d+/).each {|num| ary << num.to_i}
return ary
end


You just need the numbers from the string, right? This seems much more simpler than using .tr than .split and than .map to get the numbers.


This will, of course, only work if the string you have can only contain needed numbers, and not some irrelevant numbers which you don't need in your array.

 

[??????]

That's unnecessarily lengthy.. Could easily shorten it...


def stringToArray(aString)
return aString.scan(/\d+/).reduce([]){|r,i|r<<i.to_i}
end



I don't think that would make much difference over my previously suggested solution though.


Edit:


Also, eval should never be used when there is a more elegant solution available.

 

[Zeriab]

Of the solutions presented here I find the eval the most elegant solution, but at the same time it is clearly the worst.


As Yuuta mentions, the data comes from a server. I.e. the string is tainted. Never ever evaluate tainted strings. This is a far bigger reason than any other for not using the eval solution.



@Dekita


I disagree.  I consider your revision unnecessarily convoluted. Sixth's code clearly communicates what it does. The variable naming reflects what they represent. All of this is small stuff, I know. It's just, I consider going from your version to Sixth's version a good refactoring.


The difference between the two good solutions is quite interesting. The solution by Dekita focuses tearing and splitting according to the specific way the values are packaged, parsing the resulting clumps of strings as integers. The solution by Sixth focuses on the consecutive groups of digits parses the integers without regards to how the values have been packaged. There are pros and cons with each solutions. Removing and adding suffixes and prefixes, altering separation characters. This affects one solution, not another.


The digit scan is more robust to changes in the surrounding chars while the requirement of integers separated by any chars exists. Adding decimals? And the other solution works without changes.


Want to add nesting? Again one solution is easier to modify than the other.


Interesting, right? :3

 

[??????]

@Zeriab I just spent the best part of an hour pondering the implications of this, then I remembered I have actual things to do


Side note: I always enjoyed ruby for how easy it is to have all the logic contained on one line, not sure why, but yea..

 

[Tsukihime]

@Zeriab I just spent the best part of an hour pondering the implications of this, then I remembered I have actual things to do


Side note: I always enjoyed ruby for how easy it is to have all the logic contained on one line, not sure why, but yea..

It's also enjoyable to read other people's code golf. Hopefully I never have to modify such code since I don't want to spend an hour wondering what it's actually supposed to do.


The only reason why I might choose not to write out the logic myself is if the engine can perform optimizations to speed up the operation, as opposed to me manually parsing and building up the data myself.