This discussion is archived
1 2 3 Previous Next 43 Replies Latest reply: Mar 15, 2010 4:40 PM by 843798 Go to original post RSS
  • 15. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    jschell wrote:
    sledged wrote:
    Sometimes it's not even clear before runtime whether a constructor's needed or a method.
    To clarify, I was making reference to a closed set of options. Either a method or a constructor and no other possibilities.
    That still is unclear. Spring doesn't allow absolutely any method. All it allows and expects at that point is a factory.
    That's beside my point. A factory still translates to a method in Spring. It merely imposes the limitation that the method have a return type other than void. None of which changes the fact that Spring doesn't know until runtime whether it's invoking a method or a constructor.
    Two construction idioms supported. That is different than "constructor" and "method".
    Not different enough to invalidate my point.
  • 16. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    sledged wrote:
    jschell wrote:
    sledged wrote:
    Sometimes it's not even clear before runtime whether a constructor's needed or a method.
    To clarify, I was making reference to a closed set of options. Either a method or a constructor and no other possibilities.
    That still is unclear. Spring doesn't allow absolutely any method. All it allows and expects at that point is a factory.
    That's beside my point. A factory still translates to a method in Spring. It merely imposes the limitation that the method have a return type other than void.
    Not beside the point at all. Spring expects it to be a factory. The fact that you can put any method you want there is irrelevant. You can do the same thing in your own code where you expect a factory and it would be wrong there as well.
    None of which changes the fact that Spring doesn't know until runtime whether it's invoking a method or a constructor.
    Yes it does. That is why it provides two different ways to specify it.

    >
    Two construction idioms supported. That is different than "constructor" and "method".
    Not different enough to invalidate my point.
    Very different. As OO languages all differentiate it.
  • 17. Re: Academic Question about Classes Method and Constructor
    jtahlborn Expert
    Currently Being Moderated
    jschell wrote:
    sledged wrote:
    jschell wrote:
    sledged wrote:
    Sometimes it's not even clear before runtime whether a constructor's needed or a method.
    To clarify, I was making reference to a closed set of options. Either a method or a constructor and no other possibilities.
    That still is unclear. Spring doesn't allow absolutely any method. All it allows and expects at that point is a factory.
    That's beside my point. A factory still translates to a method in Spring. It merely imposes the limitation that the method have a return type other than void.
    Not beside the point at all. Spring expects it to be a factory. The fact that you can put any method you want there is irrelevant. You can do the same thing in your own code where you expect a factory and it would be wrong there as well.
    None of which changes the fact that Spring doesn't know until runtime whether it's invoking a method or a constructor.
    Yes it does. That is why it provides two different ways to specify it.
    Two construction idioms supported. That is different than "constructor" and "method".
    Not different enough to invalidate my point.
    Very different. As OO languages all differentiate it.
    seriously? a constructor is basically just a special static method for a class. can we admit that sledged does have a valid point (even if it's not a use case you've ever had) and move on?
  • 18. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jtahlborn wrote:
    Two construction idioms supported. That is different than "constructor" and "method".
    Not different enough to invalidate my point.
    Very different. As OO languages all differentiate it.
    seriously? a constructor is basically just a special static method for a class. can we admit that sledged does have a valid point (even if it's not a use case you've ever had) and move on?
    Nope.

    As I noted the factory idiom existed before java.

    I haven't seen any indication that any OO language accepts that a constructor is a "normal" method. The semantics are different in all three OO languages that I have used extensively: C++, Java and C#.

    I certainly haven't seen any writers lamenting the fact that construction should have been made more simple.

    As I noted I can in fact create both C++ and Java objects without construction and in both cases I would expect the system to fail immediately or become unstable.

    So the fact that java decided to make that very different behavior explicit is not a bad thing.

    The only thing I can take from this discussion so far is that sledged doesn't want to explicitly implement the two idioms. Which entirely ignores the fact that they are in fact different and represent entirely different ways of accomplishing something. And ones which do not break the differentiation between construction and methods.

    Finally I have in fact implemented both factory and construction idioms dynamically in C# and Java. And I have implement construction dynamically in C++ as well. So it is certainly a "use case" that I have encountered before. The fact that I needed to support both never lead me to want to handle them as one case. I simply differentiated that they were in fact two different cases and required that the dynamic source provided that differentiation. Which is exactly what Spring does.
  • 19. Re: Academic Question about Classes Method and Constructor
    jtahlborn Expert
    Currently Being Moderated
    jschell wrote:
    jtahlborn wrote:
    Two construction idioms supported. That is different than "constructor" and "method".
    Not different enough to invalidate my point.
    Very different. As OO languages all differentiate it.
    seriously? a constructor is basically just a special static method for a class. can we admit that sledged does have a valid point (even if it's not a use case you've ever had) and move on?
    Nope.

    As I noted the factory idiom existed before java.

    I haven't seen any indication that any OO language accepts that a constructor is a "normal" method. The semantics are different in all three OO languages that I have used extensively: C++, Java and C#.

    I certainly haven't seen any writers lamenting the fact that construction should have been made more simple.

    As I noted I can in fact create both C++ and Java objects without construction and in both cases I would expect the system to fail immediately or become unstable.

    So the fact that java decided to make that very different behavior explicit is not a bad thing.

    The only thing I can take from this discussion so far is that sledged doesn't want to explicitly implement the two idioms. Which entirely ignores the fact that they are in fact different and represent entirely different ways of accomplishing something. And ones which do not break the differentiation between construction and methods.

    Finally I have in fact implemented both factory and construction idioms dynamically in C# and Java. And I have implement construction dynamically in C++ as well. So it is certainly a "use case" that I have encountered before. The fact that I needed to support both never lead me to want to handle them as one case. I simply differentiated that they were in fact two different cases and required that the dynamic source provided that differentiation. Which is exactly what Spring does.
    I've made my point. I just wanted to let sledged know that his thought was not unreasonable. I've already deduced from the rest of the thread that you were not interested on seeing anyone else's point of view.
  • 20. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    Thanks, jtahlborn. It's nice to get confirmation that I'm able to articulate my thoughts well enough to have my point understood.
  • 21. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jtahlborn wrote:
    I've made my point. I just wanted to let sledged know that his thought was not unreasonable.
    Then it probably would have made more sense to simply quote one of his responses, agree with it, and leave it at that.
    I've already deduced from the rest of the thread that you were not interested on seeing anyone else's point of view.
    As a thought given that you "deduced" that then you should have taken the opportunity to not challenge my "point of view" in the first place.
  • 22. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Not to mention of course that if it is in fact wrong then one could open a bug or create JSR to correct it.
  • 23. Re: a constructor is basically just a special static method for a class.
    843798 Newbie
    Currently Being Moderated
    a constructor is basically just a special static method for a class.
    By the same reasoning you could say instance methods are basically special static methods just with an implicit "this'" argument.
  • 24. Re: a constructor is basically just a special static method for a class.
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    BIJ001 wrote:
    a constructor is basically just a special static method for a class.
    By the same reasoning you could say instance methods are basically special static methods just with an implicit "this'" argument.
    Yep. And pretty pointless to have classes at that point then because of course then all OO functionality can be implemented via the right sequence of procedural calls by passing this to the correct methods. Then all sorts of complications introduced by OO could be removed.

    For that matter make all the code dynamic from the beginning as well. Then one can simply edit the running source directly by overwriting the correct location in the huge string.
  • 25. Re: a constructor is basically just a special static method for a class.
    jtahlborn Expert
    Currently Being Moderated
    BIJ001 wrote:
    a constructor is basically just a special static method for a class.
    By the same reasoning you could say instance methods are basically special static methods just with an implicit "this'" argument.
    well, uh, that pretty much is how they are implemented. not to mention that this discussion was talking about reflection. and for the purposes of reflection, a static method and an instance method are the same types, just that for one you need to pass the object reference as the first argument to invoke (as you mention).

    Edited by: jtahlborn on Mar 11, 2010 2:21 PM
  • 26. Re: Academic Question about Classes Method and Constructor
    jtahlborn Expert
    Currently Being Moderated
    jschell wrote:
    Not to mention of course that if it is in fact wrong then one could open a bug or create JSR to correct it.
    the OP was never arguing that java was fundamentally implemented wrong. he was just saying that it would be nice to have Method and Constructor share a common super type because they are both essentially "invokable" types.
  • 27. Re: a constructor is basically just a special static method for a class.
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jtahlborn wrote:
    BIJ001 wrote:
    a constructor is basically just a special static method for a class.
    By the same reasoning you could say instance methods are basically special static methods just with an implicit "this'" argument.
    well, uh, that pretty much is how they are implemented. not to mention that this discussion was talking about reflection. and for the purposes of reflection, a static method and an instance method are the same types, just that for one you need to pass the object reference as the first argument to invoke (as you mention).
    Yes but seems like the same logic for the construction argument to suggest that it would be "easier" if the call semantics were the same and thus statics would require an object parameter as well - just make it null.
  • 28. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jtahlborn wrote:
    jschell wrote:
    Not to mention of course that if it is in fact wrong then one could open a bug or create JSR to correct it.
    the OP was never arguing that java was fundamentally implemented wrong. he was just saying that it would be nice to have Method and Constructor share a common super type because they are both essentially "invokable" types.
    Whether it is a bug or a request for enhancement if it is in fact a good idea then the proper way is still to open a bug or a JSR.
  • 29. Re: a constructor is basically just a special static method for a class.
    jtahlborn Expert
    Currently Being Moderated
    jschell wrote:
    jtahlborn wrote:
    BIJ001 wrote:
    a constructor is basically just a special static method for a class.
    By the same reasoning you could say instance methods are basically special static methods just with an implicit "this'" argument.
    well, uh, that pretty much is how they are implemented. not to mention that this discussion was talking about reflection. and for the purposes of reflection, a static method and an instance method are the same types, just that for one you need to pass the object reference as the first argument to invoke (as you mention).
    Yes but seems like the same logic for the construction argument to suggest that it would be "easier" if the call semantics were the same and thus statics would require an object parameter as well - just make it null.
    we aren't talking about normal programming scenarios here, we are talking about reflection, right?