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

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.

Replies are listed 'Best First'.
Re^5: Automatic vivification of an object
by choroba (Cardinal) on Jan 15, 2015 at 16:59 UTC
    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!";
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re^5: Automatic vivification of an object
by LanX (Saint) on Jan 15, 2015 at 20:42 UTC
    > 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!