Hi, If you have been following trunk very recently you probably know. The Hash class now has a new implementation. So far I'm happy with the changes that are in trunk, and here are the details. - The Hash class is still a subclass of NSMutableDictionary. - All the Hash methods are not defined on Hash anymore, but on NSDictionary instead. The methods have been re-implemented to use the CF APIs. It means that you can for example call #has_key? on all dictionaries, created by Ruby (via the Hash class) or by Objective-C (as a NSCFDictionary object). Trying to call a method that will change the dictionary on an immutable dictionary will raise an exception ("can't modify immutable hash"). - To implement the semantics of the previous Hash class (such as the possibility to freeze it, or specify an "if none" value/proc), MacRuby allocates at demand a data structure and uses a feature of the Objective-C GC to associate/attach it to the dictionary. Once the dictionary is collected, the data structure is also collected at the same time (w00t!). So far, with these changes, MacRuby builds (yeepee!) and most of the tests in test/ruby/test_hash.rb are passing. Things that are not working yet: - Tainting objects. We need to attach the taint flag in the attached structure (like we do with the frozen state). - Passing a false value. Qfalse is 0 in Ruby core, and apparently CFDictionary (via CFDictionaryGetValueIfPresent) has some problems to remove it (though lookups are working). This should anyway be addressed once "false" is something different than 0 in the core. - Hash#compare_by_identity. Supporting that wouldn't be hard by calling some private APIs in CFDictionary. We can now start replacing Array. I proposed on ruby-core to deprecate RARRAY_PTR for element access, which we won't be able to efficiently support. Nobu-san proposed RARRAY_AT() which should work for us. Also, Ben and I have been brainstorming on Monday about future changes, and here is what we decided: http://trac.macosforge.org/projects/ruby/wiki/MacRubyBrainstorming Laurent
On Mar 19, 2008, at 2:50 PM, Laurent Sansonetti wrote:
Also, Ben and I have been brainstorming on Monday about future changes, and here is what we decided:
http://trac.macosforge.org/projects/ruby/wiki/MacRubyBrainstorming
These seem to all be Hash class related. Is there something which encompasses more of the big-picture brainstorming for MacRuby as a whole? Thanks, - Jordan
Also, Ben and I have been brainstorming on Monday about future changes, and here is what we decided:
http://trac.macosforge.org/projects/ruby/wiki/MacRubyBrainstorming
These seem to all be Hash class related. Is there something which encompasses more of the big-picture brainstorming for MacRuby as a whole?
There are a few other high-level directions in there, regarding Number, Symbol, Nil/False/TrueClass, and Object. Laurent, I guess you need to dump the rest of your brain there, though… -Ben
On Mar 19, 2008, at 3:36 PM, Benjamin Stiglitz wrote:
Also, Ben and I have been brainstorming on Monday about future changes, and here is what we decided:
http://trac.macosforge.org/projects/ruby/wiki/MacRubyBrainstorming
These seem to all be Hash class related. Is there something which encompasses more of the big-picture brainstorming for MacRuby as a whole?
There are a few other high-level directions in there, regarding Number, Symbol, Nil/False/TrueClass, and Object. Laurent, I guess you need to dump the rest of your brain there, though…
In fact these are already part of the braindump I think :) But it's not relatively intuitive I admit.
Hash primitives should rb_funcall if the receiver is a subclass of Hash.
So that you can subclass Hash, override #[], and CFDictionary/ NSDictionary APIs should call your own implementation instead. (Same for Array and String.)
Freezing an object should store a flag that should be checked in the primitive methods and appropriately raise an exception.
So that when Objective-C tries to modify a Hash that was frozen in Ruby, an exception would be raised in the Objective-C side. (Same for Array and String.)
Symbols should be objects (flagged String) as they are actually represented in parse.y, and passed as they are in Objective-C. Incoming symbol objects should be recognized by the flag.
Currently in the core, symbols are pointer-like types and not real objects. The idea is to use a real object class instead (based on String), so that it can be passed to Objective-C without conversion.
All Ruby integers should be NSNumbers. Bignum is a custom subclass of NSNumber which implements the primitive methods. MacRuby should unique most numbers.
As symbols, fixnums in the core are not real objects but pointer-like types. The idea is to use CFNumbers instead and unique most of them (if not all?). Float and Bignum would be subclasses of CFNumber too, and incoming pure CFNumbers would be appropriately identified as Float by looking at the type.
Should we change the way Qtrue/Qfalse/Qnil are represented?
That's a pending issue. Qtrue, Qfalse and Qnil in the core are magic constants (respectively 2, 0 and 3). We cannot simply pass them to Objective-C as objects. Laurent
participants (3)
-
Benjamin Stiglitz
-
Jordan K. Hubbard
-
Laurent Sansonetti