3 ms·

Can you explain a little why reflection is important in GUI development?

humanrebar 12y ago
To be clear, in any Turing-complete language you can do anything (more or less). However, many things often require a lot of boilerplate, especially involving metadata: Does it display text? How do you get its name? Does it have its own thread? Does it have any XML-configurable attributes? Often, especially in C++, that boilerplate is created through code-generating tools (like WYSIWYG editors), which is fine for many use cases... all of the metadata, getters, setters, and wiring logic are churned out for you. There are drawbacks to that approach, including many of the same limitations to WYSIWYG HTML/CSS tools (which I guess is a special kind of GUI development). One way to improve the situation is to allow for more compile-time and/or runtime dependency injection in C++ code. It's not a silver bullet, but it's a tried-and-true model for other kinds of frameworks in various languages. In other words, why don't we see a Sinatra or a Spring in C++ land? Some people may think this is a feature, not a bug, but I submit the lack of those types of frameworks is due to a limitation of the language, not a lack of interest. To get to the point of C++ GUI frameworks, however, some basic building blocks are needed. Especially of note are reflection mechanisms. For example, attributes on types, functions, and objects that can be inspected in code (constexpr or not). This is a fairly involved subject worthy of a series of blog posts (with examples) instead of a single comment in a comment thread. But I hope I got the general idea across.
- pkolaczk 12y ago
  Many of the usecases where reflection is used could be also addressed with metaprogramming. This is probably why so many C++ GUI frameworks still use C macros and/or code generators. So I guess C++ not only needs reflection, but also much better metaprogramming capabilities. Template metaprogramming is considered awesome by some academics (being accidentally Turing-complete), but in fact it is quite limited compared to good macro systems.

To be clear, in any Turing-complete language you can do anything (more or less). However, many things often require a lot of boilerplate, especially involving metadata: Does it display text? How do you get its name? Does it have its own thread? Does it have any XML-configurable attributes? Often, especially in C++, that boilerplate is created through code-generating tools (like WYSIWYG editors), which is fine for many use cases... all of the metadata, getters, setters, and wiring logic are churned out for you. There are drawbacks to that approach, including many of the same limitations to WYSIWYG HTML/CSS tools (which I guess is a special kind of GUI development). One way to improve the situation is to allow for more compile-time and/or runtime dependency injection in C++ code. It's not a silver bullet, but it's a tried-and-true model for other kinds of frameworks in various languages. In other words, why don't we see a Sinatra or a Spring in C++ land? Some people may think this is a feature, not a bug, but I submit the lack of those types of frameworks is due to a limitation of the language, not a lack of interest. To get to the point of C++ GUI frameworks, however, some basic building blocks are needed. Especially of note are reflection mechanisms. For example, attributes on types, functions, and objects that can be inspected in code (constexpr or not). This is a fairly involved subject worthy of a series of blog posts (with examples) instead of a single comment in a comment thread. But I hope I got the general idea across.

pkolaczk 12y ago
Many of the usecases where reflection is used could be also addressed with metaprogramming. This is probably why so many C++ GUI frameworks still use C macros and/or code generators. So I guess C++ not only needs reflection, but also much better metaprogramming capabilities. Template metaprogramming is considered awesome by some academics (being accidentally Turing-complete), but in fact it is quite limited compared to good macro systems.