1 2 3 Previous Next 43 Replies Latest reply: Jan 22, 2010 9:19 AM by 791266 Go to original post RSS
      • 30. Re: force implemention of constructors ?
        jschellSomeoneStoleMyAlias
        I suppose it is simply a matter of tradeoffs.
        You can't have a relatively simple language that also
        provides a lot of power and yet provides a complete
        set of protection mechanisms for all types of usage.
        I suppose ... but there must have been (or at least I
        hope there was) a
        good reason for leaving it out, and I'm just wondering
        at what it could
        be ...
        Why leave out any of a multitude of small little enhancements that for a limited number of cases would have provided a small enhancement in implementation convienence?

        Because when you add all of them in it makes the language much more complex. Which besides making it much harder to learn and understand, makes compilers harder to right and will also eventually lead to some mutually-exclusive situations that can not be resolved without simply making arbritrary decisions.

        Consider this, I would consider destructors a very nice addition to the language. But to do that correctly (so that they are effective) would require that the VM, not just the compiler, has an extensive understanding of the scope of every variable. That would make applications run slower. Perhaps not significantly (although I suspect measurably.) And that would apply to all applications whether they used destructors or not.


        • 31. Re: force implemention of constructors ?
          3004
          Desired behaviour:
          abstract class Engine {
          public abstract Engine(String url);
          public abstract Engine(java.io.File directory);
          }
          
          
          class AnalysingEngine extends Engine {
          public AnalysingEngine(String url){
          /**
          * Note the abscense of "super(url);".
          */
          Okay, why? What does that have to do with what you're talking about? Is it implicitly called? What's the point?
          }

          /**
          * Compile-time error if left out.
          */
          public AnalysingEngine(java.io.File directory){
          }
          } get it ? :)
          Yes, this is as I originally pictured what you were talking about.

          Now, do AnalysingEngine's subclasses also have to have those two constructors? Or does the requirement only extend to the immediate subclass?
          class BetterAnalysingEngine extends AnalysingEngine {
                  private final BetterizingThingy bt_; // assume there's no reasonable default value could apply here
          
                  public BetterAnalysingEngine(String url, BetterizingThingy bt) {
                      super(url); // or not, if you're saying this is implicitly called
                      bt_ = bt;
                  }
          
                  public BetterAnalysingEngine(File dir, BetterizingThingy bt) {
                      super(dir); // or not, if you're saying this is implicitly called
                      bt_ = bt;
                  }
           
                  //
                  // Do you require this constructor? This class CANNOT support this one.
                  //
                  public BetterAnalysingEngine(String url) {
                      super(url); // or not, if you're saying this is implicitly called
                      bt_ = ??????;
                  }
          
                  //
                  // Do you require this constructor? This class CANNOT support this one.
                  //
                  public BetterAnalysingEngine(File dir) {
                      super(dir); // or not, if you're saying this is implicitly called
                      bt_ = ??????;
                  }
          }
          Again, though, why would you want to enforce a particular constructor signature? What do you care about where a subclass gets its state from? Are you trying to enforce that it calls a particular super ctor? If so, why do you care if the concrete class gets the url as a ctor arg or by reading a config file? Can you provide an example of how you'd actually use this feature?

          ¶
          • 32. Re: force implemention of constructors ?
            843798
            /**
            * Note the abscense of "super(url);".
            */
            Okay, why? What does that have to do with what you're
            talking about? Is it implicitly called? What's the
            point?
            Just a note that there isn't really a super constructor (as in the "Current
            Behaviour") only a specification for one in the child class.

            Now, do AnalysingEngine's subclasses also have to have
            those two constructors? Or does the requirement only
            extend to the immediate subclass?
            Yes - just like normal rules for the abstract keyword.

            public BetterAnalysingEngine(String url,
            BetterizingThingy bt) {
            super(url); // or not, if you're saying this is
            implicitly called
            No, and this would be valid ... the abstract class just defines an
            abstract constructor in the exact same way it defines a abstract
            method.

            Again, though, why would you want to enforce a
            particular constructor signature? What do you care
            about where a subclass gets its state from?
            Because I want to ensure all child classes have a specific
            way of being instantiated, i.e. they are forced to implemented
            all abstract constructors.

            Usefulness is that developers are required to implement this
            functionality and it doesn't have to be "faked" via "init()" methods
            and so on.

            Are you
            trying to enforce that it calls a particular super
            ctor?
            No.
            • 33. Re: force implemention of constructors ?
              843798
              and lets not forget that abstract classes
              already do this
              for one constructor ... the problem is
              that you can't
              do it for more then one, and require that
              each one
              is implemented.
              Abstract doesn't have anything to do with that
              though.
              Why not ?
              Because it applies to non-abstract classes as well -
              right?
              still a bit lost here .... I am talking about being able to specify multiple
              constructors to be implemented by children ... why isn't abstract
              appropriate for that ?
              • 34. Re: force implemention of constructors ?
                jschellSomeoneStoleMyAlias
                >>
                Because it applies to non-abstract classes as well -
                right?
                still a bit lost here .... I am talking about being
                able to specify multiple
                constructors to be implemented by children ... why
                isn't abstract
                appropriate for that ?
                In reply 20 you said....


                and lets not forget that abstract classes already do this
                for one constructor


                You were referring to the default ctor right?

                If so then it applies to all classes and not just abstract ones.
                • 35. Re: force implemention of constructors ?
                  843798
                  You were referring to the default ctor right?
                  no...

                  I was commenting on this behavior:
                  abstract class Joe {
                    public Joe(int k){ }
                  }
                  class JoeSchmoe extends Joe {
                  }
                  you can't compile Joe without placing a call to "super(int k)"
                  somewhere i.e assumedly in your JoeSchmoe(int k) method (but
                  it doesn't have to be).
                  • 36. Re: force implemention of constructors ?
                    jschellSomeoneStoleMyAlias
                    You were referring to the default ctor right?
                    no...

                    I was commenting on this behavior:
                    And does that not apply to non-abstract classes as well?
                    • 37. Re: force implemention of constructors ?
                      843798
                      You were referring to the default ctor right?
                      no...

                      I was commenting on this behavior:
                      And does that not apply to non-abstract classes as
                      well?
                      yes. it does ... so more what im after is forcing the impl
                      of the public Name(int k){} part, and not the call to super.

                      lets just forget i made the comment, its confusing the
                      main point - to be able to require children to implement
                      constructors as specified in the abstract class ... :)
                      • 38. Re: force implemention of constructors ?
                        3004
                        Now, do AnalysingEngine's subclasses also have to
                        have
                        those two constructors? Or does the requirement only
                        extend to the immediate subclass?
                        Yes - just like normal rules for the abstract
                        keyword.
                        Yes which one? Yes, ubclasses also have to have those 2 ctors, or yes only immediate subclass (i.e. first concrete class has to have them?

                        "Just like normal rules for abstract" isn't clear here, since normal rules are that all subclasses have to provide the method, but they can do so by inheriting it from super. Since ctors aren't inherited, you'll need to spell out what you mean here.

                        If it is that subclasses also have to provide that ctor--i.e. I can do new Sub(String url) and new SubSub(String url), etc.--then you are now disallowing the situation I described--namely that a subclass has additional state that has to be provided at construction time.

                        Again, though, why would you want to enforce a
                        particular constructor signature? What do you care
                        about where a subclass gets its state from?
                        Because I want to ensure all child classes have a
                        specific
                        way of being instantiated, i.e. they are forced to
                        implemented
                        all abstract constructors.
                        But why? Why do you care how they're instantiated? You care about implementing an interface or implementing abstract methods declared in abstract parent classes because you want to be able to use Derived wherever Base is specified. But why do you want to force a particular ctor? "Using Derived where Base is specified" doesn't apply here, as far as I can tell.
                        Usefulness is that developers are required to
                        implement this
                        functionality and it doesn't have to be "faked" via
                        "init()" methods
                        and so on.
                        Why is it useful to ensure the ability to construct a certain way? Can you give an example of how you'd use this?
                        • 39. Re: force implemention of constructors ?
                          843798
                          Yes which one? Yes, ubclasses also have to have those 2 ctors,
                          or yes only immediate subclass (i.e. first concrete class has to have them?
                          Sorry, when replying i forgot that ctors aren't inheritied (how could I do that !)... :)

                          So yes - all children of children must implement the ctors too (thinking
                          about this now, it seems a little silly, but I will keep going).

                          then you are now disallowing the situation I described--namely
                          that a subclass has additional state that has to be provided at construction time.
                          Hmm.

                          Okay ... well, for now, I can't think of a response to this ... it seems my
                          plan seems to only work 1 class-level deep .. :)

                          "Using Derived where Base is specified" doesn't apply here, as far as I can tell.
                          Yeah, it was more about being able to specify: "This is what the class can do (abstract
                          methods) and this is how you can get one (constructors)." ... i hope you can see what
                          I mean :)

                          Infact, it seems more that this sort of thing i'm after is a documentation (and
                          validation ?) tool, not an addition to the language ...

                          until I come up with more ideas ... thanks for the discussion :)
                          • 40. Re: force implemention of constructors ?
                            843798
                            I believe that abstract constructors are not allowed in Java because constructors are used for initialising state of an object.
                            abstract methods (whether within interfaces or abstract classes) define behaviour for the object.

                            This has all been said before in the thread, but what is now the actual difference between the two and why does this mean that abstract constructors are not allowed?



                            1 - OO-Rule: all objects should be in a valid state after construction:
                            This rule can be broken when abstract constructors are allowed.
                            Example:
                            I make an object which does some calculations on an URL (as proposed before in the thread)
                            Suppose that I can force a constructor taking this URL as input within the abstract class (or interface).
                            Everything runs fine, until I want to create a new class which takes two URL's and which can choose between one of the two (for instance for reducing the downtime of the application). The constructor for this class should always contain the two URL's. This new object which has the same behaviour, can not be constructed in a valid way using the abstract constructor. No simple solution exists for such case, unless we drop the abstract constructor.
                            When the abstract class containing the abstract constructor is not your property (bought jar-file) this is a blocking problem.
                            Other examples could be: taking two URL's - one for security-check and one for calculations, taking an URL and an integer-value (for time-out)...



                            2 - OO-Rule: encapsulation/polymorphism (implementation hidden for the user)
                            By defining the constructor, encapsulation is broken. This will also steer towards some implementation of the interface/abstract methods.
                            Example:
                            I have a algorithm which calculates with some numeric values and returns some result as an integer-value. I can encapsulate this algorithm as an interface with the following implementation:

                            public interface Algorithm{

                            public int calculate(double numericValue, double otherNumericValue);

                            }

                            This is the normal implementation, and has the advantage that all Algorithms can be plugged in the same manner within some larger algorithm.
                            This kind of Algorithms will always depend on a random-number for doing the calculations.
                            I change the interface to the following interface:

                            public interface Algorithm{

                            public Algorithm(Random random);
                            public int calculate(double numericValue, double otherNumericValue);

                            }

                            Totally logical use of an abstract constructor seems to me. But this interface will prevent me from using for instance the Random-algorithm as defined in colt, or some other library. This interface will force me to always implement this Algorithm using the normal Random.
                            When translating this to the problem suggested:
                            why don't we work with URI's instead of URL's? Why don't we work with some InputStream instead of some URL? These examples all cause problems which are only related to the kind of state and implementation, while the behaviour causes no problems.



                            3 - More conflicts between interfaces and patterns:
                            Making an interface for the persistence of the object would probably contain the definition of an abstract
                            empty constructor. This way the persistence comes down to calling the known constructor and filling the
                            fields of the constructed object with persisted data. I worked with Castor (exolab), which used to work this
                            way. This introduces the need for public empty constructors. Persisting immutable classes is impossible with this framework. These two requirements are however not contradictory.



                            I also would like to say that some possible solutions exist for such problems:
                            - using Factories or Abstract Factories
                            - using some reflective framework
                            - nothing prevents you from doing the same thing without defining abstract constructors (through some naming convention)



                            hope this makes sense and clarifies some problems :-)

                            kind regards,
                            Koen
                            • 41. Re: force implemention of constructors ?
                              843798
                              I followed the track and in my reply 16 mentioned the
                              need of defining constructors signatures in case
                              you are working with generics. Just to require a
                              no-args-constructor as in -3- (Castor) is not
                              feasible, Allen (IBM) proposed annotations (see
                              "Diagnosing Java Code" part 4 in developerWorks).


                              • 42. Re: force implemention of constructors ?
                                843798
                                rkippen says:
                                Hypothetically speaking, if interfaces did allow you do specify the constructor then
                                given a reference to a Class object, you could test assignability to the interface,
                                and if it returned true, then you could call the getConstructor(Class[]) method
                                without having to do a lot of extra programming using reflection...
                                This is basically achievable anyway; use an abstract initialize(...) method, and assume a no-argument constructor.

                                I can't say it's my favorite pattern, but I've seen it far more often than I'd like to admit.
                                • 43. Re: force implemention of constructors ?
                                  791266
                                  >

                                  Hi,

                                  Please, don't resurrect old threads. I'm locking this zombie.

                                  Kaj
                                  1 2 3 Previous Next