Comment on this RCR (edit wiki page) | RCRchive home

RCR 249: Object#self

submitted by itsme213 on Sat Apr 24 2004 02:28:16 PM -0700

Status: pending

Abstract

A pre-defined method on Object 
class Object
  def self *args
     self
  end
end

Problem

Transforms on objects are often done by methods like to_s, to_i, intern, etc. A default transform should be available that 'does nothing'. This eliminates the need for sentinels such as 'nil' when you want to uniformly define some such mappings, but some things do not need to be mapped. e.g. mapping types from domain objects to/from UI widgets.

Proposal

As above

Analysis

The only question I see is whether we can name such a method 'self', or if we need some other name.

Implementation

As above

Vote for this RCR

Strongly opposed [3]
Opposed [0]
Neutral [0]
In favor [2]
Strongly advocate [1]

Change the status of this RCR to:

accepted

rejected

withdrawn

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 <tt>nil</tt> 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

Back to RCRchive.

RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog