RCR 249: Object#self

Why do you need a transform that does nothing? I do not see that this has been adequately answered. --Austin Ziegler

---

I agree. It's unclear as to why this would even be useful. -- MarkHubbart

---

We should have a good visible link to on this site. I think it's not so good, if Matz has to read through all these pointless RCRs, instead of hacking Rite. -- flori

---

A fancier name than 'do nothing xform' is 'identity transform'. It is useful in math, also useful in code.

  xforms = { "123"=>:to_i, [1,2,3]=>:zip, [4,5,6]=>:self }
  xforms.each_pair do |obj,xform| p (obj.send(xform)) end

It eliminates the need for conditional code around a sentinel pseudo-transform like nil

  if xform; p obj.send(xform); else p obj; end

It eliminates using proc objects simply to allow: proc{|x| x}

Itsme

---

I think that part of the problem that I'm seeing is that I don't actually see a reason for this to become part of the core Ruby. Not to sound difficult, but I haven't seen any real problem that you're trying to solve with this that is large enough to justify its inclusion into core Ruby, when you can easily reopen Object to do exactly this in code where you need it. -- Austin Ziegler

> Perhaps so.
> Arguably IdentityXform : Xform :: 0 : Integers_with_+
> So when people need transforms they might need to reopen Object;
> or perhaps it belongs in a Transforms module, not in Core.
> Itsme

---

In your example :to_i, :to_s and :zip all return new objects, so why don't simply use :clone or :dup ? -- Matthias Georgi

---

If I did not want shared state through side effects, or want to avoid the cost of dup/clone, or any of the other usual reasons .... :dup or :clone would be fine. The to_i etc. were just to highlight that my intended usage was collections of _different_ transforms on objects, rather than different implementations of the same transform.

Itsme

---

(An edit I made was removed. Here it is again.) Why do you need collections of transforms? What problem are you solving?

If you need an identity transform, use nil and redefine #send:

  class Object
    alias_method :oldsend, :send
    def send(s, *a)
      if s.nil?
        self
      else
        oldsend(s, *a)
      end
    end
  end

This could be implemented in a module, easily, so that when you know that you're putting objects into the collection of transforms, you can call o.extend(Transforms::Identity) and get the same effect. -- AustinZiegler

---

I like this alternative, thanks.

I'll remember to run any future half-baked ideas through comp.lang.ruby first.

Itsme

---

I don't actually think it's half-baked. An identity function is a useful thing to have. Why not in an OO language as well? I think both this RCR and the Object#self idea should be part of core Ruby. Not because there's an urgent pressing need; just because they make sense. I resist changes when they have side-effects or blur the lines of whatever, but these seem self-contained ideas that are a perfect fit with the language.

I never buy the "what's the need for them" argument anyway. With that mindset, we probably wouldn't have continuations. And perhaps they wouldn't have been missed, but also we wouldn't have Borges, which would be a shame.

A better metric to my mind is "if this feature had been included a long time ago, would I want to keep it, throw it out, or be neutral?". Don't lose the big picture by focusing too much on the delta.

And FWIW, I would have appreciated this feature a few times in the past. I commonly do conditional transforms, and sometimes you want the "identity method" for that.

I'll vote in favour, but there may be issues with the naming of 'self' that I haven't seen.

--GavinSinclair

---

I've changed my mind, thanks to etc. Object#send(nil) should not be allowed (i.e. no change from current Ruby). This RCR posits a better solution, and I support it fully. The name 'self' is bad, though, because it conflicts with the special variable 'self'. 'identity' is better, but that has the problem of undermining a class-specific 'identity' concept. '_identity' perhaps? I'm rambling. We need a better name and a new RCR to supercede this.

--GavinSinclair

I echo Gavin's comments. The folks who say "why do we need a transform that does nothing" should look at String#to_s, Array#to_a, Fixnum#to_i and ponder. I think the proposer is looking for Object#to_self -- if so, I'd support the request.

--daz

---

(Gavin, when you say Object#self(nil), do you mean Object#send(nil)?) I think that Object#to_self is by far the best of these no-op method names, because of the harmony with the to_* which are no-ops in some cases. In fact it's the only one that reconciles me to having such a thing in the language at all. In other words, I agree with daz :-)

-- David Black

Yes, and I corrected my comment above; thanks. And yes, I'd be happy enough with #to_self. Thanks Dazza!

-- Gavin Sinclair

---

Smalltalk calls this method #yourself, but then Smalltalkers like to pretend that their objects are little people that you can talk with.

I like #to_self, because the identity method makes a lot of sense when compared to the current #to_* methods. Voting in favor.

-- Daniel Brockman

P.S. Curse this form layout, which has now tricked me into discarding my commentary text twice. The natural way to fill out this form is (1) type your comments, (2) choose your vote, (3) click submit.

---