Ceci est plus un type de question de cas d'utilisation ... mais aussi générique suffisamment générique pour être plus largement applicable:
En bref, je travaille sur un module qui est plus ou moins une enveloppe de ligne de commande; Oo naturellement. Sans entrer dans trop de détails (à moins que quelqu'un ne la veuille), il n'ya pas de complexité folle du système, mais elle s'est sentie naturelle d'avoir trois ou quatre objets dans ce cadre. Enfin, c'est une chose open source que je pose là, plutôt qu'un module avec quelques développeurs dans la même entreprise qui y travaillent.
D'abord, j'ai mis en œuvre l'OO en utilisant la classe :: STD, car les meilleures pratiques de Perl (Conway, 2005) ont fait un bon argument pour la raison pour laquelle utiliser des objets à l'intérieur. Contrôle total sur les attributs accessibles, ainsi de suite, une encapsulation correcte, etc. De plus, sa conception est étonnamment simple et intelligente.
Je l'ai aimé, mais j'ai ensuite remarqué que personne n'utilise vraiment cela; En fait, il semble que Conway lui-même ne recommande plus ce problème?
Alors j'ai déménagé à l'orignal préféré de tout le monde. Il est facile à utiliser, bien que la solution de surendevole de manière à ce que je veux faire. Le grand inconvénient majeur est: il a une série de dépendances de module qui oblige les utilisateurs de mon module à tous les télécharger. Un inconvénient mineur est-il possible de bien plus de fonctionnalités que ce dont j'ai vraiment besoin.
Quelles sont les recommandations? Inconvénient d'autres développeurs en les forçant à utiliser un module éventuellement obsolète ou de forcer chaque utilisateur du module à télécharger Moose et toutes ses dépendances?
Y a-t-il une troisième option pour un cadre Perl oo approprié qui est populaire, mais aucun de ces deux?
5 Réponses :
Eh bien, il y a souris , qui est comme
Moose est merveilleux. Utilisez l'orignal au lieu de la souris. # Ligne 1 sous "Description"
Oui, utilisez Moose pour développer votre application, mais utilisez la souris lorsque vous le déployez, d'autant plus que c'est une application de ligne de commande, quelque chose qui bénéficierait des améliorations de performance de la souris. Regarde à tout :: Moose.
Non, ne fais pas ça. N'utilisez jamais :: Moose.
@jrockway et ne portez jamais de chemises bleues avec des chaussettes! Ou boire du café avec 2% de lait, il doit être entier ou demi et demi! (Euhh, justification?)
Je pense que La souris obtient plus de merde que mes contributions en CPAN.
Parce que tout :: Moose dirige les gens à croire que la souris est juste une meilleure mise en œuvre de Moose. Ce n'est pas - il a moins de fonctionnalités, une communauté plus petite, moins d'extensions et des performances d'exécution inférieures. C'est un simple hack pour faire une application comme "Cat" à partir de la commande de commande plus rapidement.
Pour être parfaitement juste, voyant pratiquement tout ce qui est intéressant ces jours-ci dans Perl World a l'orignal quelque part comme une dépendance, je ne vois pas qu'il s'agisse d'une dette pour d'autres "autres autres développeurs Perl".
chances sont-ils déjà installés comme nous parlons!
Edit: Quelques statistiques:
Moose est actuellement évalué à la 65e place sur la liste des modules "la plus dépendante", Alias Top 100 , avec plus de 1637 paquets en fonction de cela. C'est presque autant que des choses comme TIME :: embauche , et plus que dbi , et je ne pense pas que vous ne pensez pas que vous soyez aussi susceptible de questionner en fonction de ceux qui seraient-ils?
Le module étant écrit n'est pas orienté vers les développeurs durs, mais à SYS Admins et similaires. C'est un système d'emballage / automatisation de ligne de commande. Si quelque chose d'orignal est peut-être favorable aux développeurs, mais un pita pour les personnes qui doivent installer ses dépendances.
Mouse, orignal moins les bois, est très la lumière sur les dépendances et est éventuellement compilée de XS.
En outre, la liste des alias a obtenu un peu d'orignal-lourd en raison de l'addition de dépendances de DBIX-Class (facultatives) sur les modules Moose * ajoutés à la méta.yml pour ce projet.
La souris est livrée avec moins de dépendances, mais beaucoup plus de bugs et beaucoup moins de test.
@jrockway Mouse copie la suite d'essais Moose puis y ajoute. Bien que cela ne passe pas tous, il sait ce qu'il peut et ne peut pas faire (voir les annuaires omettre ) et son très bien testé.
Les gens apparaissent sur #moiser avec des bugs tout le temps. Après 15 minutes de débogage, nous constatons que le problème est qu'ils utilisent la souris. Cela me passe suffisamment pour croire que ce n'est pas suffisamment testé - les gens proposent des caisses d'angle étranges et les fixer à Moose. Avec la souris, tu es la première personne à faire ça. Pour de nombreuses valeurs de "ça".
Le "cadre moderne de Perl OO" actuellement accepté est l'orignal. Je dirais que vos utilisateurs téléchargent-le, ou vous pouvez l'incliner avec vos modules dans l'installation à l'aide de :: Packer .
citant de " mais je ne peux pas utiliser cpan "(... parce que mes utilisateurs ne voudront pas installer les choses): P>
En supposant que vous n'ayez que gérer vos utilisateurs une tagball, alors module :: Installation fournit une solution - si vous mettez votre script dans le script /, puis faites P>
install_script(glob 'script/*'); auto_install;
Pour ajouter aux réponses fines existantes ...
Une partie de ce qui a été recommandé dans PBP n'est pas un mauvais conseil, mais Perl marche sur. Quand il a été écrit, les objets à l'intérieur étaient la nouvelle hotness. Maintenant, l'orignal a tout absorbé. Il y a MOOSEX :: Infidout qui vous donne la puissance de l'orignal avec l'encapsulation totale de Classe :: STD, mais sauf si vous travaillez avec des programmeurs indisciplinés, ce n'est vraiment pas nécessaire.
Ces caractéristiques de l'orignal dont vous n'avez pas besoin maintenant, vous aurez finalement besoin d'eux. Même si vous n'avez pas besoin d'eux, avec l'orignal, vous n'aurez pas à utiliser et d'apprendre encore un autre système OO chaque fois que vous avez besoin d'une fonctionnalité intéressante. Et Dieu nous interdisons que vous avez besoin de deux caractéristiques en même temps!
Il y a quelques applications où il est nécessaire qui n'a rien à voir avec des "programmeurs indisciplinés"
@Évan évitant les affrontements clés privés avec des sous-classes me vient à l'esprit. Que pensais-tu?
... FileHhandles ou tout autre objet obscur qui peut être béni mais probablement ne devrait pas et ne peut pas y attacher de données.
Il y a aussi un objet de module Perl :: insidence, entretenue activement à partir de 2010.
genre d'un prédécesseur à l'orignal, ou d'être clair: le développement a commencé indépendamment en même temps que Moose a commencé,
Je sais que cela existe mais je ne l'ai pas utilisé.
Définir "Slew"? Moose a 4 dépendances non dans la classe: STD, de ces plus grandes est la classe :: MOP qui est tout le point d'orignal.
Vous oubliez les dépendances des dépendances. :-)
Un Slew -> DEPS.CPANTESTERS.ORG/?MODULE=MOOSE ;PERL=LATEST < / a> réduit tous les modules principaux, 16 n'est pas si mauvais, mais ce n'est pas 4.
Et la plus grande chose est, l'orignal est tellement standard maintenant que votre distribution Linux devrait l'avoir disponible dans leur référentiel principal et que / mai / peut / faire un travail sysadmins un peu plus facile.
(Par opposition à la classe :: STD c'est-à-dire que ma distribution ni navires ni je ne l'ai pas, ni quelque chose qui l'utilise installé)