A Summary of the Metaclasses Proposal for C++ | Hacker News Reader

A Summary of the Metaclasses Proposal for C++

fluentcpp.com

40 pointsPleaseHelpMe18 comments

I'm torn about this proposal. One one hand, I like that the feature generalized something that you can (for the most part) already do in C++, and I like the new expressiveness metaclasses would provide.

On the other hand, this is kind of insane. C++ is insane. And I'm still not convinced this proposal is more than another bandaid over the fundamental problems with the language. Why do our programming languages keep ending up as terribly complicated and incomplete specifications of scheme or smalltalk?

I don't have a better proposal though and do admire the thought and effort given to retrofitting C++ as a modern language

But C++ has always been a "modern a language". In the sense that there is nothing "obsolete" about it. Yes, it is complicated, but so is math, for example. Programming is complicated. Real world programming, that is. C++ is "complicated" because it is designed to address real life problems. It was designed based on a well-defined set of design criteria. Which are different from those Java's and JavaScript's designs were based on. If you are to question the sanity of C++, question those criteria.

My first reaction to $class was the following: since we are talking about metaclasses, why not use that name instead, that is "metaclass" in place of "$class"?

Not sure what you mean exactly, but $class is just an example, you can also have $interface $sometypeofstruct $unmutablevaluetype etc so prefixing that all with 'meta' would be a mess

In the proposal, '$class' is actually the proposed keyword for introducing a metaclass; you won't continue to use '$' for all of the classes created from that metaclass. stephen82 is suggesting that we use the keyword 'metaclass' instead, which I probably prefer.

I would guess it's because someone might be using the name metaclass as an identifier in their code and therefore appropriating it as a keyword would potentially break programs.

$class on the other hand is guaranteed not to conflict with any existing code.

I don't see this making it into the standard.

1. Interface = abstract class, already present.

2. Reflection, rtti is sparsely used because c++ is primarily used for speed and large teams.

3. Reserved words prefixed by $, etc. Well, outside of a preprocessor directives, that will be a first , if it ever happens.

By the look of the thing, the author wants c++ to be more like c#. But c++ isn't restricting on patterns, we create them. Unlike c# there is no language defined way for dependency injection, interfaces etc. Well we can argue that, but c++ is more flexible on pattern creation, and this proposal wants to put two patterns inside the standard. I just don't see it happening.

1. It's about abstracting what "classes" are, since the built-in "class" metaclass is trying to be one-size-fits-all. Yes, an interface is an abstract class, and if you could do things like make your own "interface" metaclass, then you can "create more patterns," in your words.

2. This is compile-time reflection, which is how a metaclass generates code, so there shouldn't be much of a run-time speed consideration. I think the comparison with C# isn't quite right; if anything, the author wants C++ to be more like Lisp, Smalltalk, or even Python, which all have at least some semblance of a meta-object protocol (and code-writing code, in the case of Lisp).

1. Classes itself can be improved, but at this point, will they date breaking compatibility? Maybe from that perspective this will be given a shot.

2. More code at compile time would work. Pythinizing may work. Lisp is quite different.

Indeed. I think this is one of the best things about the proposal: it offers a way out of the current hardcoded behaviours. At the moment we barely even think about whether or not they're correct, because they're obviously too hard to opt out of.

If anything, the proposal corners people into more hardcoded behaviours.

Don't see why, you don't have to use the keywords given, and in the future existing keywords could be deprecated.

indeed, there is one thing i don't understand: why $class and not metaclass...

It can be $meta-class::class :)

Keep in mind simple=elegant is not in everybody's eyes.

1. $interface is just one example. Look at the $value example and defining an operator == which automatically works for all members: that does not yet exist 2. Some (or all? not sure..) of the reflection capabilities this brings are compile-time so no runtime speed penalty 3. There's a first for everything :]

That being said, I'm also not sure it if will make it to the standard but for different reasons; mainly that it's a pretty huge change and will make C++ even more mature/difficult/one language to rule them all/easier to rant on/...

If a metaclass is a way to make classes, can you have a meta-metaclass that makes metaclasses? Meta-meta-metaclasses to make meta-metaclasses? (etc)

funny how D already solves all these issues.

From the article:

> "Compile-time programming consists in defining a region in the codeline where the code is meant to be executed at compile time, with the evaluation of compile time data leading to a result. "

Wow, great. So in 2017, C++ is finally able to have a feature that Lisp had since about 1966.

Yes, you can call this comment "smug", but my point is less smug and it's the following:

C++ has been bloated too much. It used to be a nice OO language -perhaps not as elegant as Objective C- but, as the times advanced, good-intentioned people retrofitted more and more characteristics into C++, but the side efects of these "retrofits" is a chaos that is ultimately leading to more criticism of C++ and more people getting interested in alternatives like Julia and Rust.

Julia in particular has a very interesting OOP implementation that includes multiple dispatch, and also has good support for metaprogramming.

Rust, as I see it, is a good alternative to C++, and should also work for systems programming.

Reply on news.ycombinator.com