Dev Faq
12
votes

Le C # Spec (équipe? Comité?) A déjà examiné cette syntaxe de création d'objet?

Je n'ai jamais posté une question de cette nature avant, alors si ce n'est pas approprié pour le cas, ne faites pas de mal à mes sentiments davantage et je vais le supprimer.

L'intérêt de garder tout ce qui me souciait aussi près que possible de la marge gauche possible, je continue à souhaiter que je puisse écrire quelque chose comme: xxx

Je pense qu'une autre raison est que j'aime l'extra Écran Immobilier Je reçois à l'aide de Var lorsque le type est déjà présent sur le côté droit de l'affectation, mais mon cerveau a trop d'années de recherche du type sur le côté gauche. Encore une fois, être coincé dans mes voies n'est pas une si bonne raison de souhaiter une spécification ...

8 commentaires

Hmm, c'est intéressant, +1. Je l'aime aussi comme mieux que l'option var car il reçoit les informations de type à gauche où elle appartient. (Maintenant sortez de ma pelouse!)

Je note que la question a voté de fermer en fonction de "subjectif et argumentatif". La question n'est ni subjective ni argumentative; La question est une question factuelle directe sur la question de savoir si une caractéristique particulière a jamais eu la discussion dans la réunion de conception linguistique; C'est une question sur un fait objectif. Juste parce que peu de gens connaissent la réponse ne fait pas une question subjective ou argumentative.

@ERIC, qu'il s'agisse de discussions ou non une question de programmation. Cela se transformera en "aurait-il d'avoir été discuté" ou "devrait-ils le soutenir", qui est subjectif et argumentatif.

@Ken: La FAQ de Stackoverflow suggère que des questions sur le sujet incluent des questions sur la conception des outils propres à la profession de programmation, ce qui est une telle question. Je ne vois aucun argument chauffé sur ce qui devrait avoir ou n'aurait pas dû être fait ici.

@Eric, je pense que la raison sous-jacente que ce fil a fonctionné est parce que les demandeurs de connaissances comme moi étaient éclairés par une autorité définitive. Ce serait comme Superman se disputant avec les hologrammes

Drôle, je pensais juste à l'inverse: faire de l'exploitant nouveau . Par exemple. Var Dataentities = DataService1.Dataentaitties (constructorarg1, ...)

@Profk, cela sera-t-il confondu avec une méthode d'usine statique?

@AaronanoDide Non, c'est une méthode d'usine statique, avec sucre syntaxique sur le dessus. Toutefois, remplace Créer et s'abstient que vous devez coder votre propre créer .

6 Réponses :

0
votes

Pas sûr de cela, mais si vous cherchez à garder les choses à gauche, vous pouvez plutôt utiliser: 

var dataEntities = new DataService1.DataEntities(constructorArg1, ...)

2 commentaires

La deuxième partie de son message parle de cela, je pense.

J'ai mentionné que dans le dernier paragraphe de ma quête

2
votes

Il déduit de la face gauche à l'envers à l'expression. Et si l'expression est non triviale qui devient laid assez rapide.

Vous pouvez comprendre quelle expression en regardant simplement l'expression elle-même (sauf une inférence de type Lamda), et ce n'est pas possible avec votre syntaxe. Avec Lamdas, le gain est assez important, l'inférence compliquée est donc un bon compromis pour Lamdas, mais ajoute que la complexité d'une telle fonctionnalité triviale est un mauvais compromis pour une simple initialisation variable.

Vous pourriez avoir une affaire particulière "Affectation à la variable où l'expression supérieure du côté droit est un nouvelle expression ". Cela me semble très inélégant. Surtout depuis la fonctionnalité VAR Atteint déjà quelque chose de très similaire, tout en étant plus flexible.

4 commentaires

(Tiré aléatoire ici) Et si c'était "Type Foide = Var (Arg1, ...)"? Le caractère unique du mot-clé var traite-t-il un paramètre le faire fonctionner? C'est-var (..) serait substitué par le nouveau t, et T est ce que le type de l'expression est à gauche.

Cela a toujours le problème de l'inférence de type à partir du résultat. Si vous venez de voir var (arg1, ...) Vous ne savez toujours pas ce que cela signifie. Ce type d'inférence de type est certainement possible, mais je l'éviterais à moins que les gains ne soient importants.

Si je lisais la couverture du livre de dragon pour couvrir, puis-je comprendre? :)

@Gabriel: improbable. Le livre Dragon est un excellent livre pour l'apprentissage théorie et la pratique de la conception du compilateur pour des langages simples de flux de contrôle impératif comme C ou Fortran. Il va dans une bonne quantité de profondeur sur les bases de la lexing, analyse, analyse symbolique, optimisation et génération de code. IIRC il n'entre pas dans les détails sur des problèmes difficiles d'analyse sémantique comme le seul codeInchaos parle.

25
votes

Le comité de design C # a-t-il déjà envisagé cette syntaxe de création d'objet?

Oui, nous avons. Nous l'avons jugé il y a quelques années. En tant que preuve de cette affirmation, voir le dernier paragraphe de mon article ici:

http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx < / p>

Le consensus de l'équipe de conception était que c'était une caractéristique "agréable d'avoir", mais pas suffisamment convaincant que cela valait le coût considérable de la conception, de la mise en œuvre, du test, de la documentation et de la maintenance de la fonctionnalité.

Je note également que les commentaires à l'entrée de blog que j'ai liés sont très négatifs sur la fonctionnalité; Il semblait que beaucoup de gens trouvaient la syntaxe peu attrayante. C'était aussi des points contre la fonctionnalité.

Cependant, la syntaxe proposée devient particulièrement agréable si vous pouvez le combiner avec d'autres caractéristiques linguistiques qui favorisent la Déclaration concise de types immuables; Si nous faisons une telle fonctionnalité dans une version future hypothétique de la langue, la syntaxe que vous proposez devient plus convaincante.

Je note plus loin que nous résistons en général aux fonctionnalités qui nécessitent une inférence de "extérieur" à "à l'intérieur"; Nous préférons que le type d'informations de type de l'intérieur. Considérez par exemple ce problème: xxx

suppose que m possède deux surcharges, une qui prend un C, et une personne qui prend une D. est celle "Nouveau C (Blah) ou "Nouveau D (bla)"? Cela pourrait être soit. Maintenant, nous devons analyser les deux! Et s'ils travaillent tous les deux, nous devons trouver ce qui est meilleur.

Il s'aggrave. Supposons que vous ayez xxx

où M prend un C et A d, et c a deux constructeurs qui prennent un E ou un F, et D a deux constructeurs qui prennent un g et un H. lequel de: xxx

est choisi et pourquoi?

Lorsque vous faites la raison de l'extérieur à l'intérieur, vous entrez rapidement dans "Explosions combinatoriques" où le nombre de cas à analyser devient O (c n ) dans la profondeur de la nidification.

c # fait la raison de cette manière pour les lambdas et c'est l'une des parties les plus difficiles du compilateur pour rendre performant et correct, croyez-moi. Nous ne savons pas d'ajouter une caractéristique similaire aux constructeurs. Si nous devions ajouter cette syntaxe, il serait probablement limité aux scénarios dans lesquels le type était connu sans ambiguïté en analysant le côté gauche d'une déclaration variable ou d'une expression d'affectation variable.

(comme toujours, je note que Eric's's Les références sur les fonctionnalités hypothétiques futures dans les produits de langage inondés et entièrement fictifs qui n'ont pas de planifications ni de budgets sont à des fins de divertissement et ne doivent pas être interprétées comme une promesse d'un produit futur particulier avec un ensemble de fonctionnalités particulier.) < / blockquote>

4 commentaires

J'aimerais en savoir plus sur vos idées sur des caractéristiques hypothétiques qui facilitent le travail avec des types immuables. L'absence de soutien linguistique dans cette région est l'une de mes principales gênes avec C # actuellement.

@CODEINCHAOS: La fonctionnalité est trop pondérée à ce stade pour même le bloguer à ce sujet; Les idées que nous avons frappés surtout sur une syntaxe concise pour dire "Ceci est un enregistrement immuable", puis le constructeur et les propriétés de l'accesseur générés automatiquement pour vous - un peu comme des types anonymes. À l'heure actuelle, il y a beaucoup de "cérémonie" autour de déclarer un type immuable qui conduit à beaucoup de code ennuyeux de la chaudière. Ce serait bien de l'éliminer.

Mais vous avez int [] f = {1, 2, 3}; en C #, je veux dire qu'en dehors de l'intérieur. Je pense que c # peut provoquer une erreur d'ambiguïté lorsque le type n'est pas mentionné non plus à gauche ou à droite, compilez si le type n'est mentionné que dans l'un des côtés et empêche si la droite et la gauche évaluent aux mauvaises expressions.

@nawfal: Dans le cas où vous mentionnez que la chose sur le côté droit de la mission n'est pas en fait une expression . Le compilateur a un code de manipulation spécial pour les initialisateurs de tableau; Il vérifie que chaque élément de l'initialiszer est compatible avec le type d'élément du type de matrice.

0
votes

Aussi de savoir avoir: 

DataType dt = new DataType(){ ParamOne = 1, ParamTwo =2 };

8 commentaires

Définitivement non . DataType DT; n'est pas, et ne doit pas être confondu, la même chose que DataType DT = nouveau DataType (); . Ce dernier appelle un constructeur, c'est une distinction importante qui devrait être préservée dans la syntaxe.

Évidemment, cela ne va pas correspondre à la langue existante de C #. Du tout. Mais ma préférence à ce stade est de se déplacer vers une langue qui n'a tout simplement pas de NULLS partout. L'erreur la plus courante que je vois dans le code est une erreur "Null Référence". Ce qui, bien sûr, provient de la programmation bâclée, mais est également (comme je le vois), la seule faille de la conception de C # en tant que langue. C'est aussi une inadéquation d'impédance avec la façon dont certains types fonctionnent (comme INT).

Les langues qui n'ont pas de concept de null ont été considérées avant, mais elles ne fonctionnent pas vraiment. Tout comme des systèmes numériques sans la notion de 0. Vous êtes beaucoup trop limité dans l'expressivité sans la capacité d'exprimer, bien, rien. Maintenant, si vous discutez que c # devrait bouger davantage vers l'idiome Raii (comme trouvé en C ++), je pourrais alors être plus enclin à être d'accord avec vous. Il y a beaucoup de problèmes avec le modèle Idisposable , et je pense que c'est une source de plus de bogues que des références nuls (notamment parce que NRE peut être facilement prise au moment de débogage, alors que les fuites de mémoire sont plus difficiles).

Ah, n'a jamais dit d'abolir NULL. Mon point est que INT par défaut à 0. Pourquoi ne pas nul NULL? Pourquoi dois-je sortir de mon chemin pour obtenir une nullable int, mais pas un type de référence nullable? En outre, il existe une grande différence entre le changement de comportement par défaut de la déclaration variable et l'abolition du concept même de NULL. Comme pour quelles erreurs sont les plus courantes, je ne peux que signaler ce que je vois. Et ce que je vois le plus souvent, c'est des exceptions de référence nulle.

N'oubliez pas que DataType DT; n'est pas le même que DataType DT = null; .

@svick, bon point. Cela rend la syntaxe encore plus disjointe, car int dt entraîne une variable initialisée où comme DataType DT n'est pas.

@mcl, ce n'est pas correct. int dt; et DataType DT; résultat dans une variable non initialisée. La même syntaxe peut être utilisée pour les champs, mais elles sont toujours déjà initialisées lorsque vous pouvez y accéder à leur valeur par défaut.

@svick, bien sûr que tu as raison. À mon esprit confus, les déclarations se ressemblent énormément et donnent des résultats complètement différents selon le contexte. Les locaux non initialisés ne compilent même pas, tandis que les champs sont initialisés implicitement. Et puis les champs se comportent comme je l'ai dit, les types de valeur Obtenez une valeur par défaut, les types de référence obtiennent une null. Je préférerais que les types de référence reçoivent une instance par défaut plutôt que NULL. Et pendant que je rêve, j'aimerais que la syntaxe que j'ai proposée. Bien sûr, cela conduirait probablement à des bugs plus subtils que mon erreur de «référence NULL» détestée, qui est la raison de la laisser seule.

2
votes

Si vous souhaitez créer un objet du même type que celui utilisé pour la stocker sans avoir à répéter le nom de type, vous pouvez utiliser "stockton nouveau". L'inconvénient est que vous devez répéter le nom de membre dans l'initialisation. Voici comment il a l'air: 

IDictionary<Int32, Int32> local = New(out local);

0 commentaires
1
votes

Il y a maintenant une proposition défendue et une mise en œuvre de cette caractéristique précisément. Nous sommes susceptibles de le voir en C # 8.0.

voir https://github.com/ dotnet / csharplang / blob / maître / propositions / cible-typed-new.md

0 commentaires

Articles qui pourrait vous intéresser :

Calculer la différence dans l'échelle d'évaluation alphabétique
Ignorer la propriété de l'interface utilisateur Swagger
Comment détruire les éléments dynamiques du panneau dans le script Unity C #
Entity Framework Core 3.1 avec NetTopologySuite.Geometries.Point: SqlException: la valeur fournie n'est pas une instance valide de la géographie du type de données