Парсинг конфига из текстового файла

[stalxed]

@hell0w0rd, всё в кучу смешано:

PhpUnit - это целое семейство unit фреймворков, названо это семейство xUnit, его по косточкам разобрал Геральд Месарош(xunitpatterns.com). Его книга выходила даже на русском(лежит рядом, классная книга). И! Первый xUnit написан на smalltalk.

Hibernate, Doctrine 2 - это примеры Data Mapper, НО! Невозможно сделать Data Mapper не решив кучу смежных вопросов, что только стоят наследование(его mapping на SQL) и взаимосвязи. Больше половину книги корпоративных шаблонов Фаулер посветил именно этому. А потом с неё Hibernate и Doctrine 2 слизали решения. И кстати, код использующий Hibernate(клиентский код), имхо, выглядит уродливее, чем в Doctrine 2.
Когда Фаулер писал книгу Hibernate ещё не существовал(Hibernate начался в 2003, Фаулер написал в 2002).

Моя главная мысль: xUnit и Data Mapper существуют вне языков. Это теории, которые можно реализовать на любом ООП языке.

По поводу IDE, что PhpStrom говно, что Zend Studio. Плата за динамические типы в php. Вот например MS Visual Studio + ReSharper = реальная мощь, там такие финты вытворяются.... диву даёшься.

Symfony/FileSystem - это тупо удобно и логично.

На каждый чих и пук в "нормальных" проектах/фреймворках пишутся интерфейсы, в особо запущенных случаях обязательно есть абстрактный класс, даже если всего одна реализация далее по иерархии (привет Zend, sylius).

Это сделано, чтобы пользователи фреймворка могли его расширить.
А не делать форк.
Просто порой мучаешься расширить какую-то вещь фреймворка, а при гугление везде пишут - форкай.
Форки это не фига не круто... Это лишняя головная боль.
Так что пускай лучше будут лишние интерфейсы, лишние абстрактные классы.

И таки да, дженериков не хватает.
Перегрузки методов не хватает.
Перегрузки операторов не хватает.
Неявного, явного преобразования типов не хватает.

Но это не Java прихоти, это ООП прихоти.

 

[WMix]

ну во-первых

тебя обманули js изо всех сил набирает эти же технологии. и это не про яву (классы может и неявные но как их не хватает аж через жжжж эмулируют)

 

[Вурдалак]

ну во-первых на все класс. С этим можно спорить, но факт остается фактом - большинство современных фреймворков стараются не использовать функции и пишут классы.

ООП нужен для упрощения кода. Я хочу писать простой код. Приходишь ты и спрашиваешь: «почему ты пишешь простой код, на PHP нужно писать сложный и неподдерживаемый». Я, понятное дело, с тобой согласиться не могу, извини.

 

[hell0w0rd]

@Вурдалак, ну ты же лукавишь. Я привел в пример конкретный компонент.

$fs = new Filesystem();
$fs->mkdir('/tmp/random/dir/'.mt_rand());

из доки пример. В чем проблема была сделать mkdir функцией?

 

[AnrDaemon]

Простите, а на… тут вообще было объект припахивать? Почему нельзя было сделать

mkdir('/tmp/random/dir/'.mt_rand());

? Это менее читаемо? Хуже понятно?

 

[hell0w0rd]

тебя обманули js изо всех сил набирает эти же технологии. и это не про яву (классы может и неявные но как их не хватает аж через жжжж эмулируют)

какие те же?) Классы были всегда, не было синтаксического сахара и extends. es2015 на 90% синтаксический сахар и на 99% реализуется полифилами, кроме Proxy, что и понятно.

 

[hell0w0rd]

Ну и опять таки, я не говорю что js нужно во все задачи пихать. Я лишь не понимаю, почему java-way пихают в php, и не берут java. Я для себя только один довод знаю - скорость компиляции, и возможно специалиста сложнее найти.

 

[stalxed]

@Вурдалак, ну ты же лукавишь. Я привел в пример конкретный компонент.

$fs = new Filesystem();
$fs->mkdir('/tmp/random/dir/'.mt_rand());

из доки пример. В чем проблема была сделать mkdir функцией?

В C# подобное делают статиком, типа:
Filesystem::mkdir('/tmp/random/dir/'.mt_rand());
Называется там это служебными классами.
Все связанные функции группируются в один класс, это же удобно!
(Например тем, что можно использовать private static методы, тем самым устраняя дублирование кода между public static методами, и разбивая сложные функции на части. В случае использования обычных функций - такого функционала вы лишены).
Ну в данном пакете symfony тупанули... странно кстати почему.

 

[fixxxer]

Вовсе не тупанули. class SomeNonPosixDistributedFileSystem implements FileSystemContract

 

[fixxxer]

Вон, fixxer'у в языке с динамической типизацией не хватает дженериков

Вот в TypeScript они есть, и это прекрасно.
Динамическая типизация нужна не чтобы писать говно, а удобна на уровне инфраструктуры - т.к. 99% мы работаем с текстовыми протоколами.

почему java-way пихают в php

Это не java way, это ООП. ООП - это хорошо и удобно.

 

[hell0w0rd]

Вовсе не тупанули. class SomeNonPosixDistributedFileSystem implements FileSystemContract

Да нету там контракта никакого. Просто class Filesystem {.

Все связанные функции группируются в один класс, это же удобно!

Зачем это делать в языке, с возможностью написания отдельных функций?

 

[WMix]

Простите, а на… тут вообще было объект припахивать? Почему нельзя было сделать

mkdir('/tmp/random/dir/'.mt_rand());

? Это менее читаемо? Хуже понятно?

а тестить как? забудь про файловую систему, логика создай перенеси удали. чет запашек сразу пошел с экрана

$fs = new Filesystem();
$fs->mkdir('/tmp/random/dir/'.mt_rand());

в коде нет new там обжектик типа interface

 

[Вурдалак]

@Вурдалак, ну ты же лукавишь. Я привел в пример конкретный компонент.

$fs = new Filesystem();
$fs->mkdir('/tmp/random/dir/'.mt_rand());

из доки пример. В чем проблема была сделать mkdir функцией?

Если уж делать абстракцию над FS, то я бы отдельный интерфейс ввел, можно было бы нормально мокать и делать другие реализации. Хотя в принципе класс не final, мокать и так можно. Но с FS API вообще беда, это должно быть на уровне самого PHP. А мы как раз имеем дело с говно-функциями, которые не поддерживают полиморфизма.

Но в этой дискуссии делаешь акцент на частный случай: вот, эти ребята запилили сомнительный код, значит ООП — говно. Так не пойдёт.

 

[fixxxer]

Да нету там контракта никакого. Просто class Filesystem {.

А вот это плохо. Можно было бы сделать контракты FileSystem, File, SeekableFile и т.п. Были бы те же похапешные префиксы, только вменяемо.

Зачем это делать в языке, с возможностью написания отдельных функций?

В статики заворачивать действительно смысла нет никакого, особенно с появлением use function.

 

[Вурдалак]

В статики заворачивать действительно смысла нет никакого, особенно с появлением use function.

Автозагрузки функций нет.

 

[Absinthe]

yaml вообще убожество. Годится только если никогда не придётся трогать файл руками. Но тогда уже проще sqlite запилить. И намного удобнее.

yaml - это развитие json, в котором примитивность формата принесена в жертву читаемости.
Надеюсь, composer скоро начнет его поддерживать.

Если я могу JSON вбить от руки, и быть уверенным в том, что машина меня поймёт правильно, с YAML у меня такой уверенности нет.

А у меня есть. Потому что я не использую блокнот вместо IDE для разработки.

 

[hell0w0rd]

А у меня есть. Потому что я не использую блокнот вместо IDE для разработки.

И как тебе тут IDE поможет?

 

[Absinthe]

По поводу IDE, что PhpStrom говно, что Zend Studio. Плата за динамические типы в php. Вот например MS Visual Studio + ReSharper = реальная мощь, там такие финты вытворяются.... диву даёшься.

Это у тебя типы динамические. А у меня phpdoc, и в дальнейшем - php7. И такой тайпхинтинг - это местная строгая статическая типизация.
Если типизированные массивы и дженерики введут - и вовсе все будет замечательно, но большая часть работы уже сделана.

В C# подобное делают статиком

Все далают ошибки.

Все связанные функции группируются в один класс, это же удобно!

Это особенность C#: нельзя писать функции вне классов. Статический класс тут выполняет роль namespace.

И как тебе тут IDE поможет?

Не вижу никакой проблемы. В этом примере все однозначно.

 

[WMix]

И как тебе тут IDE поможет?

Strings in YAML can be wrapped both in single and double quotes.

 

[AnrDaemon]

я не использую блокнот вместо IDE для разработки.

Не поверишь - я счастлив, что есть на свете люди, у которых абсолютно всегда под рукой IDE. На каждый чих у них есть удобные инструменты, которые разве что не думают за них.
Я им искренне завидую.
К сожалению, я к таким людям не отношусь, и мне иногда приходится работать в голой консоли, когда наличие подсветки синтаксиса уже воспринимается как непередаваемое счастье. О чём-то большем мечтать уже не приходится.
Когда мне парсер говорит "ошибка в строке ХХХ", я открываю файл и вижу эту ошибку - я могу её исправить. Но когда я открываю файл и ошибки НЕ вижу - парсер идёт в задницу и я выбираю более удобные средства для выполнения задачи. В данном случае критерием удобства выступает логичность и наглядность представления данных.