As a followup, Refinements are derivative of ClassBoxes which for several year's was an area of focus within Oscar Nierstrasz's research group at the University of Bern. http://scg.unibe.ch/research/classboxes/ They started with Smalltalk and then went on to Java and C# implementations. They have a considerable publication record on the subject http://scg.unibe.ch/scgbib?query=classbox
The presentation deck that places Ruby Refnements into to context with classboxes is http://www.slideshare.net/ShugoMaeda/rc2010-refinements On Mar 21, 2011, at 3:07 PM, Andrew Dupont wrote: > Erik, > > Yes, this is exactly what a framework like Prototype would need. Your code is > highly reminiscent of Ruby's proposed "refinements" feature [1], one which is > being debated for inclusion in Ruby 2.0. If this could be implemented in a > way that avoids the dreaded namespace dragons, then I would lobby hard for a > feature like this. > > Cheers, > Andrew > > [1] http://timelessrepo.com/refinements-in-ruby > > > On Mar 21, 2011, at 3:13 PM, Erik Arvidsson wrote: > >> The thread about using private names is getting a bit unwieldy but I'd >> like to focus on the use case that I have been thinking of as >> "Lexically scoped monkey patching" or "Lexically scoped object >> extensions" instead of focusing on how to use "private names" to fit >> this scenario. >> >> Extending built ins and modifying existing classes to work around bugs >> or to provide a better API is (or was) a common pattern. Today a lot >> of JS library shun this approach due to the risk of conflicts. >> >> Let us assume that you could extend an object in your current lexical >> scope and that such extensions could be imported from a module into >> your current scope. >> >> Given: >> >> { >> function largerThanN(obj, n) { >> return obj.filter(function(item) { >> return item > n; >> } >> } >> >> var a = [0, 1, 2, 3, 4]; >> print(largerThanN(a, 2)); >> } >> >> Now we would like to make largerThanN to work with Object objects. The >> naïve thing to do is to just to add a filter method to >> Object.prototype. However, this might cause conflicts with other code >> that uses objects. The idea here is that we can do this safely in our >> scope (ignore syntax except that it is important that it can be done >> statically). >> >> { >> extend Object.prototype with { >> filter: function(fun) { >> var retval = {}; >> for (var key in this) { >> if (fun(this[key]) >> retval[key] = this[key]; >> } >> return retval; >> } >> }; >> >> function largerThanN(obj, n) { >> return obj.filter(function(item) { >> return item > n; >> } >> } >> >> var a = [0, 1, 2, 3, 4]; >> print(largerThanN(a, 2)); >> var o = {a: 0, b: 1, c: 2, d: 3, e: 4}; >> print(largerThanN(0, 2)); >> } >> >> The above use case cannot be solved using private names because >> private names conflict with public names. >> >> Can we agree that this is a use case that we care about and focus on >> this instead of whether private names can or cannot do this? >> >> -- >> erik >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
