|
Re^3: I dislike object-oriented programming in general
by tilly (Archbishop) on Oct 20, 2007 at 00:31 UTC
|
I'm curious. In your view, on what basis is JS more OO than Ruby? If anything I'd say that it was the other way around. (Note that both are far more OO than Perl.)
For example in Ruby if you sort an array of numbers, it defaults to sorting them as numbers. In JavaScript it defaults to sorting them alphabetically, no matter what their types are.
For another example, in Ruby I can trivially add a new method to Integer, and then call my new method on the integer 5. In JS it works, but much less consistently. This works:
Number.prototype.foo = function () {alert("Hi!")};
x = 5;
x.foo();
But this doesn't (at least not in Firefox):
Number.prototype.foo = function () {alert("Hi!")};
5.foo();
That isn't what I expect from a completely object-oriented language!
Furthermore the OO hooks in Ruby are much more pervasive than in JavaScript. For instance I once tried to write a fairly efficient factorial function in Ruby. I found that it was more efficient than the routine to convert big integers to strings! So I replaced the routine to convert big integers to strings.
I wouldn't even dream of messing around in the internals like that in JavaScript. | [reply]
[d/l]
[select] |
|
|
The reason why that doesn't work is a legacy error in the ECMAScript standard. By following a numeral with a dot, the parser expects that you're defining a floating-point value, rather than an integer. You can still call methods on it, however, if you disambiguate by wrapping it in parentheses first.
(5).foo();
| [reply]
[d/l] |
|
|
class Fixnum;
def hello ()
puts 'hi';
end;
end;
5.hello;
| [reply]
[d/l] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
++tilly for proving a surprising (to me, at least) example of where JS's object modeling goes wrong.
Personally, I think javascript's object model is cleaner than ruby's, but its prototype model seems quite alien when you're coming from a language that distinguishes classes and objects and for some reason javascript tries so very hard to hide that fact by stuffing so much niceness behind so many ugly constructs (for instance, when you've understood the JS model of inheritance, the new constructor() special operator and all it entails no longer makes any sense at all)
| [reply]
[d/l] |
|
|
Cleaner is in the eye of the beholder.
Personally I think that it makes a lot of sense to have a clear distinction between class methods and object methods. For instance it is obvious that a class called File should do things like open files and return the associated object. But it makes no sense to me to ask a file object to open other files. But that means that a file object should not inherit from File. In which case the natural implementation is to have a prototypical file which has no real file associated with it. Which "feels" wrong to me.
But different strokes for different folks. In the end either object model works.
| [reply] |
|
|
You're absolutely correct in your examples. The implementations of Javascript do not provide proper autoboxing. This isn't that surprising, given Javascript's history and the browser wars.
What I was referring to was Javascript's prototype-based (vs. class-based) OO. I find that you can easily build classes on top of prototype, but you can't build prototype on top of classes as easily. I can't imagine how I'd build a prototype OO system in Ruby. There's a dozen really decent implementations in Javascript of a class system.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
|
|
Um, only the second example involved anything that looks like autoboxing. (And that one did not involve autoboxing, as pvande pointed out it was a parsing issue.) The first was a case where JavaScript is not using available hooks in places where it makes sense to do so, and the third was a case where JavaScript simply does not provide conveniently placed hooks.
But if your complaint with Ruby's OO system is that it cannot easily implement a prototyped system, that's like saying that Perl is more OO than JavaScript because it is easier to implement a prototyped system in Perl than to implement multiple inheritance in JavaScript. This is true, but irrelevant - Perl's support for OO everywhere is not as pervasive as JavaScript's.
Furthermore you're mistaken. I found a trivial implementation here:
Proto = Class.new(Class) # Beware: magic.
def Proto.clone
Class.new(self)
end
While I don't doubt that there are many good class implementations in JavaScript, I doubt that any are as short and cute as this prototype implementation in Ruby. Follow the link for a demonstration of usage. While I have to admire how cleverly it ties objects to classes, it unfortunately doesn't work with ancient versions of Ruby such as the one I have on my computer. (Ruby 1.6.8 complains that you can't create a subclass of Class. That version is from 2002.)
There is also prototype in the Ruby gems library. I didn't like some things about it (in particular it looks like it doesn't support noticing that the prototype changed), so I implemented my own reasonably full-featured system using a minimum of strange magic that works even in ancient versions of Ruby: | [reply]
[d/l]
[select] |
|
|
(5).foo(); works, at least here using firebug
It is reasonable that parenthesis are required, as 5. makes the tokenizer think about floats and it is legal syntax. I have not checked the standard, though.
| [reply] |
|
|
| [reply] |
