Equivalent 'with' en C++? - Page 2

Zephyr
: Bah non je n'aurai pas tout à convertir, seulement dans le cas hautement improbable où tout à coup, manque de bol, j'ai besoin d'initialiser avec une variable externe qui se trouve avoir le même nom qu'un champ de ma structure, faut quand même le chercher (d'autant plus que la structure n'a pas évolué, et que donc c'est la variable qui est venue s'ajouter, ce qui signifie que j'ai volontairement ajouté une variable qui pose problème avec mon propre code ? non, géneralement j'évite de me mettre des batons dans les roues ^^)

Pollux :
Ben je suis désolé si tu penses ça, mais tout sucre syntaxique n'est pas bon à prendre. Et inversement, il y a plein de sucres syntaxiques qui ne tombent pas dans l'écueil du with, dans la mesure où il ne perdent pas de généralité : int i=0; while (i<42) { ...; i++; } -> for (int i=0;i<42;i++) ...;, ou bien replaceword($my_word,$value+1) -> s/\b$my_word\b/$value+1/e.

En gros pour toi, tout sucre syntaxique qui limite le domaine d'utilisation est bon à jeter ? Pour reprendre ton exemple du switch, l'extension qui consiste à pouvoir remplacer "case 1: case 2: case 3: case 4" par "case 1 ... 4:" est une abomination puisque si par hasard un jour je veux exclure le 3 de mes cas, il faut tout réécrire ?

Donc oui je pense que tout sucre syntaxique est bon à prendre, à partir du moment où il est raisonnable, et je préfere des écritures élegantes et lisibles à des blocs immondes mais évolutifs quand je sais que l'évolution en question n'a que très peu de chances d'arriver. Tu peux effectivement programmer de la façon la plus modulaire possible, et ne jamais reposer sur le fait qu'une portion de code risque de rester inchangée pendant longtemps... ...mais à quel prix

JackosKing-VNR :
Ha mai smoi je me mettais dans un cadre programmation objet en C++.
setDate etc...

GoldenCrystal :
tu peux faire ça avec des if/else ?

swhith (i) // int i
{
  case 1:
    j += 1;
    break;
  case 2:
    j = 1;
    goto case 1;
  case 3:
    return j;
}

if (i == 1)
{
1: j +=1;
} 
else if ( i == 2)
{
 j = 1;
 goto 1;
}
else if ( i == 3)
{
return j;
}

swhith (i) // int i
{
  case 2:
    j = 1;

  case 1:
    j += 1;
    break;
  case 3:
    return j;
}

Pollux
:

JackosKing-VNR :
Ha mai smoi je me mettais dans un cadre programmation objet en C++.
setDate etc...

Ca ne change pas grand-chose : with{} serait aussi applicable dans ce cas-là ^^
(et il y a des langages qui supportent une programmation objet propre même avec des "machin.bidule = truc" : C#, Ruby, etc...)

public sealed class Foo
{
	private class Bar /* La classe est privée, elle n'est donc pas accessible de l'extérieur */
	{
		public int n1, n2, n3;
		public float v1, v2, v3;
	}

	private List<Bar> barList;

	Foo(int n)
	{
		barList = new List<Bar>;
		for (int i = 0; i < n; i++)
			barList.Add(new Bar());
	}

	/* code */
}

Pollux :

tu utilises la variable date pour calculer user.age

3 mois plus tard tu rajoutes le champ user.date dans un autre fichier

Bref, excuse-moi mais c'est vraiment loin d'être tiré par les cheveux

Non, absolument pas ; remplacer "case 1 ... 4:" par "case 1 ... 2: case 4:", c'est raffiner une condition en lui donnant un sens différent. (de même que, je sais pas, "x+42" peut être raffiné en "x<0 ? 42 : x+42", c'est pas la preuve que "x+42" est pas bien)

Au prix de 5% de lisibilité perdue, dans le meilleur des cas

Zephyr
:

Pollux :

tu utilises la variable date pour calculer user.age

3 mois plus tard tu rajoutes le champ user.date dans un autre fichier

Bref, excuse-moi mais c'est vraiment loin d'être tiré par les cheveux

Bah... si ? C'est moi qui vais devoir te renvoyer à mes posts, j'ai expliqué (plusieurs fois, en plus) pourquoi le "with" n'aurait justement pas du être utilisé dans le cas que tu viens d'inventer...

le jour où tu veux remplacer user.age par un calcul qui dépend de la date, tu devras tout convertir

Non, absolument pas ; remplacer "case 1 ... 4:" par "case 1 ... 2: case 4:", c'est raffiner une condition en lui donnant un sens différent. (de même que, je sais pas, "x+42" peut être raffiné en "x<0 ? 42 : x+42", c'est pas la preuve que "x+42" est pas bien)

Ça revient "un peu" au même à mon sens, tu es revenu sur la ligne de départ pour la modifier, et abandonner la syntaxe plus lisible. D'ailleurs si ce genre de cas devait arriver trop souvent, ça ne prouverait qu'une chose : jamais il n'aurait fallu utiliser une telle syntaxe à cet endroit du code.

Par contre tu reparles de tes variables/constantes que j'ai volontairement ignorées puisque ça me semblait assez loin du sujet, et je dois dire que c'est de plus en plus le cas... (ce n'est définitivement pas un sucre syntaxique)

Justement, en C#/VB/Ruby, ce n'est pas nécessaire, grâce aux propriétés ^^

Pollux :
Ah, bien, tu réaffirmes bien que tu ne considères pas le cas où tu dépends de variables externes, mais à ce moment-là je ne comprends plus du tout le 2è paragraphe de ./30
Je veux dire, tu n'utilises *jamais* de variables externes avec with, on est bien d'accord ? Dans ce cas-là ma phrase

le jour où tu veux remplacer user.age par un calcul qui dépend de la date, tu devras tout convertir

est bien correcte pour toi, non ? (i.e. comme tu ne peux/veux pas utiliser de variables externes dans le with, tu dois convertir le with(user) en user.truc)

Oui, et alors ? Je vois pas où tu veux en venir...

Comprends rien Le problème du with de PHP (que n'a pas le with de VB/FoxPro), c'est les variables externes que tu ne peux pas utiliser de façon sûre dedans, donc tu es obligé de te restreindre aux constantes littérales ^^ Je ne vois pas en quoi c'est loin du sujet, c'est même le coeur du problème...

Zephyr
:

Pollux :
Ah, bien, tu réaffirmes bien que tu ne considères pas le cas où tu dépends de variables externes, mais à ce moment-là je ne comprends plus du tout le 2è paragraphe de ./30
Je veux dire, tu n'utilises *jamais* de variables externes avec with, on est bien d'accord ? Dans ce cas-là ma phrase

le jour où tu veux remplacer user.age par un calcul qui dépend de la date, tu devras tout convertir

est bien correcte pour toi, non ? (i.e. comme tu ne peux/veux pas utiliser de variables externes dans le with, tu dois convertir le with(user) en user.truc)

Heu oui et non, elle est incorrect dans le sens ou "le jour où" n'est pas censé arriver, sinon il n'aurait pas fallu utiliser de with à cet endroit.

Awé je savais même pas qu'on parlait de php en fait... D'ailleurs je savais même pas qu'il y avait un with en php. Mais heu nan là je ne parle pas d'un langage en particulier, donc si c'est un problème lié au php et uniquement à lui (flemme de relire les posts précedents,) c'est aussi hors sujet.

Pollux :
Comment tu peux savoir à l'avance si tu devras rajouter ou non des champs à 'user', ou qu'une constante entière devra ou non être configurable par la suite ?

Ben je sais pas, t'utilisais une syntaxe style PHP pour les chaînes de caractères, ça parlait d'utilisateurs et d'identifiants (un scénario web classique), et comme en plus tu as fait pas mal de sites en PHP, j'ai cru que c'était du PHP, ôtant pour moi... (menfin c'est vrai que je crois pas qu'"end" existe en PHP, non ?)

Bref, si la construction que tu défends ardamment comme étant résolument indispensable n'est implémentée dans aucun langage, ça ne fait qu'appuyer ton argumentaire déjà magistral Et je persiste à croire qu'implémentée comme tu le suggères avec collision des namespaces, ce serait une feature très chiante et bien moins utile que celle de VB/FoxPro ^^

with objet do
begin
   attribut_a := 50;
   attribut_b := 'plop';
   methode_a ();
   methode_b (17);
end;

Zephyr
:

Pollux :
Comment tu peux savoir à l'avance si tu devras rajouter ou non des champs à 'user', ou qu'une constante entière devra ou non être configurable par la suite ?

"modélisation objet" ? enfin après ça dépend de la méthode, mais perso j'évite de me lancer corps et ame, à ajouter des champs n'importe comment aux objets, etc; et c'est *très* rare d'avoir à en ajouter qui n'étaient pas prévus au départ.

si on surcharge une classe et qu'on veut appeler la classe de base depuis une méthode surchargée, on doit faire: 'MaClasseDeBase::MaMethodeDeBase(...)' non?

le '::' est un cas spécial puisque normalement c'est pour les méthodes statiques si j'ai bien compris,

Ensuite si tu nommes tes variables correctement, les collisions n'ont aucun risque d'arriver. En respectant les conventions de nommage on n'aurait jamais eu '.size = size', mais plutôt '.nSize = lnSize'. Pareil pour les variables globales ^^