Discussion :

[Paul TOTH]

J'ai regardé l'exemple, mais je ne vois pas en quoi c'est indispensable.
Ca rend le code plus illisible, c'est tout.

tu peux t'en passer à condition de n'avoir qu'une requête asyncrhone à la fois, tu utilises alors une variable globale

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
var ajax;
 
function download(url) {
 if (!ajax) ajax=InitAjax()
 ajax.open('GET',url,true); // requête asyncrhone
 ajax.onreadstatechange=onReadyStateChange;
 ajax.send(null); // lancer la requête
}
 
function onReadyStateChange() {
  switch (ajax.readyState) {
   ...
  }
 }

mais comment tu fais pour gérer deux requêtes simultanées ?

[Lung]

mais comment tu fais pour gérer deux requêtes simultanées ?

Doit y avoir un truc qui m'échappe ...

[Paul TOTH]

ben c'est pas compliqué pourtant

Si je lance deux download, il manque à l'évément un objet Sender qui permettrait de savoir quel transfert a déclenché OnReadyStateChange !

dans le cas d'une fonction anonyme c'est comme si on dupliquait le code de l'événement, un exemplaire par téléchargement.

reprenons avec un exemple Delphi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
function CreateButton(const Name:string; Tag:integer):TButton;
begin
 Result:=TButton.Create(Form1);
 Result.OnClick:=ButtonClick;
 Result.Tag:=1;
end;
 
begin
 button1:=CreateButton('Button1',1);
 button2:=CreateButton('Button2',2);
end;
 
procedure Tform1.ButtonClick(Sender:TObject);
begin
 case TButton(Sender).Tag of
   1 : ShowMessage('Button1Click');
   2 : ShowMessage('Button2Click');
 end;
end;

bon maintenant, supprimer le paramètre Sender...comment tu fais ?

avec des fonctions anonymes on pourra écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
begin
 button1:=TButton.Create(Form1);
 button1.OnClick:=function begin
  ShowMessage('Button1Click');
 end;
 button2:=TButton.Create(Form1);
 button2.OnClick:=function begin
  ShowMessage('Button2Click');
 end;
end;

[Lung]

Je crois que je comprend mieux.
Mais, ce genre de cas arrive souvent ?

Jusqu'à présent, on s'en passait, non ?

[Paul TOTH]

ah ben c'est bien ce que je dis depuis le début !

pour moi ça n'apportera pas grand chose si ce n'est de la confusion

je préfèrerais un IDE plus performant et un compilateur crossplateforme linux au lieu de ce genre de choses

NB: quand je parle de crosscompilation, je pense à CrossKylix, pas un IDE sous Linux car ça demande bcp de travail, alors que de générer des executables Linux, ils savent déjà le faire ! Je me fous que la VCL soit portée ou pas sous Linux, je ne développe pas d'application GUI sous Linux, mais uniquement des services ou des applications consoles.

enfin bon, c'est pas pour demain.

[nostroyo]

Il est vrai que peut-être les méthodes anonyme, n'ont pas un intérêt flagrant. Mais concernant les generics, je ne comprends pas pourquoi vous y êtes réfractaire. Qui n'as jamais fais de TObjectList avec à chaque récupération d'un objet un cast dessus; ou même si vous redéfinissiez votre propre list avec un cast dans le get, ça oblige à redéfinir pour chaque type d'objet. Avec les generics, on sait ce qu'on mets et ce qu'on reçoit. A mon avis c'est super utile.

[Paul TOTH]

Il est vrai que peut-être les méthodes anonyme, n'ont pas un intérêt flagrant. Mais concernant les generics, je ne comprends pas pourquoi vous y êtes réfractaire. Qui n'as jamais fais de TObjectList avec à chaque récupération d'un objet un cast dessus; ou même si vous redéfinissiez votre propre list avec un cast dans le get, ça oblige à redéfinir pour chaque type d'objet. Avec les generics, on sait ce qu'on mets et ce qu'on reçoit. A mon avis c'est super utile.

ben parce que je suis de la vieille école, et que pour commencer faudrait que je sache comme c'est implémenter pour comprendre comment ça marche

et ce que je viens de lire sur java ne me semble pas encourageant

[Lung]

Mais concernant les generics, je ne comprends pas pourquoi vous y êtes réfractaire. Qui n'as jamais fais de TObjectList avec à chaque récupération d'un objet un cast dessus;.... Avec les generics, on sait ce qu'on mets et ce qu'on reçoit. A mon avis c'est super utile.

Tiens, tiens ...
Ca, ça m'intéresse beaucoup plus.
Tu peux en dire un peu plus.

[nostroyo]

En fait je prends exemple sur ce que je faisait en java. Quand tu veux faire des collection personnalisé , tu fais un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
   ArrayList<String> data = new ArrayList<String>();
    data.add("hello");
    data.add("goodbye");

Bon ici c'est du java, donc on peux passer un String, mais tu mets ce que tu veux entre <>.
Tu récupère le tout sans cast

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String strl = data.get( 1 );

Après je ne sais pas comment ça va être implémenter en delphi, mais ce sera surement proche!

[Lung]

Intéressant.

Là, tu prends l'exmple du type chaîne.
Mais, c'est sensé marcher pour n'importe quelle objet (classe) ?

[nostroyo]

Oui.
De plus j'avais pas fait vraiment gaffe, mais il existe les generic en delphi.net, donc pour l'implémentation, je pense qu'il faut s'y référer.

[Aka Guymelef]

Ça m'embêtes un peu de devoir dire ça à des vieux de la vielle comme vous mais il y a déjà des tutoriaux sur le sujet comme celui-ci

Ensuite moi aussi j'ai des réticences vis à vis des nouveautés, même les génériques je sais pas je trouves que ça m'embrouilles l'esprit mais je dois être vieux jeu moi aussi.

C'est comme la dernière fois mon chef qui m'a montré comment on pouvait créer une classe en C#/.NET et qui pouvait s'intégrer dans SQL Server 2005 en tant que nouveau type de données et qui se manipule quasiment comment une variable objet mais dans le code SQL lui-même.
C'est super mais là encore je trouves que ça embrouilles plus que tout. Au lieu d'avoir des entités de programmation bien distinctes (ma base SQL, mes objets Delphi, etc...) on se retrouve avec tout mélangé et du coup il faut penser que peut-être c'est le code C# de la classe du type SQL qui fait planter ma requête ou qui est incompatible quand elle redescend vers mon code etc...
Bref toujours des complications sans plus et toujours moins de rigueur. L'idée d'avoir un IDE puissant dans le "refactoring" pour zapper l'idée de générique est intéressante, à la manière des snippet par exemple on pourrait faire des templates qui attendent le type de donnée pour la TList ou TObjectList et génère le code avec les méthodes surchargées pour le cast directement ce qui donne le gain de temps à coder tout en conservant une certaine rigueur et la compatibilité ascendante.

[Laurent Dardenne]

Salut,

Mais, c'est sensé marcher pour n'importe quelle objet (classe) ?

Oui.
Pour plus d'infos sur le sujet vous pouvez consulter cet excellent livre.

donc pour l'implémentation, je pense qu'il faut s'y référer.

Pour la grammaire il y a de grande chance pour l'implémentation, je ne suis pas sûr puisque les types de base sous Delphi Win32 ne sont pas des objets comme sous .NET.

Ensuite moi aussi j'ai des réticences vis à vis des nouveautés, même les génériques je sais pas je trouves que ça m'embrouilles l'esprit...

Cela m'a fait la même chose lorsque j'ai vu qq exemples en C#, c'était bien incompréhensible. Ce n'est, à mon avis, que passager car ici il s'agit d'une question d'habitude et de pratique. J'ai la même réaction en ce moment avec Linq.

on se retrouve avec tout mélangé

Fusionné plutot, et d'après certains, comme Anders Hejlsberg, c'est la voie de l'avenir. Voir Linq.
En même temps utiliser Linq pour des traitements dans un DataWareHouse

Bref toujours des complications sans plus et toujours moins de rigueur.

Ici il s'agit peut être d'un problème d'outil inadapté ou incomplet...

on pourrait faire des templates qui attendent le type de donnée pour la TList ou TObjectList

Un développeur, allemand je crois, a déjà réalisé cela et c'est plutot un préprocesseur si je me souviens bien.

N'oubliez pas que la VCL Win32 sera réécrite avec les génériques. Vous serez bien obligé, à priori et si vous migrez vers cette version, de les utiliser.


Voir aussi :
Anders Hejlsberg Film Festival: The C# and other VS Language Teams at the Movies

[Paul TOTH]

Ça m'embêtes un peu de devoir dire ça à des vieux de la vielle comme vous mais il y a déjà des tutoriaux sur le sujet comme celui-ci

ben ce tutorial ne répond pas à LA question que je me pose moi

quel est le code généré pour ce genre de chose ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
type
 TMonster<Type>=class
  fMonster:Type;
 end;
var
 TinyMonster:TMonster<byte>;
 LargeMonster:TMonster<cardinal>;
// et je ne sais pas si c'est possible
type
 Big=array[0..500] of string;
var
 BigMonster:TMonster<Big>;

on a là des choses bien différentes tout de même que ce soit en occupation mémoire ou on terme de manipulation...mais si on peut très bien vouloir gérer une liste de byte, de cardinal ou de Big par exemple.

est-ce que différentes versions du générique vont être produite à la compilation pour obtenir au final des classes indépendantes, ou est-ce que on a un code partagé truffé d'information de type ou de je ne sais quoi permettant d'avoir l'illusion d'un code propre est simple

[Aka Guymelef]

Fusionné ? Oui peut-être mais pour moi ça revient au même que mélangé dans le seul où, à l'heure actuelle, on a bien des boîtes bien distinctes qui communiquent entre-elles, une boîte pour la base de donnée, une boîte pour le programme, une boîte pour le réseau, etc...

Sauf qu'avec l'exemple réalisé par mon chef, rien ne m'empêche d'aller mettre du code métier dans ma classe qui implémente mon nouveau type voire de coder dedans tout les traitements qu'on mettrait plutôt dans des DLL en "classique". Dès lors avec mon système de boîte quand j'ai une erreur, je sais de suite grâce au message quelle boîte aller voire. Chose beaucoup moins évidente quand base de donnée et programme sont fusionnés.

Et mon chef a beau me dire qu'évidemment mettre du code métier est la chose à pas faire, il y en qui le feront et on sera bien obligé de reprendre leur travail derrière

Pour les génériques c'est justement le manque de sémantique qu'il y a derrière qui est le plus gênant. Habitué à voire des variable toujours typés avec un nom explicite, rencontrer un type générique qui peut être par définition n'importe quoi me semble en contradiction et fait resurgir des souvenirs douloureux de VB et son sacro-saint-bordélique faible typage.

Quelque part je me demande si les nouveautés qu'on a débattues dans ce topic ça ne réponds pas plutôt une volonté de fainéantise au moment de coder plus que de répondre à de vrais problèmes d'architecture comme l'introduction des interfaces par exemple.
Je dis bien au moment de coder parce que pour ce qui est du debuggage c'est une autre histoire. On pourrait aussi se poser la question de la performance car il doit y avoir un coût au niveau de la Réflexion à utiliser des génériques, coût qu'on ne doit pas avoir en utilisant des types bien définis (en conjonction avec le polymorphisme).
C'est d'ailleurs, je trouves, une notion qui ne semble plus importer lors du codage chez les nouveaux développeurs (et par ailleurs les plus enclins à utiliser la solution de rapidité/facilité) : optimisation. Je le vois chez nous qui, pourtant, faisons des sites Web en C#/.NET l'aspect postback est constamment utilisé mais coûteux tant en mémoire qu'en temps processeur alors qu'il y aurait peut-être solution avec du JavaScript côté client. Vraiment j'ai l'impression que l'idée d'aujourd'hui est que les machines sont assez surpuissantes comme ça et pourront encaisser à l'aise tout ce qu'on leur impose (idée que j'ai d'ailleurs l'impression d'avoir avec Vista et ses super-trop-jolis-effets-de-la-mort-sur-mes-fenêtres-mais-qu'est-ce-que-je-bouffe-en-RAM) enfin là on s'écarte peut-être du sujet de base.

PS : en fait j'ai plus mis le lien pour ceux qui se demandaient comment ça s'implémentait

[Laurent Dardenne]

si on peut très bien vouloir gérer une liste de byte, de cardinal ou de Big par exemple.

Oui mais dans ce cas tu dois contraindre ta classe générique voir la dériver, car pour un tableau on accéde à une de ces valeurs via un indice, un byte n'en posséde pas.

est-ce que différentes versions du générique vont être produite à la compilation pour obtenir au final des classes indépendantes, ou est-ce que on a un code partagé truffé d'information de type ou de je ne sais quoi permettant d'avoir l'illusion d'un code propre est simple

Pour delphi .NET on le sait, pour Delphi Win32 je ne sais pas. On peut supposé qu'il suive le C++ avec le pb de taille du code(code-bloat).
Là faut poser la question sur les newgroups US de Borland.

[delphichem]

L'évolution qui m'intéresse le plus dans cette version est le support UNICODE car CodeGear à pris un grand retard dans ce domaine, cette cause a été l'une des principale à de nombreux développeurs de délaisser Delphi au profit de C# ou autre.
Mais bien sûr les autres évolutions sont toujours les bienvenus

[Aka Guymelef]

Je suis d'accord avec Delphicem, ça c'est vraiment une problématique que l'on ne peut plus ignorer ou devoir dépendre de composants tiers de nos jours.

[Laurent Dardenne]

on a bien des boîtes bien distinctes qui communiquent entre-elles

Oui je suis d'accord avec toi. Si on regarde le pro*C d'Oracle c'est le même principe. L'approche est peut être d'offrir une vision différente via un regroupement des différentes sources et type de manipulations de données.

Et mon chef a beau me dire qu'évidemment mettre du code métier est la chose à pas faire, il y en qui le feront et on sera bien obligé de reprendre leur travail derrière

ça la maintenance c'est un autre débat mais je partage aussi tes réserves.

rencontrer un type générique qui peut être par définition n'importe quoi me semble en contradiction

C'est un type paramètrable, une instance d'une classe générique ne contient qu'un type de donnée. Et le typage fort existe tjr, c'est le traitement qui est partagé.

On pourrait aussi se poser la question de la performance

C'est une question de choix lors de la conception.

C'est d'ailleurs, je trouves, une notion qui ne semble plus importer lors du codage chez les nouveaux développeurs ...
enfin là on s'écarte peut-être du sujet de base.

Disons que c'est une autre réflexion, là je pense que c'est un problème lié la perception et l'usage du temps dans notre société.

[Paul TOTH]

ah ok, j'avais zapé ce passage

c'est donc bien une recompilation de la classe avec le nouveau type...sauf qu'en CLR c'est natif, en win32 ça ne sera pas possible. J'imagine donc que Delphi produira la nouvelle classe lors de sa déclaration...hum...oui dans ce sens c'est "pratique" de déclarer ce genre de chose:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
type
 TListOf<T:TObject>=class(TList)
 private
  function GetItem(Index:integer):T;
 public
  procedure Clear; override;
  property Items[Index:integer]:T read GetItem; default;
 end;
 
function TListOf<T:TObject>.GetItem(index:integer):T;
begin
 Result:=List[index];
end;
 
procedure TListOf<T:TObject>.Clear;
var
 i:integer;
begin
 for i:=0 to Count-1 do TObject(List[i]).Free;
 inherited;
end;

mais comme je crée rarement des classes aussi basiques, j'aurais tendance à écrire ceci derrière :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
type
 TListOfButton=class TListOf<TButton>
 private
  fOnClick:TNotifyEvent;
 public
  property OnClick:TNotifyEvebt read fOnClick;
 end;
 
 TListOfListBox=class TListOf<TListBox>
 private
  fOnDrawItem:...;
 end;

ce qui en fait serait une grave erreur, car ces deux classes devraient hériter d'un TListOfObject commun et non de deux déclarations spécifiques du générique !

non, décidemment, je pense que ça apporte plus de confusion que de simplification, même si je peux comprendre que ça soit parfois une solution adaptée à un problème donné.