undefined | Better HN

0 pointsepidemian10y ago0 comments

> To me that appears to be the strangest way to express a loop in any language I've used (and I've used a lot of them).

Well, given that repeating some piece of code N times involves only two "entities", the code to be repeated and the number of repetitions, i see it as a very natural OO design decision to put that looping logic on a method on one of those two entities. The other possibility would be to make the "code" object respond to a method that tells it how many times to execute:

  { puts "Hello, alternate Ruby" }.do_times(10)

It might be more intuitive to do so if the first object you have is the code you want to repeat, but it doesn't read as nicely :P

> It also really bothers me that in ruby you can invoke a function on a null value to see if its null (myvar.nil?). That's really messed up...

Can you elaborate in this please? I personally think that making nil something else than an object on OO language wouldn't make much sense. It would be an unnecessary complexity to stipulate "the way we interact with objects is through message-passing, except with nil, on which you cannot pass any message, but instead you have to compare it by identity to a global value named nil". Nil being a regular object that responds to things like .to_s or .nil? is pretty handy.

0 comments

ploxiln10y ago

If you don't know the type which a name references (or whether it is nil), you have to figure that out before you call any methods on it, in an "external" way. So you have to do " == nil" or "typeof(mything) ==" or "isinstance(mything, type)". This is true for almost every method (except "nil?" in ruby.)

Ruby has a lot of these special cases where there's a gimmicky way to do something which is not the general purpose way and is not the right way to think about that kind of logic. "== nil" is just as short as ".nil?" and isn't as wacky as intentionally calling methods of nil (and every other object needing to have this nil-specific interface).

skywhopper10y ago

This isn't a gimmick or a special case. "nil" is an object of type NilClass, which is a subclass of Object: http://ruby-doc.org/core-2.2.0/NilClass.html

In fact, everything in Ruby is an object. Languages that treat "nil" or "44" as not being instances of a class are the ones making special cases.

svisser10y ago

The absence of an object is not a special case.

To indicate that with a "nill" object is a special case?

j / k navigate · click thread line to collapse