InheritBaseConstructors ast attribute

As said on the list thread ( http://groups.google.com/group/boolang/browse_thread/thread/bcb090c5ef4956bf ), I don't think this is a good idea.
When you add a specific constructor to ChildClass then it would silently break all external code using the implicitely inherited constructors !

If you add virtual function to ChildClass it silently breaks implicitely inherited function. This is not bad
and absolutely logically.

Who talked about virtual function? (and i guess you meant the method job() from your example?)
the problem is with constructors here.

If we were to implement your idea here what would happen :

class a:
def constructor():
pass
def constructor(a as int):
pass
class b(a):
pass

d = b(1) //ок

then when you add a specific constructor to class b:

class b(a):
def constructor(just_added_constructor as string):
pass

d = b(1) // compiler error: b has no constructor for argument int

which is everything but obvious, and goes completely under the radar if the class b gets constructed in a external assembly.

>I agree the code becames incorrect if add constructor to b and the code uses generated constructor.
>But Boo gives message about it.
Boo has no way to give a message if the class b is used by another assembly.
Think class b is in a library used by third-parties (moreover possibly in another .NET language).

>Default behavior( generation for no constructor class) is logic.
Logic, in someway I agree. Obvious, it isn't (especially if you comes from most other languages C#, Java, C++ included ).

>And usefull for several real cases.
I agree, it would save a little typing, but I don't think it deserves the term "useful" because it's really no more than a shortcut to not write the constructors "stubs". Probably "handy" is more appropriate if there would be no drawbacks doing it this way.
And the typing advantage would completely go away when you need to add another constructor (then you'll have to write the constructors stubs anyways).

>I said If you change parameter list for function using it code becomes incorrect.
>But we don't worry about it. This situation is similar to it.
When you change the parameter list of a method it is obvious that you break the API.
Something similar would be that when you add a new method it breaks the API, which is absolutely not obvious and would be something to worry

I think a better solution here would be to have a AST attribute [InheritBaseConstructors] to explicitly say you want to inherit classes, since doing it implicitly would cause the problem demonstrated above. It still saves a lot of typing AND has the added advantage that you can use it even if your class b do have specific constructors

"When you add a specific constructor to ChildClass then it would silently break all external code using the implicitely inherited constructors !"

Why? With the code...

class ParentClass():
def constructor(x as int):
print "You're constructing with an integer."

class ChildClass(ParentClass):
pass

The last two lines could translate to (before compilation):

class ChildClass(ParentClass):
def constructor(*args):
super(*args)

And with the code:

class ParentClass():
def constructor(x as int):
print "You're constructing with an integer."

class ChildClass(ParentClass):
def constructor(x as string):
print "You're constructing with a string."

The last three lines could translate to:

class ChildClass(ParentClass):
def constructor(x as string):
print "You're constructing with a string."
def constructor(*args): # 'inheritance' is here
super(*args)