Just A Summary : Baby's first screencast

Comment on Baby's first screencast by James Abley

Fri, 14 Mar 2008 17:08:39 -0500

That’s quite cool. I’m almost inspired to pick up Ruby in more depth, since that uses some language features that I’ve not gone deep enough to encounter yet. I look forward to seeing a more in-depth version.

And don’t worry about the typos, I’ve got far worse fat fingers than that!

Comment on Baby's first screencast by Piers Cawley

Sat, 15 Mar 2008 06:21:40 -0500

What I’d really like to do is to write:

class Whatever
  use :laissez_faire_nils

  ...
end

and have all the methods I define in that class definition use an Objective C style nil. For bonus points, if someone reopens the class, they shouldn’t get that style of nils unless they explicitly ask for them again. However, I think the only way to do something like that would be to use an explicit block:

class Whatever
  with(:laissez_faire_nils) {
    def some_method
      ...
    end
  }
end

Mutter… {} isn’t right there. But then wrapping do ... end around a block of purely declarative code just feels ugly too. If only there were some way of implementing new block methods, so we could write:

with(:whatever)
  ...
end

Lisp style macros rock…

Comment on Baby's first screencast by Kevin Ballard

Sat, 15 Mar 2008 10:13:47 -0500

I’m a fan of try(:method), as in

foo.try(:bar).try(:baz)

It’s also really simple to implement

class Object
  def try(name, *args)
    method(name).call *args
  end
end

class NilClass
  def try(name, *args)
    nil
  end
end

Comment on Baby's first screencast by Aristotle Pagaltzis

Sat, 15 Mar 2008 11:58:27 -0500

Piers, I don’t think that code is right. Your modification of @nil@’s behaviour is temporally scoped, whereas it should be lexically scoped.

Comment on Baby's first screencast by Tom Moertel

Sat, 15 Mar 2008 16:12:56 -0500

You might want to reconsider the requirement that “maybe(3) {nil} should be nil,” especially if you’re using the Maybe monad as inspiration. Without that requirement, the semantics of maybe(z_) {_e} are straightforward: nil represents failure.

If you add that requirement, however, failure is represented by attempting to call a non-existent method on a nil value. Such failure semantics result in unintuitive inconsistencies. Consider, for example, the following chain:

maybe(3) { e1.e2.e3.e4 }

If e1, e2, or e3 fails (i.e., returns nil), the entire computation e1.e2.e3.e4 fails and thus the result of the maybe computation is 3. If, however, only e4 fails, the entire computation e1.e2.e3.e4 somehow “succeeds” (with the result of nil), which seems inconsistent. Why should nil denote failure for all but the last element of the chain?

It seems, then, that the requirement ought to be “maybe(3) {nil} should be 3”.

Cheers,
Tom

Comment on Baby's first screencast by Piers Cawley

Sun, 16 Mar 2008 16:48:19 -0500

@Aristotle: Ugh! You’re right. I have the awful feeling that the only successful fix would involve changing the interface so that the first value is passed as the value to the block:

maybe(initial_value, default) {|it|
  it.should.return.the.default.if.nil.crops.up
end

That way we can wrap the initial value in a proxy object before the block gets at it and wrap each intermediate value as well. I don’t like the interface so much though (even though it would end up working even more like a Haskell Maybe).

@Tom: Ah yes, point taken.

Comment on Baby's first screencast by Daniel Berger

Mon, 17 Mar 2008 13:32:57 -0500

foo.bar.baz rescue nil

Have a nice day.

Comment on Baby's first screencast by Piers Cawley

Tue, 18 Mar 2008 02:20:28 -0500

@Daniel: If you want to shoot yourself in the foot, go ahead and do that. If, however, you’ve been there, done that and got the holes to prove it, you start wanting something a little more robust.

Comment on Baby's first screencast by loki

Sat, 12 Apr 2008 11:38:32 -0500

May be you could use:

if defined? foo.bar
  puts 'May be'
end

Comment on Baby's first screencast by Nando Vieira

Sun, 01 Jun 2008 20:40:46 -0500

An alternative to the maybe approach is something like this: http://pastie.caboo.se/206983