in reply to Re^2: Automatic vivification of an object
in thread Automatic vivification of an object

> As for prototypes, I tend to add them to method declarations as a form of minimal documentation to help me quickly understand what data types the method is expecting

Sorry but that's dangerous nonsense.

Using anything else than $ would be misleading hence even $ is redundant.

And even $ will make Class->method() act different to Class::method()

Cheers Rolf

PS: Je suis Charlie!

Replies are listed 'Best First'.
Re^4: Automatic vivification of an object
by bounsy (Acolyte) on Jan 15, 2015 at 16:30 UTC

    My nethods are always intended to be used as methods ($obj->method(...)) and non-methods are always intended to be used as functions (class::function(...)). Method invocations rely on the first parameter being an object of the required type in order to function properly and to make sense. Yes, an end user can do whatever he/she wants (this is Perl, after all), but it won't work correctly in many cases, since additional methods and properties will likely be accessed in a method. For methods, my understanding is that $obj->method(...) and class::method($obj, ...) (assuming $obj is of type class) are functionally identical. Feel free to correct me if I am wrong.

    In almost all cases, my methods and fuctions all have specific parameters that they are expecting (i.e., nothing, two scalars, a scalar followed by an array, a hash, etc.). So how is this dangerous?

    I am aware that some Perl functions are flexible to accept multiple types of parameters and I have left off prototypes when I have created such functions, but I generally don't create functions like that. If I want to create such functions, then I usually use a hash/hashref as the last parameter and pull key/value pairs as needed.

      It's just confusing. It's like using warn for documentation because STDERR is closed in all my scripts, anyway:
      close STDERR; warn "Now we have a better POD to play with!";
      لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
      > So how is this dangerous?

      a $ prototype forces scalar context

      DB<108> sub nopro { print @_ } DB<109> sub pro ($) { print @_ } DB<110> @a=3..7 => (3 .. 7) DB<111> nopro(@a) 34567 DB<112> pro(@a) 5

      This is especially dangerous if your argument is another function call.

      Giving a method a prototype other than ($;@) is at best misleading and will result in awfully ugly bugs if someone is assuming:

      > $obj->method(...) and class::method($obj,...) (assuming $obj is of type class) are functionally identical

      DB<113> sub meth ($$) { print @_ } DB<114> main->meth(@a) main34567 DB<115> main::meth('main',@a) main5

      if you want a good self documentation, expand arguments to meaningful names:

      sub meth { my ($self, $x_ax, $y_ax, $arr_ref, @opt) = @_; }

      I'm not sure what your understanding of "type" is in Perl's context.

      Cheers Rolf

      PS: Je suis Charlie!