Originally posted by Horatio Westock:
I don't understand your question. That is legal.
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 ]
Originally posted by Gjorgi Var:
...my approach with method as an argument to another method may not be a good OOP...
I think it's prefectly fine from an OOP standpoint. You just want to consider how easy the code is to read, and whether you want a "handle" on the return value(s).
int d = dugh(); //here, variable d can be used elsewhere
foo(dugh()); //here, return value remains anonymous
[ March 27, 2005: Message edited by: marc weber ]
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.)
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.