De la version actuelle (0.98) de Moose :: Manuel :: MooseX sont les lignes:
Nous avons de grands espoirs pour l'avenir de
MooseX :: Méthode :: SignaturesMooseX :: Declare. Cependant, ces modules, pendant qu'il est utilisé régulièrement dans la production par certains des plus fous les membres de la communauté, sont encore alpha marqué juste en arrière de cas les changements incompatibles doivent être prises.Je remarque que pour
MooseX :: Méthode :: Signaturesle journal changement Septembre 2009 mentionne la suppression de la " avertissement effrayant ALPHA ".
Alors, sont-ils encore « alpha »?
Serais-je toujours considéré comme l'un des « plus fou » pour les utiliser?
6 Réponses :
Cela dépend de ce que vous entendez par «la production prête». Je ne dépendais pas d'eux jusqu'à ce que leur vitesse ne ralentit pas un peu. J'aime mes trucs de production pour ne pas avoir besoin de soins fréquents des modifications de code externes, des ajustements de l'API, etc. Ce n'est pas quelque chose de particulier à l'orignal, mais tout jeune projet.
Vous devez juger à quel point cela vous importe. Dans certaines situations, poussant des trucs dans la production est un processus long, vous devez donc être circonspect avec de telles choses. A l'autre extrême, certains endroits vous permettent d'éditer des fichiers directement sur le serveur de production. C'est-à-dire que vous devez définir votre tolérance avant de pouvoir vous dire quel côté un module Moosex donné est activé.
Merci pour votre réponse. On dirait que vous êtes réticent à utiliser même Moose .
Je pense que l'orignal est vraiment cool. Je suis juste réticent à faire attention à cela tous les jours pour voir si je dois refaire beaucoup de choses. Je dois faire avancer les choses et ne pas compter sur un jeu de modules changeant rapidement n'est pas le moyen de progresser. Comme je l'ai dit, ce n'est pas particulier d'orignal.
Merci. Ça a du sens. Alors, créez-vous tous vos objets de zéro?
Je fais la plupart de mes objets en appelant des constructeurs dans des modules CPAN. :)
Il y a des gens qui sentent que la maturité et la stabilité de Tout cela est à dire, la décision de savoir si quelque chose est ou que la production n'est pas prête à l'emploi dépend fortement de votre environnement de production, de vos besoins de développement et de votre goût pour le risque. Sans être dans vos chaussures, nous ne pouvons pas éventuellement donner une décision éclairée sur la manière dont aucun outil donné correspond à ce profil. Moosex :: delcare , devel :: déclarer sur lequel il est basé, ou même orose ne sont pas encore prêts pour "Prime Time". Je connais également deux grandes entreprises avec des millions de visiteurs par mois, qui ont Moosex :: Déclarez dans leur environnement de production. Personnellement, je suis heureux avec la pile que je suis fournie avec Moose et ne voyez pas encore à apporter Moosex :: Declare . Je connais des opinions qui sont d'avis que je respecte profondément qui refusent de rédiger un nouveau code sans le sucre déclaratif de Moosex :: Déclarez .
Merci. C'est probablement bon pour moi de me rappeler que tout le monde n'est pas aussi ravi de Moose comme je suis. Je l'utilise tellement, j'avais oublié ce fait.
Ce n'est pas que les gens ne soient pas ravis d'orignal, mais ils valorisent plus la stabilité plus. Je pense que Moose et Moosex sont vraiment cool. J'en ai juste besoin pour stabiliser. :)
Je pense que c'est une question de perspectives différentes autant que tout - RAFL est l'un des «membres plus insensés de la communauté» susmentionnés, tandis que Rolsky est plus conservateur. C'est à vous de décider de qui vous êtes d'accord et je pense vraiment que la variable la plus importante est votre propre code.
Moosex :: Declare est bon code. Cela ne saura pas au hasard votre machine, ce n'est pas affreux pour la performance et il offre un lot de chaussures Nifty tout en réduisant la quantité de chaudière que vous devez écrire. Mais il pourrait changer d'avenir, rendre votre code refuse de compiler jusqu'à ce qu'il soit mis à jour; Cela pourrait faire de votre éditeur et d'autres outils de développement confus lorsqu'il voit la syntaxe qu'il ne peut pas analyser, cela pourrait faire chier vos collaborateurs en leur faisant apprendre un nouveau module pour travailler avec votre code, ou peut faire pisser votre patron en le faisant Donc, tout futurs mainteneur doit apprendre un nouveau module pour travailler avec votre code. Laquelle de ces choses s'applique à vous et à quel degré? Vous savez mieux que moi, j'espère.
Merci. Mon éventuel remplaçant devra probablement apprendre Perl à partir de zéro, de sorte que vos commentaires sur la maintenabilité sont particulièrement pertinents.
+1, mais laissez-moi noter que «plus de membres insensés de la communauté» transmettent vraiment autre chose que ce que je pense que vous essayez de dire. Florian écrit un code bon et généralement stable. C'est juste qu'il expérimente aussi beaucoup. De grandes choses sont venues de cela. Comme pour toutes les dépendances externes, il est tout simplement important que l'on passe un peu de temps à décider lorsqu'il s'agit d'une bibliothèque de qualité prototype ou quand elle est considérée comme éprouvée et vraie.
Je dirais qu'ils sont prêts à la production - je suis en utilisant eux en production - mais il y a plusieurs choses à considérer:
au moment de l'exécution, la surcharge principale est le type et la vérification des arguments, ce que vous devriez (idéalement) faire de toute façon. Cela dit, les contraintes de type Moose ont des frais généraux, à savoir la coercition et les contraintes plus complexes (types de Moosex: Types :: style structuré). Ne les utilisez pas si la performance est un problème.
Moosex :: Déclarez et Moosex :: Méthode :: La syntaxe externe de Signature est maintenant stable. Mais il est important de savoir que les Internals sont soumis à un changement Pour vous donner une idée, la signature elle-même est saisie à l'aide d'un gros bloc de code C volé à partir du tokéniseur Perl (TOKEACC). Cela peut casser dans certaines situations car il n'est pas réellement analysé. Le bit à l'intérieur des supports est analysé en utilisant PPI , conçu pour Pure Perl, mais le résultat résultant L'arbre PPI est ensuite piraté pour obtenir quelque chose d'utile. Devel :: Declare est un piratage - après qu'il voit des mots-clés spécifiques (par exemple '' Rôle ',' Classe ',' Méthode ') Le Devel :: Declare-Utilisant le module doit réécrire le code source à la main, sans interaction avec le véritable parseur Perl.
Les cas d'angle peuvent causer de Perl à segfault. Ou réécrivez le code source mal, vous obtenez donc des erreurs de syntaxe mais n'indique aucune idée de ce qui les causer sans Moosex :: Declare n'a pas été mis à jour beaucoup, et vous voudrez peut-être examiner des alternatives telles que COTS . Personnellement, j'ai décidé de coller avec de l'orignal pur jusqu'à ce que Perl lui-même commence à prendre en charge la classe / méthode / a la syntaxe de manière nativement, qui est éventuellement sur les cartes . Performance
Moosex :: Déclare et les dépendances font presque toute leur magie à la compilation. Selon la taille de votre programme, vous trouverez peut-être n'importe où d'une demi-seconde à plusieurs secondes d'initialisation supplémentaire. Si cela pose un problème, n'utilisez pas Moosex :: Declare .
Stabilité
-mo :: déparfe . Si vous gâchez le Moosex :: Déclare Syntaxe par accident, il n'y a aucune garantie que le module détecte cela et vous donnera une erreur judicieuse. Le message alpha peut avoir disparu, mais cela fait toujours les choses sombres et effrayantes les choses en interne, et vous devriez être préparé pour cela.
Je ne suis pas sûr de pouvoir garantir que la syntaxe externe est stable puisque Moose n'a pas de telles promesses de stabilité elle-même.
Notez que, tandis que coerce a une pénalité de vitesse, c'est aussi l'une des choses les plus superbes . Utilisez-le selon le cas, ne l'utilisez pas pour NO Raison :)
Pour les trucs de rédaction de code, j'ai parlé à des membres de l'orignal sur l'utilisation de Moose dans un flux de travail de type pré-processeur. Un processus de distribution moofinified.pm.pl, résout tout le truc de l'orignal, crache de code PERL non moellé et installe cela. Vous pouvez ensuite regarder la sortie pour voir ce qui s'est mal passé sans avoir à attendre avant d'exécuter un programme. Si vous n'avez pas besoin de la dynamique, je pense que c'est la meilleure façon pour l'orignal.
Moosex :: Méthode :: Signatures (MXMS) et Moosex :: Declare qui l'utilise, n'est pas la production. Ce n'est pas parce que le code n'est pas stable, mais parce qu'il est effroyablement lent. Il suffit d'utiliser la méthode Méthode :: Signatures , en revanche, n'a presque aucune performance au-dessus de quoi Cela coûterait normalement les chèques demandés. La syntaxe est presque exactement la même que celle des MXMS et prend en charge les types d'orignaux (et de souris). Les deux dépendent de la même technique de modification de la syntaxe sous-jacente. (Divulgation complète, je suis l'auteur de la méthode :: Signatures.)
Si vous aimez Moosex :: Déclare mais que vous voulez la performance de la méthode :: Signatures, essayez Méthode :: Signatures :: Modificateurs . mot-clé, aucun type ou argument, est un performance d'exécution de 500-1000x frapper sur une méthode régulière appeler . Mon MacBook Pro peut faire environ 6 000 appels de méthode simples par seconde en utilisant MXMS VS 5 000 000 avec Perl uni.
pénalité de performance je vois est autour de 2-5x par rapport à Cela vaut la peine de se débarrasser de l'argument de Perl Shifting Hell. Moosex :: Declare et Moosex :: Méthode :: Les signatures fonctionnent bien, mais ils peuvent avoir une pénalité vraiment méchante en fonction de ce que fait votre code. Ceci peut être corrigé en n'utilisant tout simplement pas la méthode ou à l'aide de Méthode :: Signatures :: Modificateurs .
Méthode :: Signatures :: Modificateurs (5x étant surtout pour une classe spécifique que j'utilisais). Et il semble que cela compilait principalement l'heure ou peut-être une première initialisation pour la première fois, car elle comprenne moins de 2 fois lorsque le calcul est plus long.
Méthode :: Signatures :: Modificateurs a de meilleures erreurs, mais vous devez éteindre cette optimisation lorsque vous utilisez du débogueur (il va Haywire car il ne voit pas ces méthodes, vous pouvez voir pour vous-même -mo = déparfe sortie).