Re: RE:RE: [Tsp-devel] suggestion pour core.common.TspStreamReader e t core.common.TspSes sion en Java

[Eric NOULARD]

Le jeudi 12 mai 2005 à 17:15 +0200, CHOQUET, Mathias a écrit :
> Bonjours,
> 
> Je crois comprendre le problème de la Fifo. cet attribut est public et on ne
> peut pas l'enlever 
> puisque les consumers actuels s'en servent.

Exact. 
Quoiqu'un membre public c'est bien crado donc améliorer
ça serait une bonne chose.

> 
> Moi j'aime bien l'idée de faire de la classe TspSampleFifo une classe
> abstraite TspSampleSet 

Je suis d'accord avec ça. 

N'empêche qu'on peut pour plus de souplesse
dans des futures évolutions transformer le membre public
en getter, qui pour l'instant se bornera à renvoyer le membre
TspSampleSet devenu privé mais bon celà permettra d'éventuel
changement 'sous le manteau'.
On peut aussi faire se changement plus tard ce n'est pas fondamental 
aujourd'hui.


> même si cela fait que certaines méthodes n'ont plus de sens.
A noter que l'API actuelle du TspSampleFifo est peut-être
inadapté. Si tu en vois une meilleure propose donc.

> 
> Voici ma proposition pour arranger un peu ce problème : 
> 
> ceux qui utilisent l'ancienne API avec TSPSessionSampleInit()
> ------------------------------------------------------------
> rien ne change à part que l'on instancie TspSampleSet en TspSampleFifo 
> dans la méthode TSPSessionSampleInit().

Ok avec ça.
> 
> ceux qui utilisent la nouvelle API avec
> TSPSessionSampleInit(TSPStreamReader,TSPSampleSet) 
> ----------------------------------------------------------------------------
> --------------
> On demande explictement aux utilisateurs d'instancier leur objet
> TSPSampleSet (en 
> TspSampleToto par exemple) pour qu'ils soient obligés de répondre aux
> besoins de l'API TSPSampleSet.
> A mon avis, cela peut éviter des confusions pour les utilisateurs.

Ok personnellement ça me va.

> 
> 
> Mathias C.
> 
> > -----Original Message-----
> > From: Eric NOULARD [mailto:address@hidden
> > Sent: Wednesday, May 11, 2005 7:15 PM
> > To: Devel TSP
> > Subject: Re: [Tsp-devel] suggestion pour 
> > core.common.TspStreamReader et
> > core.common.TspSes sion en Java
> > 
> > 
> > Je viens avec une réponse un peu plus détaillée.
> > Sur le principe je suis donc POUR l'optionnalité de la FIFO
> > sur les détails d'implem' voilà mon avis:
> > 
> > > 
> > > Pour se faire, voici ma proposition : 
> > > Créer une classe abstraite : public abstract class TspStreamReader
> > > implements Runnable 
> > 
> > Oui Ok pour classe abstraite
> > TspStreamReader 
> > 
> > (du coup on refactor l'actuelle en TspFifoStreamReader)
> > > 
> > > Cette classe abstraite aurait en plus une méthode configure : 
> > > 
> > > public Configure(TspDataInputStream in, TspGroup[] groups) {
> > >   this.in     = in;
> > >   this.groups = groups;
> > >   stop        = false;
> > >     }
> > 
> > Là je ne suis pas d'accord c'est un constructeur de la classe 
> > abstraite
> > et pas une méthode. Ce serait donc:
> > 
> > public TspStreamReader(TspDataInputStream in, TspGroup[] groups) {
> >             this.in     = in;
> >     this.groups = groups;
> >     stop        = false;
> > ]
> > 
> > > 
> > > Le constructeur et la méthode « public void readGroup(int 
> > i) » serait à
> > > implémenter par des classes étendant la classe abstraite 
> > TspStreamReader.
> > 
> > uniquement readGroup.
> > 
> > > 
> > > L'utilisation de la FIFO se ferait par défaut avec la classe
> > > TSPFifoStreamReader.La méthode readGroup serait identique 
> > et le constructeur
> > > serait le suivant : 
> > > 
> > > public TspFifoStreamReader(TspSampleFifo fifo) {
> > >   this.fifo   = fifo;  }
> > 
> > Non ce serait le constructeur actuel avec un appel au
> > constructeur du père plus l'init de la fifo.
> > 
> > public TspFifoStreamReader(TspDataInputStream in, TspGroup[] groups,
> > TspSampleFifo fifo) {
> > 
> >         super(in,groups)
> >     this.fifo   = fifo;
> >     }
> > 
> > 
> > > 
> > > Du coup, l'utilisateur a le choix d'implémenter ou non sa 
> > propre classe
> > > TSPStreamReader (par exemple totoStreamReader extends 
> > TspStreamReader).
> > > 
> > > Cette classe serait instancié par l'utilisateur et envoyée 
> > à la méthode
> > > TSPSession.RequestSampleInit(totoStreamReader)  qui 
> > surchargerait la méthode
> > > actuelle.
> > 
> > Ca je suis OK.
> > 
> > > 
> > > Si l'utilisateur ne l'implemente pas, il appelle normallement
> > > TSPSession.RequestSampleInit() qui instancie 
> > TspFifoStreamReader et qui
> > > appelle le configure.
> > > 
> > > Pour TSPStreamReader, les changements seraient :
> > > _Créer une classe abstraite TSPStreamReader en laissant 
> > vide readGroup et le
> > > constructeur
> > > _Ajouter la méthode configure (décrite au-dessus).
> > > _Créer une classe TSPFifoStreamReader qui implémente le 
> > constructeur et
> > > readGroup.
> > 
> >   Voir mes remarques précédentes.
> > 
> > > 
> > > Pour TSPSession, les changements seraient : 
> > > _Changer le nom du thread  « sampleFifoThread » en « sampleThread »
> >   Ok pour sampleThread.
> > 
> > > _Ajouter une méthode RequestSampleInit(TspStreamReader)
> >   Ok pour pour ça aussi.
> > 
> > > _Enlever l'attribut de classe "TspSampleFifo sampleFifo"
> > 
> >   Ca ne va pas être possible si simplement.
> >   Même si c'est pas joli du tout.
> >   Les consumers actuels utilisent ce membre.
> >   Il faut donc continuer à leur donner accès de façon à ce qu'ils
> >   puissent faire maSession.getSamples().getSample() ou encore
> >   maSession.getSamples().nbSample()
> > 
> > La TspSampleFifo pourrait devenir une classe (Abstraite) TspSampleSet
> > et le membre publique de TspSession un getter TspSession.getSamples()
> > qui renvoie un TspSampleSet dont l'API ressemblera à celle du
> > TspSampleFifo.
> > 
> > Je suis pas très content cette dernière suggestion vu que si
> > l'appli a fourni son propre TspStreamReader les méthodes
> > maSession.getSamples().getSample() ... n'auront pas de sens...
> > 
> > Si on veut avoir une session qui offre sur un appel
> > 
> > TSPSession.RequestSampleInit()
> > 
> > la bufferisation avec FIFO il faut qu'ensuite l'appli ait
> > accès à cette FIFO (ou au mini une API pou récupérer les samples)
> > puisque ce n'est pas elle qui l'a crée.
> > 
> > Je réfléchis à ça et j'y reviens j'attends aussi ton retour/tes idées
> > sur ce point Mathias.
> > 
> > 
> > Eric
> > > _______________________________________________
> > > Tsp-devel mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/tsp-devel
> > 
> > 
> > 
> > _______________________________________________
> > Tsp-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/tsp-devel
> > 
> _______________________________________________ Tsp-devel mailing list 
> address@hidden http://lists.nongnu.org/mailman/listinfo/tsp-devel