I don't see a compelling argument either way.

Assuming the situation I posit holds, the reader or user will, of necessity, have consulted the documentation for the modules that would, of course, speak to matters relevant to "what can I do with this thingy". It pretty much follows from the posited situation that the possible values of ref($obj) are closely related in some useful manner, so as to permit generalization. Heck, they may all have an identical set of methods, differing only in how those methods do stuff.

If I am in a situation where I need "another ref($obj)", I, in my laziness, don't want to be forced to say ref($obj) just for the sake of truth and beauty. I do not see that having "new" take the ref() if necessary as being, per se, a Bad Thing.

Perhaps we will have to agree to disagree.

yours,
Michael

In your argument there is a lot of assumed knowledge about the code. I hope you have great recall or don't need to maintain your code in a distant future.

In the below code $response->finish is not working correctly. It seems someone forgot to add code to register some action with the legacy system to the called finish method. Some client has expanded his use of the info generated and this is suddenly a noticed misfeature. As the newly hired Perl expert your assigned task is to fix the problem.

# Mark the calling request object as answered, use the
# ID param to create and return an response packet object.
# Let the old system know this is done.
sub _respond {
    my ($self, $request, $id, $response ) = @_;

    my $response = $request->new;    ### Hey!!

    $request->count( $request->count + 1 );

    if ( $response->approved) {
        $response->requestor( $id);
        $response->finish( SUCCESS ); 
        $request->answered( $id)
        Request_handler->reap( $request->id());
        return $response;
    }
    $response->finish( FAIL);
    return;
}
[download]

There are 27 variations of the type Packet floating around the system. _respond is called from 19 different places all but 2 of which get $request or its forerunner passed in.

My point: Do your posited circumstances exist here?

The author who wrote the code knew. He knew that $_[1] would always be a Packet_Foreign here. He didn't care about truth or clarity so the find part of a find and fix problem now requires much more effort.

I am not a great typist so I like to avoid unnecessary typing but sacrificing information for the sake of fewer keystrokes is foolish.

Howdy!

I can't tell if my posited circumstance is in place.

Whether I say $request->new or ref($request)->new has no effect on the assumption that the ref($request) is of the appropriate class (either directly or by inheritance). If it is important to verify the particular package that a ref is blessed into to ensure that the ->new part goes to the right place, then you need to check that explicitly. I don't see where that bears on the particular dispute at hand.

The sample code presented would lead me to the presumption that the range of values ref($request) could take would all have the expected methods available to it. The code would die if that assumption were invalid. If I were faced with that range of classes for $request, I would have to dredge through the various packages to discern what variations in behavior were occurring to figure out just where to patch finish().

I did note that I assumed that the packages were documented to permit users to know what methods were provided where. I'm still not seeing the objection.

yours,
Michael