base and self built-in keywords

[sergeik...@gmail.com]

Obvious need to access base classes often. Lets add `base` keyword like c# has.

pros:

   cozy template inheritance

   deduplication

   slim commit history

`self` keyword might be also useful cozy to use for macro-templating.

[sergeik...@gmail.com]

class Product

    : public ValuableCollectionDescendantContract<Product, std::set<Variable>>

{

    using base = ValuableCollectionDescendantContract<Product, std::set<Variable>>;

    using cont = std::set<Variable>;

  look and feel better, deduplication >>>>

class Product

    : public ValuableCollectionDescendantContract<Product, std::set<Variable>>

{

    using base::cont;

воскресенье, 1 октября 2017 г., 9:00:32 UTC+3 пользователь sergeik...@gmail.com написал:

[Nicol Bolas]

On Sunday, October 1, 2017 at 2:00:32 AM UTC-4, sergeik...@gmail.com wrote:

Obvious need to access base classes often.

We do? I don't. Then again, I don't use base classes that often, so...

Furthermore, C++ has multiple inheritance, so now you have to decide which base you're talking about. Now, that could actually be an interesting and useful construct: `base<I>` would resolve to the `I`th base class of the class in question. And reflection wouldn't be as good in this case, since a keyword (or whatever) would be able to use the current context to know which class to get the base class of. Reflection-based mechanisms would require that we specify which class we're talking about.

[Niall Douglas]

Furthermore, C++ has multiple inheritance, so now you have to decide which base you're talking about. Now, that could actually be an interesting and useful construct: `base<I>` would resolve to the `I`th base class of the class in question. And reflection wouldn't be as good in this case, since a keyword (or whatever) would be able to use the current context to know which class to get the base class of. Reflection-based mechanisms would require that we specify which class we're talking about.

Python supports multiple inheritance too and I'd suggest you clone their super() function rather than invent anything new.

Niall

[Arthur O'Dwyer]

On Sunday, October 1, 2017 at 4:16:02 PM UTC-7, Niall Douglas wrote:

Furthermore, C++ has multiple inheritance, so now you have to decide which base you're talking about. Now, that could actually be an interesting and useful construct: `base<I>` would resolve to the `I`th base class of the class in question. And reflection wouldn't be as good in this case, since a keyword (or whatever) would be able to use the current context to know which class to get the base class of. Reflection-based mechanisms would require that we specify which class we're talking about.

Python supports multiple inheritance too and I'd suggest you clone their super() function rather than invent anything new.

Oh dear. Literally anything would be better than Python's super() function.

Python invents a sort of linearization of the multiple-inheritance tree (the MRO) so that you can manually call super-class __init__ routines (or not) as you choose; i.e., Python does not have the concept of "constructor" as we understand it in C++. It's more like Objective-C's init routines. In my experience it's basically impossible to use correctly; if you're doing multiple inheritance in Python you're probably doing something wrong whether you're aware of it or not.

(In Python 2 super() requires repeating the name of your own class anyway, where repetition of class names was the original problem OP wanted to solve. But I see that the repetition has been dropped from Python 3 — cool! This tutorial seems fair and balanced to me, and covers the syntax in both dialects of Python.)

This blog post points out something I'd never consciously considered before: Python has no non-virtual inheritance (I think?). Of course the calling of virtual base constructors is a source of confusion in C++ just as much as in Python, but at least C++ doesn't let you call your base subobjects' constructors manually.

Not that I'd want to invent anything new either, mind you.

The OP's problem could be solved in C++03/11/14/17 with the following, which is how it's done in practice and I don't see anything wrong with it:

    class Derived : public Base {

        using base_type = Base;  // one awkward repetition

        [...]

    };

Or, theoretically, in C++17 we could start writing the following and relying on constructor template argument deduction to omit the empty angle brackets in the usual case. I haven't tried this in practice:

    template<class base_type = Base>  // zero awkward repetitions

    class Derived : public base_type {

        [...]

    };

Anyway, I don't think there's any problem to be solved here. Certainly I don't think C++ should introduce any special syntax for the "I'th base class." If you want something like that, you probably want Herb Sutter's metaclasses (or better) anyway.

my $.02,

Arthur

[Niall Douglas]

Python supports multiple inheritance too and I'd suggest you clone their super() function rather than invent anything new.

Oh dear. Literally anything would be better than Python's super() function.

Python invents a sort of linearization of the multiple-inheritance tree (the MRO) so that you can manually call super-class __init__ routines (or not) as you choose; i.e., Python does not have the concept of "constructor" as we understand it in C++. It's more like Objective-C's init routines.

A more accurate explanation is that super() would return the native vtable for the selected inherited class.

 

In my experience it's basically impossible to use correctly; if you're doing multiple inheritance in Python you're probably doing something wrong whether you're aware of it or not.

(In Python 2 super() requires repeating the name of your own class anyway, where repetition of class names was the original problem OP wanted to solve. But I see that the repetition has been dropped from Python 3 — cool! This tutorial seems fair and balanced to me, and covers the syntax in both dialects of Python.)

Multiple inheritance is exactly as useful in Python as in C++. Usually best sparingly, but when it's useful, it's useful, plus the same metaprogramming tricks are available in Python's multiple inheritance as in C++. And I've seen no trouble in using it correctly, you can have recursive nestings of eval() specialised fragments assembled together and it all works fine, including super() to traverse the hierarchy.

Python's really great. Such a deep well of evil power available to the programmer.

 

This blog post points out something I'd never consciously considered before: Python has no non-virtual inheritance (I think?).

More that virtual inheritance is the default for all member functions. You need to explicitly ask to call a non-virtualised implementation, which is via super() actually.

 

Anyway, I don't think there's any problem to be solved here. Certainly I don't think C++ should introduce any special syntax for the "I'th base class." If you want something like that, you probably want Herb Sutter's metaclasses (or better) anyway.

Reserving self and base for Herb's metaclasses, now that is something I can agree 110% with.

Niall

[Сергей Кривонос]

Hi Arthur,

 

Making template of a class is deduplication. But it makes compilation much longer. And allows unproper use unless we enforce specific base by static assert.

A compilation error message may be shown in case of any collisions.

 

 

От: Arthur O'Dwyer
Отправлено: понедельник, 2 октября 2017 г. в 08:31
Кому: ISO C++ Standard - Future Proposals
Копия: sergeik...@gmail.com
Тема: Re: base and self built-in keywords

[Arthur O'Dwyer]

On Mon, Oct 2, 2017 at 7:29 AM, Niall Douglas <nialldo...@gmail.com> wrote:

Python supports multiple inheritance too and I'd suggest you clone their super() function rather than invent anything new.

Oh dear. Literally anything would be better than Python's super() function.

Python invents a sort of linearization of the multiple-inheritance tree (the MRO) so that you can manually call super-class __init__ routines (or not) as you choose; i.e., Python does not have the concept of "constructor" as we understand it in C++. It's more like Objective-C's init routines.

A more accurate explanation is that super() would return the native vtable for the selected inherited class.

Yes, but if we were copying Python, it still wouldn't necessarily be the specific base class that the OP wanted; it would just be the next base class in the Method Resolution Order. It would have to be determined dynamically, depending on the most-derived-type of *this.

But I think we're arguing over a hypothetical at this point.

Python's really great. Such a deep well of evil power available to the programmer.

We agree on both of those sentences. :)

 

This blog post points out something I'd never consciously considered before: Python has no non-virtual inheritance (I think?).

More that virtual inheritance is the default for all member functions. You need to explicitly ask to call a non-virtualised implementation, which is via super() actually.

Well yeah all dispatch is virtual. But I meant virtual inheritance, i.e.

class Animal(object): pass

class Cat(Animal): pass

class Dog(Animal): pass

class CatDog(Cat, Dog): pass

As far as I understand it from like five minutes of research yesterday — so, not a lot — there's no sense in which CatDog has "two" Animal base subobjects.(*) Whereas in C++ it would have two Animal base subobjects, unless you added a couple of "virtual" keywords.

(* – I am quite possibly wrong. The CatDog does clearly "remember" its Animal member behaviors somehow, so it is not completely far-fetched to me that it could "remember" its Animal instance variables. But that's not my current mental model of how Python works. Arguably CatDog doesn't even have any Animal "base subobjects" and Python doesn't recognize the concept of "subobject"; Animal methods work on CatDog only because duck-typing.)

–Arthur