in reply to bless with => separated args

Does anyone know of any reason why => might be used in place of , in this instance?
There's no particular reason apart readability/psychological feeling. Here you have a large structure applied -this is the keyword!- by bless to the class you want to bless it into. You often use => instead of , when you want to stress that the term on the left is applied or associated to that on the right.
I had always assumed that => stringifies its left operand, but a little testing, seems to indicate it only actually stringifies if it thinks the left operand is a word... i.e. not a $var - subtle!
Indeed it stringifies only in a few situations and in some cases this has led to confusion.

Incidentally, it may be a matter of personal preference/style, but this: 

  return bless my $self = {}, (ref $class || $class);
  #                           ^^^^^^^^^^^^^^^^^^^^^^

[download]
is deprecated by many kwnoledgeable OO Perl hackers.

Replies are listed 'Best First'.
Re^2: bless with => separated args
by jaa (Friar) on Aug 01, 2005 at 09:32 UTC
    Thanks for the detail on fat-comma.

    Any reason why "(ref $class || $class)" is deprecated?

    It is useful if you want a new instance based on the same class as an existing object, without having to hard-code the class name.

    The only reason that I have heard is that most people start OO by copying the examples, without understanding the code, which surely is not a strong enough reason for deprecation?

    Regards,

    Jeff

[reply]
      Any reason why "(ref $class || $class)" is deprecated?

      It can make the semantics of your constuctor confusing. If I want a new object of class Foo then I want to call Foo->new. I'd probably expect $foo->new to clone $foo, but if the class author wanted that functionality they should have created an object method called "clone" or something like that.

      In general, it's a good idea to have class methods and object methods completely separate from each other. The ref $class || $class idiom breaks that distinction.

      It is useful if you want a new instance based on the same class as an existing object, without having to hard-code the class name.

      Well, you can always use (ref $foo)->new if that's what you want.

      --
      <http://www.dave.org.uk>

      "The first rule of Perl club is you do not talk about Perl club."
      -- Chip Salzenberg

[reply]
        I'd probably expect $foo->new to clone $foo, but if the class author wanted that functionality they should have created an object method called "clone" or something like that.
        That, I do not understand. If you expect the author to name clone functionality clone, then why assume that new clones the object?

        I'd expect something called new to give me a new thing - not a cloned one.

        Well, you can always use (ref $foo)->new if that's what you want.
        That's not much of an argument, is it? With such an argument, we could do away with for/foreach, unless, and/or, q/qq/qw/qx, etc. There are always alternatives taking a few more keystrokes.

        And note that the existance of ref $proto || $proto in a constructor doesn't prevent you from writing: 

            (ref $foo)->new

        [download]
        if 
            $foo->new

        [download]
        confuses you.

        But the absense of ref $proto || $proto forces someone who doesn't confuse easily to write: 

            (ref $foo)->new

        [download]
        Ergo, using ref $proto || $proto gives the user of the module more choice.
[reply]
[d/l]
[select]
      I'm far from being an OO expert myself, but the basic reason is that they think that new() should be used as a class method and that an instance method to provide cloning should be supplied instead, to keep their roles/functionalities separated, so as to avoid possible confusion.
[reply]
[d/l]
        The existance of 
            ref $proto || $proto

        [download]
        in the constructor doesn't prevent you from using new strictly as a class method.

        It just doesn't enforce that upon someone who doesn't mind.

        I use 

            ref $proto || $proto

        [download]
        in my constructors, but I use my constructors purely as class methods. However, I let other uses of my modules free in their choice.
[reply]
[d/l]
[select]
      Deprecated implies they once endorsed it.

      Writing ref $proto || $proto allows the caller of the constructor to create a new object by calling: 

          $obj -> new;

      [download]
      Some people (who are seen as "knowledgable") claim that $obj -> new confuses the hell out of them and that hence constructors should not contain ref $proto || $proto.

      I think that's silly. If something confuses you, don't use it. No need to jihad the thing that enables you to get confused.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom