He visto una buena cantidad de código fuente de otras personas y otro software PHP de código abierto, pero me parece que casi nadie realmente usa PEAR.¿Qué tan común es PEAR en el mundo real?
¿Qué tan común es el uso de PEAR en el uso del mundo real?
Estaba pensando que tal vez la sensación actual en los marcos puede estar afectando su popularidad.
La cultura del programador de PHP parece tener una infestación desenfrenada del síndrome "No se inventó aquí", donde todos parecen querer reinventar la rueda ellos mismos.
Para que esto no se aplique a todos programadores de PHP, pero haciendo esto aparentemente demasiado normal.
La mayor parte del tiempo creo que es debido a la falta de educación, y eso combinado con la dificultad de los proveedores de alojamiento que ofrecen servicios PHP decentes.
Esto hace que conseguir una instalación de PEAR viable sea mucho más difícil, y se ve empeorado por la estructura de diseño de PHP que no es favorable para un diseño modular.
(Esto puede mejorar con la adición de espacios de nombres, pero aún no se han visto).
La gran mayoría del código PHP que veo en la naturaleza sigue siendo un clásico código de aficionado interpolado con HTML, y la mayoría del alojamiento barato que los usuarios de PHP inevitablemente suscriben no le da acceso al shell.
La biblioteca de Pear es una especie de cosas que simplemente se asienta allí, tapando, con muy poca gloria. Si está buscando algo que pueda hacer, y no hay nada más específico en el marco que está utilizando, vaya a usarlo.
He estado trabajando en un sitio de citas durante los últimos dos años, y hay al menos 65 archivos de fuentes de pera que he usado, y todavía vivo allí hoy. Algunos, como el localizador o html_Quickform, serán superados por el nuevo código a medida que se actualice, pero para otros simplemente no hay necesidad.
Im mi opinión PEAR es un buen proyecto, pero carece de las personas que quieren trabajar y mantener trabajando en ello, la mayoría de los paquetes tienen prácticas de codificación inconsistentes (no me refiero estilo de codificación) y hay un montón de en de TODO toda la cosa.
Encuentro útil algunas veces para codificar cosas que aún no sabía que existían, como funciones de validación de país personalizadas, etc., de lo contrario me serviría mejor con cualquier marco disponible (como CodeIgnite o Zend Framework).
PEAR no es común ni popular.
Traté de usar PEAR tantas veces, pero le falta el umpphh para confirmar.
Prefiero Zend Framework que tiene el enfoque de tipo "suelto", use solo lo que desee.
En mi experiencia (limitada), cada proyecto PEAR que era potencialmente interesante tenían puntos principales en contra de ella:
include. Cuando su intérprete de PHP tiene que procesar todo ese código fuente en cada visita a la página (porque es posible que los autores no lo hayan diseñado para ser opcode-cache-friendly), hay una carga mensurable para procesar miles de líneas de código no utilizadas.Solía usar PEAR::DB en el trabajo. Descubrimos que la mayoría de nuestros scripts pasaban su tiempo dentro del código PEAR en lugar de nuestro propio código. Reemplazando eso con un envoltorio muy simple alrededor de las funciones pgsql_* se redujo significativamente el tiempo de ejecución y se incrementó la seguridad del tiempo de ejecución, debido al uso de real declaraciones preparadas. PEAR::DB usó su propia lógica de sentencia preparada (incorrecta en el momento) para Postgres porque las funciones nativas pgsql_ eran demasiado nuevas para usarse en todas partes.
En general, me siento como PEAR es bueno como una "biblioteca de inicio" en muchos casos. Es probable que sea un código de mayor calidad que cualquier persona producirá en un corto período de tiempo. Pero ciertamente no lo usaría en un sitio web público popular (al menos, no sin muchos ajustes manuales ... manteniendo mi propio tenedor).
+1 y secundado en PEAR :: DB/postgres. He tratado el mismo problema. Solo reinventa la rueda cuando las bibliotecas estándar ya lo hacen de manera eficiente. –
El punto # 2 es el gran asesino para mí. El código PEAR está hinchado porque tiene que lidiar con una amplia variedad de situaciones. La mayoría del código es leído e interpretado por cada página en su sitio, incluso si solo está usando una pequeña parte de él. – jmucchiello
PEAR no es común, ni popular, pero es bueno, y se lo recomendaría a cualquiera.
(estoy de acuerdo con Tom en que no se siente como un único y unificado, API, pero entonces, esto es PHP ... uno no les gustaría ver que conseguir por encima de su estación como un interpretado piratear el lenguaje ahora sería uno?!)
Sí. Y, sin embargo, de alguna manera todavía funciona en su mayoría. (Al menos el código VB malo fue en su mayoría invisible.) – dkretz
la infestación es autosostenible por desgracia, todos reinventan la rueda, pero no la comparte para que otros no tengan que hacerlo. –
Realmente no creo que este sea el motivo por el cual PEAR carece de adopción total. – jmucchiello