Si je comprends bien, ce que tu veux au final, c'est faire une bibliothèque (voire bibliothèque slash framework) pour C# qui intègrerait des concepts C# et Qt (donc plus loin qu'un binding). Si je reformule, ce serait une couche intermédiaire entre C# et Qt, et tu imagines que ça serait intéressant de virer toutes les autres API de C# de manière à ce qu'il ne reste plus que ta couche vers Qt. Là par contre, je ne comprends carrément plus.
Je trouve que l'idée de base est bonne (une bibliothèque C# pour Qt), mais je ne comprends pas le besoin de virer le reste. Il y a plein de choses couvertes par l'API C# qui ne le sont pas par Qt, ça me semble dommage de faire un RAZ de l'API (d'ailleurs tu ne justifies pas pourquoi tu veux te débarrasser de l'API actuelle de C#).
En tout cas, ça me semblerait plus facile à intégrer dans un environnement de développement en tant que bibliothèque additionnelle que comme "langage" (ça n'en serait pas un vraiment puisque ça reste du C#), incompatible avec le reste du monde (en l'occurrence, incompatible avec C++ ET avec le C# standard).
# pourquoi virer l'API standard de C# ?
Posté par davenouille . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 3.
Si je comprends bien, ce que tu veux au final, c'est faire une bibliothèque (voire bibliothèque slash framework) pour C# qui intègrerait des concepts C# et Qt (donc plus loin qu'un binding). Si je reformule, ce serait une couche intermédiaire entre C# et Qt, et tu imagines que ça serait intéressant de virer toutes les autres API de C# de manière à ce qu'il ne reste plus que ta couche vers Qt. Là par contre, je ne comprends carrément plus.
Je trouve que l'idée de base est bonne (une bibliothèque C# pour Qt), mais je ne comprends pas le besoin de virer le reste. Il y a plein de choses couvertes par l'API C# qui ne le sont pas par Qt, ça me semble dommage de faire un RAZ de l'API (d'ailleurs tu ne justifies pas pourquoi tu veux te débarrasser de l'API actuelle de C#).
En tout cas, ça me semblerait plus facile à intégrer dans un environnement de développement en tant que bibliothèque additionnelle que comme "langage" (ça n'en serait pas un vraiment puisque ça reste du C#), incompatible avec le reste du monde (en l'occurrence, incompatible avec C++ ET avec le C# standard).