Inheritence of constructors

[joey-coleman]

The following bug was originally reported on Sourceforge by lausdahl, 2009-07-26 12:54:46:

Inheritence of constructors and use of default constructors from superclaser

Hi I found yet another difference from VDM Tools and VDMJ, which one is the correct one?

Constructor inheritance:

If a class (newA) interstates from aother class (newA) in VDM Tools the base classes constructor is still visible to the class inheriting:

Class baseA

public baseA : seq of char ==> baseA baseA(name)==…

end baseA

class newA is subclass of baseA

public newA : () ==> newA newA()==baseA(“test”);

end newA

This is allowed in VDM Tools

New newA(“New test class”); -- not allowed in VDMJ (Class has no constructor with these parameter types)

[joey-coleman]

Comment by nick_battle, 2009-07-27 15:41:59:

This was deliberately omitted in VDMJ, though I agree we should discuss why VDMTools is different in case there is a strong reason for allowing it.

My motivation was that other OO languages (Java, C++) do not do this, requiring that superclass constructors are called explicitly from subclass constructors. But I didn't investigate the reasons for this.

If this is allowed, it means that a subclass can always be constructed by calling one of its superclass constructors (true?). I can see that could be valid, but I cannot see how it can be universally safe. If the subclass had state that had to be initialized, it would mean that its constructor(s) could be bypassed, thus creating a subclass object which is not in a consistent state (if the constructor is responsible for its consistency).

[joey-coleman]

Comment by shinsahara, 2009-08-02 10:07:40:

I can't decide which is better on VDM++ user view.

[joey-coleman]

Comment by pglvdm, 2009-08-14 08:36:14:

Well I am surpriced to hear that this kind of inheritance of non-default constructors is NOT used in languages such as C++ and Java since my personal intuition would find this kind of inheritance of special constructors from superclasses in the way suggested by Kenneth very natural. However, if we adopt this it is naturally important to solve the issue about how this should effect the automatic code generation. I suppose that this does not immediately work with the VDMTools code generators but I must admit that I haven't tried it. Maybe Kenneth can experiment with that. If it is solvable here I would be in favor of this kind of inheritance.

[joey-coleman]

Comment by pglvdm, 2009-08-15 08:08:13:

I have been looking at some of the old VDM++ examples and as far as I can see the VDMUnit framework first introduced in the Enigma example from the VDM++ book depends on this kind of inheritance. So as far as I can see it is working in VDMTools whereas VDMJ gives type errors here.

[joey-coleman]

Comment by nick_battle, 2009-08-15 13:21:18:

I'm surprised you think this is "natural", Peter. The more I think about this, the more dangerous it seems to be. If you consider a constructor to be an object's "contract" with the world, to set itself up completely (and we have discussed previously whether class invariants should be suspended during construction for this reason - they should), then saying that a subclass can be constructed by just calling its parent's constructor(s) makes no sense. By definition, they cannot set up the state of the subclass, so unless you're very lucky, constructing a subclass object using the superclass constructor is a recipe for building inconsistent objects.

So I think C++, Java and friends (and VDMJ!) are right to omit constructor inheritance. If you want to engage a superclass constructor - and of course you have to at some level - you must explicitly call it from a subclass constructor (unless its the default).

You're right that VDMUnit depends on this, and it was one of the changes I had to make to get VDMJ to run the code. But as we've seen with POP3's "x := x", these published examples are not always perfect :-)

[joey-coleman]

Comment by shinsahara, 2009-08-15 23:20:21:

I've just remembered that following is the most important point.

NIck>>You're right that VDMUnit depends on this

FeliCa Networks already made 10 million test cases. And, SONY is making many test cases. CSK Systems made a few thousand test cases.

So, it is hard to change VDMTools as VDMJ, java, C++ style.

[joey-coleman]

Comment by nick_battle, 2009-08-16 15:58:06:

I'd need to see exactly how they've constructed their tests, Shin. But the "correction" would usually be a one-line fix injected into the subclasses concerned: "public subname: args ==> subname subname(args) == supername(args)". This is for anything that is a subclass of TestCase. A sed script might be able to fix it.

I appreciate that existing commercial usage is an important matter, but I'm trying to make a point about the language semantics. It is not unusual for compilers and other tools for evolving languages to have switches that indicate their level of compliance with standards (ie. such a new feature could be off by default, keeping your users happy).

[joey-coleman]

Comment by ardbeg1958, 2009-09-06 11:01:15:

I think eventually VDMTools should be changed to VDMJ/Java style in this issue. Constructors should not be inherited.

[joey-coleman]

Comment by nick_battle, 2009-09-21 09:23:01:

At the Language Board NM on 20th Sept 2009, the following was agreed:

VDM++ should adopt a C++ style for constructor chaining, given that both languages support multiple inheritance and suffer from the same problems as a result. The proposed grammar would be as follows:

class A is subclass of B, C operations public A: int * int A(x, y) B(x+1), C(x,y) == ...

i.e a constructor parameter pattern list is optionally followed by a list of initializers for its superclasses, each representing a call to a superclass constructor. This implies that superclasses are constructed before subclasses, and has a closer fit with other languages (for code generation, including C#) in that regard. Note that, unlike normal operations, the type signature of a constructor only defines the parameter types; the return type is implicit (like other OO languages).

We have yet to define the overall initialization ordering, especially regarding the initialization of instance variables and the ordering of super constructors in a hierarchy (though we note C++ defines this by the order in the class inheritance clause, not by the order of the upcalls in the constructor(s)). We also need to define the behaviour of default constructors in the new scheme (most likely called in order, if no explicit call made).

The meeting did not explicitly agree on whether inheritance of constructors should be supported. It was noted that FeliCa, who were thought to use many VDMUnit test cases that use this, would not have a problem if VDMTools was changed to remove constructor inheritance.

These changes would be introduced in "VDM-10".

This issue is now moved to the Discussion phase for general Overture community comment.

[joey-coleman]

Comment by nick_battle, 2009-11-02 13:26:58:

Withdrawn and replaced by issue 2890687 (VDM++ object oriented issues).

[joey-coleman]

Comment by nick_battle, 2009-11-02 13:29:12:

Closed

[joey-coleman]

Comment by nick_battle, 2013-06-14 15:27:07.576000:

• assigned_to: Nick Battle
• LRM updated: --> False
• VDMTools Implementation: -->
• VDMJ Implementation: -->