i.e., is Ruby's Set equivalent to Java's LinkedHashSet?
In Ruby 1.9: yes. In Ruby 1.8: probably not.
Set uses a Hash internally; and since hashes are insertion-ordered in 1.9, you're good to go!
As mu is too short points out, this is an implementation detail and could change in the future (though unlikely). Thankfully, the current implementation of Set is pure ruby, and could be adapted into an OrderedSet in the future if you like
Related
Trying to get the aerospike ruby client to work under 1.8
What is the equivalent of these calls in ruby 1.8 ?
https://github.com/aerospike/aerospike-client-ruby/blob/master/lib/aerospike/utils/buffer.rb#L65
https://github.com/aerospike/aerospike-client-ruby/blob/master/lib/aerospike/utils/buffer.rb#L95
IIRC, Ruby 1.8 strings are, for all intents and purposes, what 1.9 would treat as ASCII-8BIT. As such, String#[] and String#[]= are the way to proceed as already suggested in the comments. (The same functions in 1.9 will target a potentially multibyte character at a certain offset, rather than a byte.)
For a more complete discussion on Ruby M17N and how strings changed in Ruby 1.9, see:
http://yokolet.blogspot.com/2009/07/design-and-implementation-of-ruby-m17n.html
http://yehudakatz.com/2010/05/05/ruby-1-9-encodings-a-primer-and-the-solution-for-rails/
Rather than rely on how a particular version of Ruby processes bytes/chars/strings, instead use the pack and unpack methods. They are always available and behave consistently.
For your use, unpack the data into an array, then you can use normal Array slicing to change the bytes in question, then pack everything back into the byte-stream.
In Ruby 1.9 I would use String#match(regexp,start_index). I'm sure there must be a (computationally efficient) equivalent in Ruby 1.8, but I can't find it. Do you know what it is?
You could start the regexp with ^.{start_index}
or take the substring first before performing the match.
Alternatively, if you're constrained to using Ruby 1.8, but can install your own libraries then you could use Oniguruma.
As far as I can tell, there is no efficient way to match a Regexp against a large string, starting from an arbitrary index, in pure Ruby 1.8.
This seems like a major flaw. I guess the moral of the story is: use Ruby 1.9!
I have an array of custom classes. I've defined <=> on them, and have tested to make sure that my custom definition behaves as it should. I assumed that I could then call [].uniq and have it filter out my duplicates, but that isn't happening. Is there another operator I need to overload?
Array#uniq is based on equality, not on ordering, so your objects need to respond to eql?. Also, it uses hashing to speed up performance, so you need to implement hash as well.
Unfortunately, this contract isn't specified in the documentation, but it usually is specified in pretty much every Ruby book or course.
What I needed to implement, was .hash
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the difference between Ruby 1.8 and Ruby 1.9
I have found some differences in interpretation of global and local variables.
Can anyone point me to list of major differences?
These are probably the most important changes:
Ruby 1.9 changed from being
interpreted to being
bytecode-compiled (using the YARV
VM).
The String class has been redesigned
entirely to make it encoding-aware.
Regular expressions are now
implemented using the Oniguruma
engine, rather than the home-made one
used in ruby 1.8, enabling new
features like negative look-around.
The enumerator library from stdlib
has been added to core and most
Enumerable methods have been
changed to return an Enumerator
when invoked without a block.
Symbol#to_proc has been added.
There's a new syntax for lambdas,
-> which allows default arguments
and lambdas taking blocks.
There's a more complete list of changes here.
One major point might be that they use a different VM (at least, the 'standard' distributions do, obviously there are a number of options like MacRuby, IronRuby, etc). You might have a look here for details on all the changes.
Is the value returned by ruby's #hash the same across interpreter instances?
For example, if I do "some string".hash, will I always get the same number even if run in different instances of the interpreter? If so, is this also true for all the builtin types (e.g. Hash, FixNum, etc).
Not the same in different instances, at least with Ruby 1.9.1.
This link gives some further info...
It seems that they changed hash algorithm in 1.9 to a random seed-based one...
If you want to do something that you know will be the same across versions and objects try md5 or sha1.
require 'digest/md5'
Digest::MD5.hexdigest('some string')