Re: [MacRuby-devel] book idea - "making it look like Ruby"
On Fri, Feb 11, 2011 at 4:08 PM, Rich Morin wrote: > At 6:09 PM -0200 2/11/11, Caio Chassot wrote: >> On 2011-02-11, at 15:25 , Matt Aimonetti wrote: >>> >>> Magically converting a snake_case method call to a >>> CamelCase method dispatch is bad for peformance >>> and documentation. > > It's not clear to me that there would be a significant > performance impact. It might be possible to do (most > of) the translations at start-up time, avoiding much > impact during execution. In JRuby it currently has no performance impact. The camel_cased versions are defined as aliases to the original. I forget whether we define them as traditional aliases (wrapped by another structure) or if we just bind the same method object under all names. We have also debated making the aliases *redispatch* so that if you wanted to replace them all you'd just replace the original camelCased version. That turned out to be a perf issue in practice, so we backed it off until we can come up with a nice way to have multiple names resolve to the same method object. FWIW, JRuby users would go ape if we took away snake_cased versions of Java names. They love having everything look like Ruby, and I personally think it helps the code flow a lot more naturally to have a single style...not to mention you don't have to remember whether you're calling a snake_cased or camelCased method...you just always use snake_case. > The question of documentation is also somewhat iffy. > There is already a difference in appearance between > the ObjC and MacRuby calling syntaxes. Would merely > allowing (ie, not requiring) the use of snake_case > make this much problem much worse? As far as I know, there's never been any confusion about snake_cased aliases in JRuby. People read the JavaDocs, mentally switch to snake_case, and proceed. - Charlie ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] WeakRef advice
Another important use of weakrefs came to mind: avoiding finalization. In general, finalizers are a bad idea. They often block GC, or at least block each other. They add overhead to GC cycles, since either finalizers must be run or objects must be enqueued for another thread to run their finalizers. By using WeakReferences (and especially PhantomReferences) you can drive finalization from userland code, avoiding much of the GC overhead that might otherwise result. - Charlie On Fri, Feb 18, 2011 at 5:28 PM, Charles Oliver Nutter wrote: > On Tue, Feb 15, 2011 at 5:28 PM, Laurent Sansonetti > wrote: >> Hi Alan, >> Do you control the data structure that holds a reference to 'B'? If yes, you >> may want to use NSHashTable which supports weak references. >> To me, this sounds like a design problem. Maybe your project can be >> re-architectured to avoid this pattern. > > Weak references and weak lists/hashes are often very useful for caches > you need to age out or when you need to associate data with a given > instance of an object without holding hard references. Using weak > references is definitely not a design problem in itself. > > I'm also disappointed that you'd recommend people use NSHashTable > rather than just fixing WeakRef :) In JRuby, we nuked weakref.rb some > time ago because it has a lot of problems. Instead, we wrap the JVM's > builtin weakrefs. > > See also the weakling gem, which (for JRuby) provides additional > features mentioned in that Ruby redmine ticket like reference queues > and a simple weak ID hash to use in place of _id2ref. > > - Charlie > ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] WeakRef advice
On Tue, Feb 15, 2011 at 5:28 PM, Laurent Sansonetti wrote: > Hi Alan, > Do you control the data structure that holds a reference to 'B'? If yes, you > may want to use NSHashTable which supports weak references. > To me, this sounds like a design problem. Maybe your project can be > re-architectured to avoid this pattern. Weak references and weak lists/hashes are often very useful for caches you need to age out or when you need to associate data with a given instance of an object without holding hard references. Using weak references is definitely not a design problem in itself. I'm also disappointed that you'd recommend people use NSHashTable rather than just fixing WeakRef :) In JRuby, we nuked weakref.rb some time ago because it has a lot of problems. Instead, we wrap the JVM's builtin weakrefs. See also the weakling gem, which (for JRuby) provides additional features mentioned in that Ruby redmine ticket like reference queues and a simple weak ID hash to use in place of _id2ref. - Charlie ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
