From: Igor Pirnovar Date: 2009-02-11T22:23:23+09:00 Subject: Re: Ruby vs Perl performance David Masover wrote: > I fail to see how that's more inherently anarchistic than: > > - Re-opening classes at runtime > - Redefining methods, or whole classes, also at runtime > - Adding a method or mixing a module into just one instance > - All of the above with user input (eval) > - Doing no type checking whatsoever > - Overriding basic operators (make 2+2==5) > - Corrupt basic assumptions (make nil.nil? false) and crash Indeed, all this can lead to anarchy and chaos, but that is your doing! There must be a reason for redefining a class, if it is a subversion than indeed it is anarchy, but how many creators sabotage their own creation?. Language enforcing the rules does not mean that it should stop you from making incorrect assumptions such as 2+2==5. Statistically, type checking is not needed and mostly presents an unnecessary clutter in the code with little if any benefit at all. And what's nil.nil - some devilish construct of yours? > Ruby's strength is in what you're calling "anarchy" -- except when you > choose to call it "flexibility". I do not call Ruby anythingexcept OOPL from start to the end. And most certainly all that you call inherently anarchistic above if used to model the reality you are trying to reproduce with your design is power unheard of in the traditional OOPLs. > You've certainly not done a good job of explaining or defining such > rules. I did not invent nor made up those rules, they are spelt out in Booch, and nicely packed in design patterns. You can adhere to these rules in any language even assembler, it only is much harder to do so in procedural languages. Besides, it is not so much about following these rules as understanding them. Your misplaced comments about most of the details you are bringing up in this discussion and most noticeably about encapsulation show a serious deficit in this area on your part. >> The fact that you see meritocracy in the same light as >> aristocracy ... > Show me where I said that. Are not the following your words: "Except that Ruby enforces the aristocracy with respect to which methods belong to which classes". I have gone to great length explaining the difference between taxonomy that classifies things by its membership and the other that takes into account the merits. The two are orthogonal and do not mix as you are suggesting by attributing knighthood based on behaviour (activity, methods, functions, processing) rather on ancestral principles based on name or membership, as is known to us throughout the history. > ... It's fine if the language can enforce them -- in Perl, I can do > things like 'use strict' or 'use warnings'... Again you are mixing apples and oranges. Perl's strict does not qualify for encapsulation, orthogonality of aggregation or composition and inheritance, for rule of favouring delegation over inheritance,... heck I do not even know you understand what I am talking about! And I have no time explaining or defining all this to you. For any OO programmer, designer or analyst these are pure facts nobody questions or doubts any more. > So, if there was an UnboundMethod#bind! method, which would bind that > method to an object completely unrelated, I could choose not to use that > method. So could you. I don't see how its very existence threatens that. You are a master of sabotage. I believe you do this only in forum discussions and not to your code and creative processes, however if this writing is a creative process, you must somewhat of an anarchist. > It's a lot easier to ignore functionality you don't need than it is to > find functionality you do need missing. And what a generality is again this? I have not found it in any of the pertinent methodologies discussed here. Most likely it is a convenient concoction of yours for the sake of argument and no substance or merit for that matter. > Actually, Module _is_ a class. Modularity packs abstractions into discrete units. Abstractions are represented by classes. There is no way on the Earth to turn this definition around. Namely a class can never be a module nor is module a class as you are suggesting. Yes, you could make your own concoctions but that ain't gonna be OO! > Am I missing any? As I have shown you above, a great deal and much more. Have fun, cheers -- Posted via http://www.ruby-forum.com/.