Style question - Modify passed arged if void context?

This is yet a continuation of the microlanguage that I'm working on; right now, I've been able to implement tye's solution on reverse inheritence as offered in (tye)Re2: Possible Stupid Perl Trick - Importing method into object class?. That is, I can now do:

package Data;

sub new { ... }
sub other { ... }

#no "process" package


package My::ProcessA;

BEGIN { #reverse inheritence code into Data }

sub processA {
   my ( $data, @opts ) = @_;  #$data is a Data instance\
   ...
   return new Data( $stuff );
}

package My::ProcessB;

BEGIN { #reverse inheritence code into Data }

sub processB {
   my ( $data, @opts ) = @_;  #$data is a Data instance
   ...
   return new Data( $stuff );
}


# In code:
use Data;
use My::ProcessA;   (Data::processA appears, magically!)
use My::ProcessB;   (Data::processB appears, magically!) 

my $data = new Data ( $data_from_file );

# Now possible, woohoo!
my $processed = $data
                    ->processA( @Aopts )
                    ->processB( @Bopts );
[download]

This works great, and no compliants here.

However, in browsing thru OOPerl recently, I noticed that the wantarray function, which can determine what context the function is called in, actually can have 3 states; true if an array is wanted, defined but false if a scalar is wanted, or undefined if in void context. Now, thinking about my functions above, I wonder if there should be a difference in terms of functionality between the following calls:

my $newdata = $data->processA( @opts ); #scalar
              $data->processA( @opts ); #void
[download]

That is, in the void context, it would seem to be apparent that I want to do process A on the data and set the data to those new values. In the scalar context, the function returns a new Data object which is stored in the new variable; $data may or may not be set with the new data as well. I'm more interested in the case where, in scalar context, it is NOT set with the new data while void context it is; I know this feels like bad coding style, but for some reason, this seems to rather natural in the way this data is processed.

Should I avoid this 'mixed metaphore' and have the processing be consistent regardless of context, or is there nothing wrong with the alternate behaviors?

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

Comment on Style question - Modify passed arged if void context? Select or Download Code

Replies are listed 'Best First'.
Re: Style question - Modify passed arged if void context? by dragonchild (Archbishop) on Dec 11, 2001 at 22:07 UTC
That's pretty neat that wantarray tells you if it was a void context. To address your concern ... I would say that's it's a neat idea to do that. Sorta like the entire discussion on whether unary operators should modify in place, if called in a void context. As always, you gotta document, document, document. wanders off to think on how to use this neat-o-keen behavior ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply]
Re: Style question - Modify passed arged if void context? by dws (Chancellor) on Dec 11, 2001 at 23:14 UTC
Should I avoid this 'mixed metaphore' and have the processing be consistent regardless of context, or is there nothing wrong with the alternate behaviors? A poll of your user community might be in order. Run the syntax by a few people, and ask them what they expect to have happen. Let (reasonable) user expectations guide your design.	[reply]
Re: Style question - Modify passed arged if void context? by blakem (Monsignor) on Dec 12, 2001 at 00:49 UTC
CheeseLord meditated about doing this for `uc` and `lc` (i.e. `uc $foo` in void context would actually modify `$foo`) at DWIM Part Nineteen: Unary Operators in Void Context. -Blake	[reply] [d/l] [select]
Re: Style question - Modify passed arged if void context? by japhy (Canon) on Dec 11, 2001 at 22:47 UTC
That's one reason I really like Ruby. You can do things like `obj.meth!` that denote that the `meth` method operates in-place. Self-documenting code. Update: the "!" is allowed in method names, and does not enforce in-place modification, but it is merely a convention. Oh. PerlMonks. I have no problem with it, so long as the behavior is documented. _____________________________________________________ Jeff`[japhy]`Pinyan: Perl, regex, and perl hacker. `s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;`	[reply] [d/l] [select]
Re: Style question - Modify passed arged if void context? by herveus (Prior) on Dec 12, 2001 at 20:12 UTC
Howdy! Yes. No. Ummm... It depends... If you are going to have different behavior in void vs. scalar contexts, you need to be real clear in your docs. My gut tells me that such would be unexpected. On the other hand, it may be appropriate for some circumstances (as the documentation will make clear). That is, in the void context, it would seem to be apparent that I want to do process A on the data and set the data to those new values. In the scalar context, the function returns a new Data object which is stored in the new variable; $data may or may not be set with the new data as well. Does processA change the input data or does it produce useful side effects? Why might the calling context be variable? I think that the answers to those questions will clarify what the "right" behavior will be. yours, Michael	[reply]