Оцінка просторів імен PHP


11

Я перебуваю на стадії попереднього випуску PHP-проекту з відкритим кодом, який, сподіваюся, буде використаний іншими розробниками у власних проектах. Наразі проект не підтримує простори імен, і я намагаюся оцінити, чи слід використовувати простори імен або умову PEAR іменування Dir_Subdir_Class, яка, схоже, має ті самі технічні переваги без деяких недоліків. Якщо чесно, це непростий вибір.

Деякі питання щодо просторів імен:

  • Один із способів того, як мій проект намагається диференціюватися, надаючи більш простий API, ніж інші подібні проекти. Оскільки простори імен є новими, а також тому, що вони складніші за конвенцію іменування PEAR, введення їх у кодову базу зробить мій проект менш простим у використанні. Реалізуючи їх, я втрачаю деяку диференціацію з точки зору простоти використання.
  • Хоча я бачу деякі переваги для просторів імен, вони, схоже, не вирішують проблеми, яку потрібно вирішити в сучасному продукті PHP, який використовує конвенцію про іменування PEAR. Називання конфліктів під час використання мого проекту повинно бути мінімальним, якщо не існує.
  • Ця стаття дає мені деяку паузу у прийнятті просторів імен, оскільки їх реалізація була менш зоряною.
  • Я також вагаюся стрибати на естакаді, яка може нікуди не поїхати. Оскільки простори імен є новою функцією для PHP, я ще не впевнений, що вони стануть стандартними.
  • Сумісність. Майже весь PHP-код, який коли-небудь був написаний, не використовує простори імен, оскільки це нова функція. Інші бібліотеки були б несумісні без перетворення.

Деякі моменти використання просторів імен:

  • Сприйняття. Якщо простори імен стануть стандартними та найкращими практиками, мій проект може швидко розглядатися як непрофесійний та застарілий без них.
  • Конкуренція. Хоча деякі конкуруючі проекти PHP починають використовувати простори імен в останніх версіях, багато хто ще не зробив цей стрибок. Якщо це зробити зараз, це могло б дати мій проект ноги на інші проекти.
  • Майбутня робота буде простішою, якби я перейшов зараз до того, як проект стане загальнодоступним, а не після, коли мені доведеться на деякий час підтримувати дві його версії.
  • Я хочу підтримувати кращі практики, і якщо простори імен стануть найкращою практикою для PHP, мій проект повинен використовувати їх.

З того, що я можу сказати, ви повинні вибрати той чи інший спосіб; ви не можете зробити і те, і інше. Чи є моменти, які я не розглядав? Чи існують якісь об'єктивні знаки (не будь-яких полум'ям), які б вказували на або проти просторів імен, які стали професійним стандартом для PHP? Буду вдячний за будь-яке розуміння чи ресурси, якими ви хотіли б поділитися, як мені потрібно, щоб незабаром прийняти рішення.

Відповіді:


5

Тут залишаються два знаки, що простори імен у PHP:

  1. Схема іменування PEAR була скасована на користь просторів імен у PEAR2 .
  2. Однією з заявлених цілей Zend Framework 2.0 є стати прикладом використання PHP 5.3 , за рахунок повного використання просторів імен, серед іншого. Я вважаю це сильним свідченням того, що Зенд повністю відданий просторам імен і надалі підтримуватиме їх і розвиватиме (сподіваємося на краще).

Я повністю погоджуюсь з вами, що нинішньої реалізації просторів імен, як мінімум, бракує, але ваші аргументи проти їх використання не є такими надійними. Навіть у своєму поточному вигляді простори імен передбачають:

  • Краща організація коду,
  • Уникаючи іменних зіткнень,
  • Контекст для класів, функцій та констант.

Майте на увазі, що більшість аргументів проти просторів імен PHP є порівнянням з реалізаціями на інших мовах, а не проти їх фактичних достоїнств як функції.


+1 для посилань. Чи могли б ви розширити кращу організацію коду та точки контексту? Я трохи важко розумію, як це забезпечує кращу організацію коду. Здається, що більшість проектів буде дотримуватися класу 1: 1 для файлової структури, згрупованої в логічних каталогах, таку ж, яку ви використовували б у схемі іменування PEAR. Навіть ZF2 виглядає так, що він використовує однакові структури файлів і файлів у більшості випадків, але лише зараз з просторами імен. Це інакше, але я не обов'язково бачу, наскільки це краще чи організованіше, ніж в першу чергу добре названі каталоги та файли.
VirtuosiMedia

У мене також проблеми з контекстом. Якщо що-небудь, схоже, що простори імен видаляють контекст, щоб мати більш стильний стиль кодування, а не додавати контекст. Як приклад, якщо я інстанціюю новий клас глибоко у файлі, тепер мені потрібно знайти місце, де було оголошено простір імен, щоб зрозуміти, для якого класу це, а не одразу видно з назви класу. Якщо я чогось не пропускаю, здається, що простори імен є менш багатослівними, але за рахунок чіткості.
VirtuosiMedia

@VirtuosiMedia PEAR і старі схеми іменування ZF імітують простори імен, тому три мої моменти дещо вірні і для них. Я намагаюся зазначити, що якщо ці пункти є істинними в поточній реалізації просторів імен PHP, то їх невеликих снафів недостатньо, щоб не використовувати їх. Маючи на увазі кращу організацію коду, я маю на увазі переважно файли, прийняття розумної та логічної структури та ієрархії для ваших класів, що, звичайно, можливо без просторів імен. Але простори імен (і схеми, що імітують їх) - це особливість, яка допоможе вам досягти всіх трьох балів одночасно.
янніс

Готча. Дякуємо за роз’яснення. Чи бачите ви значні переваги для фактичних просторів імен над емуляційними просторами імен?
VirtuosiMedia

1
@VirtuosiMedia Усі пункти за використання просторів імен, які ви вказуєте на питання, є дійсними. До цього я додам, що простори імен PHP допомагають вашому коду відчувати себе трохи природніше кодерам з різного походження, що може бути неоціненним у великому проекті. Також не існує стандарту для емульованих просторів імен, переконайтесь, що більшість з них приблизно однакові, але використання фактичних просторів імен гарантує, що всі користуються однаковою схемою. До речі, там є пробірник імен , який ви можете використати, щоб ідентифікувати свій код.
янніс
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.