Passing the method's return as argument

Hola, What would be the correct way to pass the return of one method as an argument to another method? Let's say we have a method dugh() that returns some value and a method foo() that takes the return of dugh() as an argument...

Any legal way to get the return of dugh() to be the argument of foo()...

Horatio Westock

Ranch Hand

Posts: 221

posted 13 years ago

I don't understand your question. That is legal.

e.g.

Gjorgi Var

Ranch Hand

Posts: 85

posted 13 years ago

Originally posted by Horatio Westock: I don't understand your question. That is legal.

e.g.

Sorry for the confusion caused... Yes, that solved the problem, thank you for the point. On the other hand, my approach with method as an argument to another method may not be a good OOP... [ March 27, 2005: Message edited by: Gjorgi Var ]

...my approach with method as an argument to another method may not be a good OOP...

To be clear, the method isn't an argument; the return value of the method is an argument. This may seem a trivial distinction, but there are languages (Smalltalk, Ruby, Groovy, and more) in which a method can be an argument. And in general these are considered to be more object-oriented than Java. The idea is that everything's an object, including a a method. And you can pass any object as a parameter. (Note that scripting languages like Ruby and Groovy tend not to have type safety, so you really can pass anything as an argument - even if it's something that makes no sense to pass as an argument.)

well, if you want to split hairs and debate technicalities, you could say Jim's simplifying a little. type safety isn't quite the same as static typing; just because a language will let you pass any object, of any type, as an argument to a method, doesn't mean the language isn't keeping track of the types involved. typically, in modern-day languages that let you do this, you're in for some sort of type mismatch exception being thrown if you're not careful.

static typing, like Java has, is where you have to tell the compiler what types of objects a variable can take and what types the parameters and return values of functions can be; attempting to violate your own declarations about types usually generates a compile-time error in statically typed languages. the opposite is dynamic typing, which occurs in languages that figure out the types of variables, objects, parameters, and so on as they go along, and usually try to convert between types as needed whenever they can.

strong typing or type safety is when the language doesn't try to treat an object of one type as if it were of any other. if such a language is also statically typed, usually you have to explicitly cast or convert objects before you can treat them as something other than what they are; dynamically and strongly typed languages can sometimes attempt to do some of the simpler conversions themselves (like .toString() and conversions between int, float and double, say) but occasionally they'll force you to do some converting yourself, or catch a TypeError exception or something.

weakly typed languages are not often designed any longer. such languages, like C, will let you treat any variable or object as if it were any other thing without converting it first. in C, multiplying your birthdate with your mother's maiden name is straightforward and easy. some weakly typed languages got really bad - in very old versions of FORTRAN, you could redefine the values of literal constants; you could make the symbol "1" have the value "2"... yes, it really got as messy as you might imagine; that's why modern languages tend to be strongly typed.

Gjorgi Var

Ranch Hand

Posts: 85

posted 13 years ago

Originally posted by Jim Yingst:

To be clear, the method isn't an argument; the return value of the method is an argument. [/QB]

That was exactly what I wanted; to take the return value of a method as an argument to another method...