On Sat, Aug 18, 2012 at 9:13 PM, Denis Leclair <[email protected]> wrote: > Christopher Dicely wrote in post #1072759: >> In a sense what you are asking for is self-contradictory in Ruby -- a >> class is >> an object (an instance of class Class), and its a different object than >> its own >> instances. So, when you take a method out of the public interface to >> hide it >> from "external" code, you are hiding it from class methods because they >> are >> external code as much as any other method that isn't part of the >> instance is. > > I disagree that this is self-contradictory in Ruby. I understand that > they've gone with the "a class is an object" model and that certainly > brings a lot of nice characteristics to the language. But that, in and > of itself, does not require that class methods be treated as "external > code" from the perspective of the class object.
It (i.e. the class) is external from the perspective of the instance. The instance should be responsible for maintaining its own affairs. > There is still a very strong association between the class method and > the class object that it is bound to so there's no technical reason why > the class method couldn't be given more access privileges than other > non-associated code. It must have been a deliberate decision to set it > up this way and I'm trying to get an appreciation for why that decision > would have been made. Even if it is technically feasible it will add additional complexity and it may make things actually unnecessary complex - especially if you start thinking about how super and sub classes should be handled in this case. Current checks are simpler because "self" is the only instance which is allowed to invoke protected methods and private methods must only be invoked without explicit receiver. > Then again, maybe there is a technical reason why those privileges > couldn't be given and I'm just not seeing it. Since I am not Matz I cannot answer this definitively. My assumption of possible reasons - encapsulation at the object level, since class != any of its instances it is external to the object and giving it privileged access will break that rule (you then could also ask for instance.@foo = 123, i.e. easy access to instance variables - added complexity (cost in development, maintenance, runtime performance) - there is a solution (use #send) - too low benefit given items above I think Matz just did not want to encourage people writing code manipulating an instance in other classes. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ -- You received this message because you are subscribed to the Google Groups ruby-talk-google group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at https://groups.google.com/d/forum/ruby-talk-google?hl=en
