or zax a écrit 195 commentaires

Réseau anonyme non censurable ... je préfère largement le concept freenet qui lui n'a pas besoin de faire de capture sous forme d'image pour apporter l'anonymat, la protection contre la censure etc ...

Le fait de passer en utf-8 ne pose aucun souci, si tu prends quelques précautions qui sont valable en réalité pour les encodage latin9 :

_ quand tu codes : en anglais, donc dans la pratique ton fichier sera ASCII, car si tu es sûre de la configuration de ta machine, tu ne l'es pas des machines des gens pouvant de relire. Même pour les messages de logs si tu fais des applications serveurs ou des applications web.

_ man : en français les encodages ne sont pas uniformes donc ne t'attends pas à tout avoir nickel à l'affichage

_ quand tu transmet un fichier à quelqu'un, vires les accents espace et compagnie.

En fait la vrai distinction c'est si les données sortent de chez toi ou pas. Si oui prend des précautions pour être sûre que la personne en face n'ai pas de problème.

Sinon cela ne change rien, et je pense même que tel encodage ou tel autre pour les besoins courant cela n'apporte rien, par contre quand tu as plusieurs machines ou un parc, lance un dé : si c'est pair tout en latin, si c'est impair tout en utf8. le principal c'est que tu puisses manipuler tes données facilement, même si çà transit entre plusieurs machines du parc, donc vaut mieux que ce soit uniforme.

pour rigoler j'ai fait dans google ; C expression régulière emails

et j'avais pleins de code lol.

Cela n'enlève pas l'intérêt du site de l'article bien sûr, par contre parfois les bonnes vieilles habitudes cela peut dépanner.

Ben je sépare ma vie privée du boulot, donc mon poste perso se base sur un fichier, mon poste pro sur un autre.

Par contre je travaille dans un environnement zéro papier. avec des backups automatiques.

je l'utilise tous les jours avec l'application Thinking Rock

Bzr n'est pas le seul à gérer les deux approches, GNU Arch gère les deux cas depuis le début.

De plus il est pas évident de comparer la notion de branches entre un système centralisé ou non, chacun utilisant ce terme pour désigner des choses différentes, je pense surtout à la notion de branche de SVN notamment.

* Pour le côté multiplateforme qui rend plus aisé l'utilisation en entreprise lorsque l'on a pas la main sur le choix de L'OS du poste de travail.

* Quand j'avais regardé GIT, je n'ai rien compris à la doc, à l'époque, on parlait d'utiliser cogito pour le rendre ergonomiquement 'human being friendly', à l'heure actuelle je suppose que cet aspect n'est plus un problème.

Personne ne parle des abus de geonumbers qui prenait des numéros à tout va sans vraiment vérifier si le numéro non taxé amène vraiment à l'entreprise souhaité.

Des sociétés se sont retrouvé avec des milliers d'appels de personnes cherchant à joindre une entreprise alors qu'elles appelait une autre, paralysant des lignes de supports pour rien.

Donc c'est bien quand on fait son travaille sérieusement

Je n'ai jamais affirmé que Java est le concept de base, ne te méprend pas sur ce que j'ai voulu dire, je me suis mal exprimé.

Je suis d'accord et partage ton avis sur tous les points.

Pour ce qui est de faire de la programmation objet à longueur de journée, ben c'est ce qui me fait manger chaque jours.

"une méthode statique est une méthode appartenant non pas à un objet mais à une classe, donc la dériver c'est un contre sens en POO", c'est mon opinion, tu ne l'as partage pas, tant mieux et il faut de la diversité de discours je ne suis pas contre, par contre tu as contre argumenté par rapport à l'implémentation d'un langage ce qui est à côté du propos.

Et ma grosse connerie elle a été argumenté contrairement à ta position d'offusqué !

Alors tu peux essayer de jouer au grand par ton ton condescendant, tu n'en rendras que plus creuse ta position.

statique ou pas est un concept, comme la programmation orienté objet est un concept, maintenant si tu n'aimes pas le concept de programmation objet, pourquoi pas.

Maintenant que des implémentations font plus le concept de base, tant mieux, il faut évoluer, mais tout ajout ne devient pas quelque chose d'utile et géniale parce que c'est 'nouveau'. C'est génial quand cela apporte une valeur ajouté dans les problématiques que l'on rencontre dans la conception d'application efficace, maintenable et pérenne.

Je n'utilise pas un langage pour faire un étalage de syntaxe histoire que la programmation soi plus fun, un langage est un outil qui doit à travailler mieux, et plus vite.

Maintenant si je me trompe et que cet ajout à une réelle valeur ajoutée, expliques moi, je ne demande qu'à comprendre, en attendant, j'ai argumenté mes propos.

Prend le cas du Ruby, il a certains aspects qui peuvent paraitre exotique dans son implémentation de l'objet, mais ces spécificités se sont révélées souvent utiles pour mieux architecturer l'application. En plus d'autres facteurs totalement irrationnels de l'ordre du goût personnel, font que c'est mon langage préféré niveau objet.

Par rapport au python qui est en soit un super langage, tu présentes certaines spécificités comme un plus, explique en quoi c'est un plus ? Si c'est juste pour dire sur le papier python fait çà que tel autre langage ne fais pas ... intérêt zéro, si par contre cela apporte un mécanisme qui simplifie l'implémentation de certains design pattern, alors super !! Ce truc est génial.


Donc les implémentations des langages c'est le dernier de mes soucis, tu présentes quelques choses de spécifiques, explique en quoi cette spécificité est un plus et non un simple argument de l'ordre "qui a la plus grande".

ben non car je pensais que tu maitrisais certains basique.

l'intérêt d'un objet est de rattacher des traitements à des états propres à chaque localité (du fait de l'existence des attributs), une classe statique est une entité qui ne peut avoir qu'un seul état à un moment donné.

La conséquence est que l'on a pas besoin de se rattacher à une instance pour manipuler l'état en cours. L'absence d'instance fait que l'état est disponible de façon globale de n'importe où.


Cette accessibilité globale fait que la surcharge ou l'héritage sur une entité à un seul état possible (élément statique) n'a pas de sens, car n'ammène aucune flexibilité supplémentaire :

Tu as besoin de récupérer une fonctionnalité statique ? Elle est disponible depuis n'importe quel endroit du code, donc héritage inutile.

Tu as besoin de personnaliser une fonctionnalité statique ? tu appelles ta fonctionnalités statique récupère le résultat et le retravaille, donc surcharge inutile.


l'intérêt de l'héritage et de la surcharge est de pouvoir factoriser et personnaliser des fonctionnalités sous forme hiérarchique sur toutes les états existant d'une entité, car tu gardes dans tes attributs d'instance, l'état spécifique à chaque instance tout en récupérant tes fonctionnalités déjà écrites.

Bref c'est du basique de POO.

Regarde le travaille nécessaire pour maintenir LFS et tu verras que c'est une vrai dstribution. Pour maso certes mais pas moins vrai que les autres.

Justement parce que je ne limite pas ma vision à l'implémentation objet d'un langage, je ne valide pas la pertinence d'une pratique par le fait qu'un langage permet de le faire ou pas, mais uniquement sur la pertinence en terme d'architecture et de conception.


[troll]
Et un langage qui ne gère pas la notion d'entité sans état correctement (classe) est un langage qui bride bien beaucoup je trouve.
[/troll]

$this n'a pas a appeler du static au travers de $this, c'est self::nomMethodeStatique() qui devrait être imposé, c'est un bug.

C'est une chose qui relève plus d'un problème de mentalité chez php que d'un problème objet, php encourage un laxisme navrant dans le language, j'apprécie les capacités techniques de php et son modèle objet par contre de base ils partent du principe que même si un développeur écris n'importe quoi il faut que çà marche.

* une méthode statique est une méthode appartenant non pas à un objet mais à une classe, donc la dériver c'est un contre sens en POO, ce n'est pas parce que certains langage font n'importe quoi qu'il faut imiter.

* Pour le deuxième point je demande à voir sur un exemple concret. Car l'affirmation me parait grosse

* pour le fait de changer $this par extract forcément si tu voulais savoir qu'un langage çà se casse, je te fais des exemples équivalent en JAVA, C++ quand tu veux.

Enfin le modèle objet n'est pas une surcouche vu que c'est le moteur objet de Zend sur lequel se repose PHP, le modèle objet est écris à un niveau plus que l'implémentation même du PHP.


Il n'empêche que point de vue ergonomie d'utilisation de modèle objet, je préfère d'autres langages que le php (ruby par exemple) mais ce n'est qu'une question de goût

Cela impose tel architecture "si tu utilises ...".

MVC est une extension parmis d'autres, donc adieu la normalisation imposé d'un framework.

Ce que je critique n'est pas la qualité de la technologie qui est superbe mais le fait que l'on appel "framework" quelque chose qui n'est pas un framework.

Le problème est que dire que l'on utilises un framework cela fait bien, donc on appel tout et n'importe quoi un "framework". Surtout que dans beaucoup de cas un framework n'est pas justifié, et c'est à ce marché là que répond ZF.

Je ne connais pas bien Zope, on me l'a souvent décris plus comme un serveur d'application qu'un framework. Pour ceux qui connaissent contrairement à moi, c'est une affirmation juste ?

Je ne suis pas d'accord avec toi, tu prend un langage quelconque, même sans librairies, tu peux structurer ou pas, choisir une architecture ou pas.

Le framework impose une architecture, car l'un des objectifs d'un framework est d'enlever au maximum le travail d'analyse au développeur. C'est pour cela par contre que tu as des frameworks spécialisés, framework web, appicatif, réseaux etc ...

Si tu peux faire ce que tu veux ce n'est plus un framework.

Zend propose pleins de fonctionnalités et de classes, pour aider sur pleins de choses, mais n'a pas de norme imposé, mais une logique globale.

Le principe de framework universelle est un peu un contre sens par rapport au but d'un framework, qui est spécialisé pour un sous ensemble d'application.

ZF est plus une sorte de méta-framework, et serait une excellente base pour créer un framework.

La surcharge n'est pas une fin en soi, c'est un moyen parmi d'autres de faire du polymorphisme, et du polymorphisme tu en fais sans problème en PHP.

Ensuite que tu pointes une ressource par une variable $fp, un objet ou autre cela change rien, par contre si tu structures ton code correctement en objet, tu n'as pas cette problématique de te le trimballer en permanence

Pour être franc jusqu'à PHP 4.X je partage ton avis. Je refusais même de faire de l'objet.
Par contre depuis PHP 5.X je ne fais que de l'objet au quotidien sur des applications grands compte à forte audience (centaines de milliers d'utilisateurs), çà tient la charge, le code se structure facilement et est maintenable, grâce à l'utilisation de framework notamment.

Je suis entièrement d'accord, arrêtons d'appeler un Framework tout est n'importe quoi.

Le seul est intérêt de ZF est de rappelé au monde que PHP 5.X n'est plus un simple langage de script mais peut être un véritable environnement OBJET de développement. Sur ce point là ZF est une très bonne chose.

Je ne connais pas du tout.

De quoi s'agit-il exactement ? Comment interprète-t-on ces statistiques ?

Hey !!! mais c'est horrible ce traducteur en language SMS ! Promis je n'écris pas comme cela moi !!!

Il y a une chose que je ne comprend pas, la sortie en question c'est juste les paquets pré-compilé en français qu'ils veulent dire, car sur gentoo c'est depuis vendredi que OOo 2.2 en français pré-compilé est disponible, donc j'ai un peu de mal à comprendre cette dépêche.