Compass : East Oriented

[Xenos]

Bon, je lirai ces deux liens dans 5 minutes, mais là, pour le coup, j'ai l'impression d'être juste ignoré:

sans le formaliser, j'en avais fait en stage de dernière année (sous la forme d'un réseau neuronal où chaque noeud est un objet, qui reçoit une copie de tous les messages des autres,le traite ou non et renvoie ou non un message à tous les autres)... Eh bien avec ce genre d'approche, le "je sais ce que je veux et je te fais confiance pour le faire" est vite devenu un "je sais ce que je veux mais mon truc fais n'importe quoi".

J'ai pas compris East (pourtant, c'est bien l'idée "faites passer des messages et faites confiances aux noeuds avals pour qu'ils le traitent", non?) ? Ou y'a autre chose?

Bon, après, ton histoire de zone de confort, y'a pas de lien :
-> East, je l'ai tenté, sans forcément avoir le nom, lors du stage de dernière année; et je l'avais même retenté au boulot pour gérer l'upload d'un dossier dans un logiciel. La classe UploadDossier envoyant chaque fichier aux différentes classes d'upload (PDF, DXF, DWg...) qui pushent ou non ce fichier vers une classe de résultat; dès que t'ajoutes des conditions croisées comme "le DXF n'est upload que si un PDF valide est uploadé" ou "si deux PDF sont uploadés, un message d'erreur doit apparaitre pour le signaler et aucun des deux n'est uploadé (donc le DXF éventuel ne l'est pas non plus), patatra... Mais peut-être l'ai-je mal fait?
-> J'en sors régulièrement (je reviens de la cooupe de France de robotique, où on a fait dernier: je n'avais jamais fait de véritable robotique et ma dernière soudure remontait au lycée)

Après, le retour, en PHP, tu retournes ce que tu veux, donc la classe appelée n'a aucune restriction. En Java, tu peux retourner null au lieu d'un objet, donc c'est assez similaire.
J'objecterai enfin que tu essaies de faire finalement de la programmation évènementielle, adaptée à JS mais pas à PHP.

(La fonctionnalité qui merge les messages successifs est peut-être pétée; si tu veux faire du multi-post, une astuce consiste à copier le post précédent dans le nouveau message, à insérer ensuite ton nouveau texte, à poster ce nouveau message, puis à supprimer l'ancien: tu auras un seul nouveau message avec l'ancien texte + le nouveau texte)

[srm]

Désolé pour la partie sur réseau de neurone que j'ai zappé.
C'est pas la même chose "je TE fais confiance pour faire correctement ce que tu sais faire".
En réseau de neurones c'est "je VOUS fais confiance pour faire correctement ce que vous savez faire".
Donc en réseau de neurones tu peux bien très rapidement avoir un code spaghetti du genre goto, très difficile à faire évoluer et débug. Ce qui est justement tout le contraire en East.

Vu que East dans sa forme actuelle n'existait pas vraiment (pour ne pas dire pas du tout) l'an passé, tu as peut-être testé quelque chose qui s'en approche un peu, mais c'est un peu comme dire "je fais un peu de l'objet", si tu fais pas correctement de l'objet, forcément ça peut donner n'importe quoi. Bah c'est pareil pour East.

Pour ton cas si tu pouvais refaire un exemple en une trentaine de lignes de code je pourrais te dire

C'est pas parce que tu envoies des messages que tu fais de la programmation événementielle, ça n'a aucun rapport.

Retourner null est déjà une réponse.

Exemple, avec un getter :
Un policier me demande mes papiers :
Cas 1 : je lui donne
Cas 2 : je ne fais rien et ne lui donne pas
En PHP ça donnerait :
Cas 1 : return $data;
Cas 2 : return null

Maintenant imaginons ce cas là :
Un policier me demande mes papiers :
Cas 3 : je m'en vais
En PHP ça donnerait :
Cas 3 : bah heu... je sais pas en fait

En East tu gères le cas 3 très bien.

[Xenos]

Hum, je m'en vais = return null et en parrallèle, je goto LePlusLoinPossible. D'ailleurs, en l'absence de return, PHP return null par défaut


Je vois pas trop la différence entre le vous et le te... Puisqu'au milieu du vous, il y avait le te?!
D'ailleurs, les cellules biologiques sont en "vous", elles ne s'adressent pas directement à une autre cellule précise.

Pour l'uploader:
Ce qu'on veut:
• Sélectionner un dossier pour l'uploader dans le logiciel
• Lors de l'upload d'un dossier, n'uploader que les fichiers validés
• Un fichier est validé s'il s'agit d'un PDF, d'un DXF, ou d'un DWG

Conditions supplémentaires tombées à postériori (ben oui, en environnement industriel, les mecs changent souvent d'avis >.<)
• Chaque fichier va être rattaché à une structure de nom précise, qui indiquera dans quelle catégorie uploader le fichier ("NumeroDeCategorie_Dateyyyy-mm-dd_Revision_NomQuelconque.extension")
• Si j'upload deux PDF pour la même catégorie et révision, ils ne sont pas validés (aucun n'est uploadé, un message me le dit)
• Un DXF ou un DWG (nommé NumeroDeCategorie_NomQuelconque.dxf/dwg) ne peut être uploadé que si un PDF est uploadé pour cette catégorie
• Du coup, si un deux PDF sont uploadés pour une même catégorie (donc, ces deux PDF sont invalides), aucun DXF ni DWG n'est uploadable


Comment le faire (début d'esquisse):

Code :

Class DirectoryUpload {
    FileUploader[] FileUploaders;
    File[] filesToUpload

    uploadFolder(Directory dir) {
    for file in dir.files do
        for fileuploader in FileUploaders
            fileupload->thereIsAFileToUpload(file, filesToUpload);
    }
}

Class PDFUploader implements FileUploader {
    thereIsAFileToUpload(File file, File[] files) {
        if (File.isPdf()) // Bon, là, déjà, y'a du return, mais on fait comment sans return?
            files.thereIsAValidFileToUpload(file);
    }
}
Class DXFUploader implements FileUploader {
    thereIsAFileToUpload(File file, File[] files) {
        if (FileUploader.isThereAPdfForThisDxf(file))  // Et là, sans "getter", comment on fait?
            files.thereIsAValidFileToUpload(file);
    }
}

Perso, en essayant East là dessus, j'ai vite terminé en un immonde sac de noeuds...

Parce qu'au fond, ce que je veux, c'est savoir si le fichier est un PDF, et je fais confiance à File via isPdf pour me le dire... Ca me semble bien suffisant comme approche, cela respecte la notion de message et de boite noire (okay, cela requiert que l'appelant sache que l'appelé reconnait le message isPdf, sans argument), sans pour autant être sur-poussé au East.
Je vois bien que East oblige aux messages, mais l'OOP classique (là encore, sans voir les getter/setter comme des écraseurs/lecteurs d'attribut) me semble satisfaire à la même chose. En fait j'ai l'impression que tu refais, au niveau utilisateur du langage, ce que le langage lui-même fait déjà.

D'ailleurs, je ne suis pas d'accord avec The thing about messaging is data becomes irrelevant.: quand on envoie le message vers son destinataire, les data s'y trouvent (final string DirectorName). De même, public Movie[] moviesDirectedBy(String arg), pour moi, c'est "je veux la liste des Movie pour un réalisateur (et sous forme d'un array, là, on passe à coté du I de SOLID), et je te fais confiance pour me la donner". C'est bien du what, pas du how.

Ah au fait: en East, ta callstack va finir par creuver les plafonds, non, puisqu'il n'y a pas de retour possible vers l'appelant?

[srm]

Hum, je m'en vais = return null et en parrallèle, je goto LePlusLoinPossible. D'ailleurs, en l'absence de return, PHP return null par défaut

Et tu le codes comment ton "en parallèle" ?
C'est pour ça qu'en East on dit de toujours faire un return $this

Je vois pas trop la différence entre le vous et le te... Puisqu'au milieu du vous, il y avait le te?!
D'ailleurs, les cellules biologiques sont en "vous", elles ne s'adressent pas directement à une autre cellule précise.

Entre envoyer un message à un destinataire précis et envoyer à tout le monde, tu ne vois pas en quoi le code sera bien plus simple à faire évoluer et à gérer ?

Pour la suite je réponds un peu plus tard

[srm]

Au niveau de la stack trace aucun soucis elle se vide aussi vite qu'elle se remplis

Je comprends pas tout ton code en C là :x
Je vais faire avec ce que j'ai compris et en PHP en simplifiant certains aspect :

<?php



class FileAggregator implements ArrayIterator

{

    private $files = [];

    

    public function imPdf(File $file)

    {

        $this->enqueue($file);

    }

    

    public function imDxf(File $file)

    {

        if (/* blabla match pdf file for this dxf */) {    

            $this->enqueue($file);

        }

    }

    

    protected function enqueue(File $file)

    {

        $this->files[] = $file;

    }

}



class File

{

    public function areYouPdf(FileAggregator $fileAggregator)

    {

        if ($this->isPdf === true) {

            $fileAggregator->imPdf($this);

        }

    }

    

    public function areYouDxf(FileAggregator $fileAggregator)

    {

        if ($this->isDxf === true) {

            $fileAggregator->imDxf($this);

        }

    }

}



class PDFUploader implements FileUploader

{

    public function thereIsAFileToUpload(File $file, FileAggregator $fileAggregator)

    {

        $file->areYouPdf($fileAggregator)

    }

}



Class DXFUploader implements FileUploader

{

    public function thereIsAFileToUpload(File $file, FileAggregator $fileAggregator)

    {

        $file->areYouDxf($fileAggregator);

    }

}

Tu vois plutôt simple à faire en East

[Xenos]

En parallèle, au sens de PHP, est à entendre comme A l'insu de la classe appelante (mais peut parfaitement être un vrai parallèle dans d'autres langages).
L'idée était de souligner que la fonction appelée peut, de toute façon, retourner "merde" à son appelant (sous la forme d'un null).

D'ailleurs, question subsidiaire: comment réaliser des tests unitaires quand les méthodes sont des boites noires complètes qui ne renvoient qu'une référence d'elles-mêmes? Quoiqu'on peut répondre la notion de test n'a pas lieu d'être puisqu'on 'je sais ce que je veux, et je *fais confiance pour que ce soit fait*'... Mais si jamais le code part en cacahouète, je serai curieux de savoir comment on débug cela...


Okay, maintenant, dans ton exemple, ajoutes les conditions qui me sont tombées dessus par la suite (puisque East est censé être "plus extensible que l'approche classique", si j'ai bien compris son intérêt):
• A l'ajout d'un PDF, si un autre existe déjà, le PDF doit être rejeté (et tous les DXF éventuellement liés au PDF doivent être rejetés)
• Les PDF et DXF peuvent être ajoutés dans n'importe quel ordre (donc, le DXF peut être envoyé dans imDxf avant qu'un pdf n'existe... en ce cas il est rejeté... mais une fois le PDF ajouté, il faut que le DXF soit ajouté aussi !)
• Il faut ajouter les fichierx DWG sur le même principe (mêmes règles) que le dxf

Je sais pas toi, mais moi, je sens que les im*, et areYou* vont vite se démultiplier...

[srm]

Ok si tu me montres ton code non East alors
Car il y a un peu de boulot quand même.

[srm]

Déjà un truc que je comprends pas, tu peux avoir qu'un pdf en tout et pour tout au final ?
Au max :
1 pdf
1 xdf
1 dwg c'est ça ?

[Xenos]

Nope, 1 et 1 seul PDF par "ligne" (une ligne = une tuyauterie qui va d'un point à un autre, pour situer le contexte). 0 1 ou plusieurs DXF/DWG/mélange des deux par ligne, si celle-ci a un PDF.
Si pas de PDF sur une ligne: pas de DXF/DWG uploadable. Si plusieurs PDF sur une ligne: aucun n'est uploadé (donc, pas de PDF pour cette ligne; donc pas de DXF/DWG non plus).

J'ai pas le droit de sortir le code d'ici J'essayerai de le ré-esquisser plus clairement après.

[srm]

Plusieurs PDF sur une ligne ?
Franchement je vois pas comment ton système fonctionne.
Si j'envoie un PDF, puis un autre, comment il sait que je suis sur la même ligne ou une nouvelle ?
Tu as un numéro de ligne avec l'upload du PDF ?