From: ara.t.howard@... Date: 2007-01-05T00:05:49+09:00 Subject: Re: Little Things On Thu, 4 Jan 2007 dblack@wobblini.net wrote: > Hi -- > > On Thu, 4 Jan 2007, ara.t.howard@noaa.gov wrote: > >> On Thu, 4 Jan 2007, Rob Sanheim wrote: >> >>> I bet once they saw "send!" in the docs or in irb they would >>> immediately know how it works. Its aligns perfectly with many other >>> things in the std lib, and fits perfectly with POLS. >> >> agreed. >> >>> As for protecting from people overriding it, I think having the >>> underscore forms is enough. YSYEO ("You'll shoot your eye out.") I'm >>> sure there are programs were object_id and other meta-methods are >>> overridden. All you can do is warn people against doing it, test your >>> code, and of course choose libraries that behave well. >> >> alternatively, it can be externalized so no matter how hard you muck about >> with objects you cannot break certain unalienable behvaiours we desire them >> to >> have. > > Do you really think no one will ever do: > > def Pervasives.send > # ... > end > > ? :-) yes. the Pervasives module would be designed at the C level to prevent modification, if you read my initial post you'll see that's it's entire purpose: harp:~ > cat a.rb class Pervasives freeze class << self freeze end end class Pervasives def self.send end end harp:~ > ruby a.rb a.rb:9: can't modify frozen object (TypeError) i know this can be subverted, but it can be done at the C level. the point is to have a single object responsible for maintaining and retrieving certain unalterable traits of objects. this can either be done somehow for every object or for one object. i prefer the one object approach because it streamlines the api: you don't have to remember send! vs. send or object_eval vs instance_eval, you use the Pervasives handle with the normal method to cut straight to the heart of of any object. regards. -a -- in the practice of tolerance, one's enemy is the best teacher. - the dalai lama