[C++-sig] Re: (return_self_policy / return_arg): Keywors

Nikolay Mladenov nickm at sitius.com
Sat Jul 5 05:20:13 CEST 2003


David Abrahams wrote:
> >> Maybe we should deprecate the def() way and provide a mechanism for
> >> chaining init<...>() instances in the class_<...> constructor
> >> (e.g. with commas).  At least that would focus all attention in the
> >> same place.
> >
> > I would better like it if def is the only way of defining constructors.
> > Initially I thought that staticmethod should be implemented as policy,
> > but you convinced me into the "python"-ian way: staticmethod is a
> > statement in python.
> > Well so is __init__, and in python it is def'ed as any other
> > method.
> 
> Well, that's a good point.


So you agree here.


> 
> > Why should we explicitly specify that the class is not constructable
> > (with no_init) (the c++ way),
> > instead of explicitly exporting constructor with def (the python way).
> > "There should be one-- and preferably only one --obvious way to do it"
> > ;-)
> > and def should be it for exporting methods:)
> 
> I understand the principle, but sometimes you have to make compromises
> at the language boundary.  Besides, not having to explicitly specify
> default constructors is both the C++ and the Python way.  Consider:
> 
>          >>> class Foo:
>          ...     pass  # no explicit __init__
>          ...
>          >>> x = Foo() # OK
> 
>          struct Foo {}; // no explicit constructor
>          Foo x;         // OK
> 
> Why should I have to write an explicit __init__ in order to expose
> Foo to Python?


And I do here.

> 
> > I have exported a lot non-constructable classes as bases and as
> > collections of staticmethods.
> 
> Yes, but at least if the class is abstract you'll get a compile-time
> error if you don't supply no_init, while if we eliminate the default
> constructor definition compiling and linking would succeed for default
> constructible classes, but fail at runtime when you try to instantiate
> them (unless you remember the init<...>(), which maybe doesn't appear
> anywhere in the C++ class declaration).  I consider failing at compile
> time to be far superior.

And completely agree here

Ok. I see the dilemma. And I'm starting see your point about the comma
separated inits, 
though I wouldn't really enjoy writing them.

But this is getting a little bit far from the keywords, and the init
problem really got me cycling.

>
> I guess I'm not feeling quite *that* relaxed yet ;-)
> 

So, do you feel we have differences left about the keywords?





More information about the Cplusplus-sig mailing list