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
  • 30. Re: Academic Question about Classes Method and Constructor
    jtahlborn Expert
    Currently Being Moderated
    jschell wrote:
    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.
    sure, that would be the way to go. or submit some patches to openjdk. my understanding of the OP's post was that he was seeking validation that his idea made sense ("Academic Question..."). i personally think it has merit, although i'm not sure that the benefit would be very large as we've already established that there are very few scenarios where people would not care about the distinction between a constructor and a method.

    all i was addressing in your quote above was the classification as java being "wrong". i don't think anyone was arguing anything so strong, just that there might be scenarios where it would be convenient if Method and Constructor had a common interface/superclass.
  • 31. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jtahlborn wrote:
    all i was addressing in your quote above was the classification as java being "wrong". i don't think anyone was arguing anything so strong, just that there might be scenarios where it would be convenient if Method and Constructor had a common interface/superclass.
    Ok.

    But my point was and still is that they are fundamentally different. And that rules out convenience. Especially when it just isn't that hard to deal with the two cases explicitly. And when one does deal with it explicitly it insures that the user must understand that there is in fact a fundamental difference.
  • 32. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    jschell wrote:
    jtahlborn wrote:
    all i was addressing in your quote above was the classification as java being "wrong". i don't think anyone was arguing anything so strong, just that there might be scenarios where it would be convenient if Method and Constructor had a common interface/superclass.
    Ok.

    But my point was and still is that they are fundamentally different. And that rules out convenience. Especially when it just isn't that hard to deal with the two cases explicitly. And when one does deal with it explicitly it insures that the user must understand that there is in fact a fundamental difference.
    Convenience was just a footnote in my reasoning. The primary reason is similarity. I think they have enough in common to warrant their own unique super class. Fundamental differences do not preclude two or more classes from having the same super class. The fact of the matter is that they already have a common super class: AccessibleObject, which also includes class Field. I'm merely talking about one more level of classification.
  • 33. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    sledged wrote:
    But my point was and still is that they are fundamentally different. And that rules out convenience. Especially when it just isn't that hard to deal with the two cases explicitly. And when one does deal with it explicitly it insures that the user must understand that there is in fact a fundamental difference.
    Convenience was just a footnote in my reasoning. The primary reason is similarity.
    I believe I provide a number of other examples that are similar as well. Yet attempting to merge them would not be a good idea.
    I think they have enough in common to warrant their own unique super class. Fundamental differences do not preclude two or more classes from having the same super class.
    First the analogy is not apt. You are attempting to use a general concept of all OO languages and then make it match your case which no OO language supports.
    Second you do not use inheritence in any OO language solely due to shared behavior. Doing so almost always indicates a bad design.
    The fact of the matter is that they already have a common super class: AccessibleObject, which also includes class Field. I'm merely talking about one more level of classification.
    Pretty sure they have Object as base as well. But that doesn't make either one a String which also has Object as a base.
  • 34. Re: Academic Question about Classes Method and Constructor
    jtahlborn Expert
    Currently Being Moderated
    Sledged, you aren't going to convince jschell.
  • 35. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    Hello sledged,

    I think a much cleaner solution (and much more academic too ;) would be structural types (scala supports them by the way).

    With kind regards
    Ben
  • 36. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    jtahlborn wrote:
    Sledged, you aren't going to convince jschell.
    I suppose not, but I wanted to give jschell the benefit of the doubt in regards to your comment about not being interested on seeing anyone else's point of view.
    BenSchulz wrote:
    Hello sledged,

    I think a much cleaner solution (and much more academic too ;) would be structural types (scala supports them by the way).

    With kind regards
    Ben
    Never used it. I'm guessing scala removes the need for extending classes and/or implementing interfaces?
  • 37. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    sledged wrote:
    jtahlborn wrote:
    Sledged, you aren't going to convince jschell.
    I suppose not, but I wanted to give jschell the benefit of the doubt in regards to your comment about not being interested on seeing anyone else's point of view.
    People have certainly convinced me in the past about other subjects when they presented arguments that convinced me about a particular subject.
  • 38. Re: Academic Question about Classes Method and Constructor
    jtahlborn Expert
    Currently Being Moderated
    So, suppose i define a class:
    public class Foo {
      public int x;
      public int y;
    
      public Foo( int newX, int newY) {  x = newX; y = newY; }
    
      public static Foo createFoo(int newX, int newY) {
        return new Foo(newX, newY);
      }
    }
    For the purposes of someone instantiating Foo there is absolutely no difference between calling "new Foo(5, 15)" and "Foo.createFoo(5, 15)". i'm not referring to the byte code generated or any fundamental principals of OO design, i'm talking about a programmer which wants to instantiate Foo.

    As such, if i define a framework which allows me to reflectively instantiate objects, and i want to handle constructors and static methods, i might define some utility classes like:
    public interface Instantiator<T> {
      public T create(Object... params);
    }
    
    public class ConstructorInstantiator<T> implements Instantiator<T> {
      private Constructor<T> _cons;
    
      public T create(Object... params) { 
        return _const.newInstance(params);
      }
    }
    
    public class StaticMethodInstantiator<T> implements Instantiator<T> {
      private Method<T> _meth;
    
      public T create(Object... params) {
        return _meth.invoke(null, params);
      }
    }
    Now, given this scenario, sledged made the (reasonable) observation that it might make sense if Method and Constructor shared an interface such that these two helper classes were unnecessary. And, from the perspective of of the framework implementor and the framework user, this is a perfectly reasonable suggestion. sledged didn't say that the concept of constructors and methods should be completely done away with, just that they share common behavior which could be reflected in the jdk API design without any hindrance to any other usage of Constructor and Method.
  • 39. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jtahlborn wrote:
    Now, given this scenario, sledged made the (reasonable) observation that it might make sense if Method and Constructor shared an interface such that these two helper classes were unnecessary. And, from the perspective of of the framework implementor and the framework user, this is a perfectly reasonable suggestion. sledged didn't say that the concept of constructors and methods should be completely done away with, just that they share common behavior which could be reflected in the jdk API design without any hindrance to any other usage of Constructor and Method.
    I understood the suggestion from the original post. As previously noted I have implemented factories and constructors dynamically before and done it in more than one language. I didn't consider it terribly complicated.

    How about providing an example of the significant behavior that this parent interface would have which would allow you to use the two interchangably?

    It seems to be that newInstance() would seem to be pretty significant on Constructor. I can't imagine how that would apply to Method.
    Conversely invoke() seems significant on Method but I can't see having that on Constructor.
  • 40. Re: Academic Question about Classes Method and Constructor
    jtahlborn Expert
    Currently Being Moderated
    jschell wrote:
    How about providing an example of the significant behavior that this parent interface would have which would allow you to use the two interchangably?

    It seems to be that newInstance() would seem to be pretty significant on Constructor. I can't imagine how that would apply to Method.
    Conversely invoke() seems significant on Method but I can't see having that on Constructor.
    it's comments like these which led to my side comments in my original post. this comment follows my assertion that you are making no attempt to see anyone else's point of view. is it really such of a stretch on your imagination to have a method on Constructor like:
      public T invoke(Object obj, Object... params) {
        if(obj != null) {
          throw new IllegalArgumentException("constructors do not take references");
        }
        return newInstance(params);
      }
    Which fulfills the contract of an interface like:
    public interface Invokable {
      public Object invoke(Object obj, Object... params);
    }
  • 41. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    jtahlborn wrote:
    public T invoke(Object obj, Object... params) {
    if(obj != null) {
    throw new IllegalArgumentException("constructors do not take references");
    }
    return newInstance(params);
    }
    Which fulfills the contract of an interface like:
    public interface Invokable {
    public Object invoke(Object obj, Object... params);
    }
    Alternatively, the first argument could be the enclosing instance for constructors of inner classes in a non-static context.
    public T invoke(Object object, Object... args) {
        Class<?> declaringClass = getDeclaringClass();
    
        if (declaringClass.getEnclosingClass() != null
                    && !isStatic(declaringClass.getModifiers())) {
            Object[] moreArgs = new Object[args.length + 1];
            moreArgs[0] = object;
            arraycopy(args, 0, moreArgs, 1, args.length);
            args = moreArgs;
        }
    
        return newInstance(args);
    }
    Which would be similar to how Method.invoke() treats the first argument based on whether the method is a static method or an instance method.
  • 42. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jtahlborn wrote:
    jschell wrote:
    How about providing an example of the significant behavior that this parent interface would have which would allow you to use the two interchangably?

    It seems to be that newInstance() would seem to be pretty significant on Constructor. I can't imagine how that would apply to Method.
    Conversely invoke() seems significant on Method but I can't see having that on Constructor.
    it's comments like these which led to my side comments in my original post. this comment follows my assertion that you are making no attempt to see anyone else's point of view. is it really such of a stretch on your imagination to have a method on Constructor like:
    Seems that I still have not made it clear.
    1. I understood what was being proposed in the very first post. I do not need examples, further clarification or any other additional data to understand the proposal. All such attempts here have not made the proposal any clearer nor in any way made me think that I didn't understand it completely in the first post.
    2. I understand how to promote such a call into a parent, whether an new parent or an existing one. Not only do I understand the potential interface but I also fairly confident that I could implement all of the needed functionality. I suspect it could be all implemented in java (and if not I am confident that I could dig through the existing java code to find the needed native methods.)
    3. I understand that it is convenient. Again that is something I understood from the first post.

    So getting beyond those two points what I am discussing is why that is consistent with terms of standard object oriented ideals.

    Or specifically in my case why it is not consistent.

    And convenience is not sufficient and at best is only a benefit that results from a decision based on other reasons.
    public T invoke(Object obj, Object... params) {
    That promotes a method call to a Constructor. It associates a "method" call (whetever the name) with something that conceptually represents the OO concept of construction.

    But construction is not a "method" call. Not in any of the three OO languages that I am familar with. Not in any book nor article that I have ever read on the subject. So that covers C++, C#, Java, Objective-C, Smalltalk and probably a couple of other niche ones as well.

    Can you provide some reference that suggests otherwise - in that one should think of construction as nothing more than a method call?
  • 43. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    sledged wrote:There's enough similarity between Method.invoke() and Constructor.newInstance() that they could be called by a single method specified by a common super class. The two classes even the same super class hierarchy and implement the same interfaces.

    It just seems that with the similarities, it's likely that this idea has already been conceived by the designers. So I'm led to conclude that there's probably a specific and pertinent reason why there's not a common super class for the two. My question is simply "What is that reason?"

    Or have I just come to the wrong conclusion, and there is no specific reason?
    If only there were a way to get a dev to weigh in on this one.

    My guess is that methods and constructors were first conceived and built separately, and all the gains you listed were probably not thought of or considered too trivial for the work and testing required in making any changes. Furthermore, I doubt the specification will ever change. The current paradigm is well entrenched now, and programmers don't like to fix what ain't broke enough.

    I also know from my limited experience that carrying around 6 or 7 levels of parent classes for any object can be very tedious. (I tried to write my own menu framework. Hell in a handbasket.) Although what you propose is only one more level of classification, sometimes it is nice to have all the code relevant for one method (or constructor) in one screen instead of spread across two (or more!) classes.

    Although academic questions are important, programming is ultimately more like plumbing than it is like wisened professorship. Practicality compromises with principle. (IMHO)
1 2 3 Previous Next