[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