На вопрос некоторых людей выше о том, что мол показывание точного времени есть цель поставленная свыше отвечают, что это всего лишь условия среды и это качество просто необходимо для выживания. Это логично и в принципе объясняет то, почему в конечном итоге в представленной модели часы эволюционировали до многострелочных и достаточно точных часов.
Однако у меня появляется вопрос, откуда в часах появилось стремление выживать и размножаться? Или это таки вопрос к теории происхождения жизни, на который теория эволюции не пытается дать ответ? Если так, то хотелось бы узнать, что теория зарождения говорит по этому поводу.
On Unix, with shell=False (default): In this case, the Popen class uses
os.execvp() to execute the child program. args should normally be a sequence.
A string will be treated as a sequence with the string as the only item
(the program to execute).
Буду говорить исключительно о своих личных впечатлениях.
1. Имя класса следует писать с большой буквы в стиле CamelCase. Ввиду отсутствия (на данный момент) неймспейсов, хорошо бы было добавить к именам классов префикс, например, MySuperLib_Events.
2. Перечислять в «шапке» класса сигнатуры методов, наверное, не стоит. Для этого есть аутлайнер в среде разработки. Остальные поля неплохо бы прокомментировать.
3. Singleton. Без гласной на конце.
4. Я предпочитаю функцию is_null конструкции === null.
5. В методе load класса events наблюдается жесткая связка класса с неким классом mysqlLayer по имени. Вместо этого можно использовать метод-сеттер, в который передавать объект, реализующий некий интерфейс.
6. Метод load может вернуть false, хотя в докблоке заявлено, что возвращаемое значение — self (что тоже, строго говоря, некорректно; в этом случае, насколько я понимаю, придется писать имя класса).
7. Метод get класса events нечитаем. По-моему, ему нужна декомпозиция и правильное форматирование.
В общем, извините за такие придирки. По сути к проектированию классов только пятую можно отнести. Тем не менее, надеюсь они окажутся чем-то полезными.
Вообще, из кода класса довольно трудно понять, что он делает, и имена методов не подсказывают их назначения.
В принципе исходя из своего опыта работы с геттекстом, я тоже не мог бы назвать его удачным решением проблемы, однако многие переводчики уже привыкли работать именно с ним и приходится с этим мириться.
Когда я размышлял о вопросе локализации текстов, то мне на ум приходил вариант, который я бы назвал объектно-ориентированным. Зачастую переводить нужно не только надписи на кнопках и простые фразы, состоящие из одного-двух приложений, а целые письма, состоящие из нескольких абзацев, содержащие медиа-вложения и прочее.
Хотелось бы чтобы для всего этого использовался один подход (хотя бы идеологически). Сама собой приходит идея выделения всех переводных сущностей из текста и некий механизм привязки этих сущностей к тексту. Пока только к сожалению ничего конкретного не удалось придумать, т.к. хватает других задач.
Предложенный вами подход в целом интересен, для простых проектов использовать его может быть целесообразно. Еще раз прошу прощения, что невнимательно прочитал топик в первый раз :)
Виноват. Признаюсь, не прочитал целиком, потому что подумал что если вы знаете про gettext, то у вас не должно появляться такого вопроса. И да, gettext действительно не очень удобен, когда несколько числительных идут в одной фразе, хотя такая ситуация и встречается не очень часто.
Питон ваши строковые айдишники отсортирует и поместит в конец списка. Получится у вас [6, 7, '13', '5'].
И я очень сомневаюсь, что такой результат вас устраивает, потому что '5' оказывается после 6, что это за сортировка такая? Будете удивляться, почему у вас «гладиолусы обыкновенные» ('5') выводятся позже «гладиолусов с секретом», хотя идентификаторы то идут в другом порядке, а строкой пятерку вы сделали, как сами признались, для того, чтобы «не путалось».
В итоге вам все равно нужно будет написать свое правило сортировки, которое вас удовлетворит. Пример не засчитан.
Я это заметил — но это ничего не изменило. Вы пишете что вы называете массив отсортированным если «ai < aj, j ⊆ {x | i+1 < x ≤ n}». Так вот у вас это неверно если i равно нулю, а j равно трём.
С чего же? Функция, которая задает сортировку, приведена. Если ей передать '5' и '13' она вернет отрицательное число, что значит, что '5' меньше '13' по тем правилам, которые я выбрал для данной конкретной сортировки. Где вы видите противоречие?
Мне кажется не стоит хаять языки программирования. Они даны — играйте по их правилам.
Ну вот в том то и дело, что сортирует, но по другим правилам. Эти правила я причем определил сам, передав функцию их описывающую параметром метода sort, как вы, наверное, заметили.
Любой упорядоченный набор элементов я могу назвать отсортированным, если смогу придумать для него условие сортировки, которому он удовлетворяет. Даже численную сортировку можно сделать двумя способами — в прямом и обратном порядке. Если вы привыкли сортировать в прямом, значит ли это, что массив, отсортированный в обратном, вовсе и не является сортированным?
То, что вы утверждаете, что операторы < и > в Яваскрипте и ПХП не являются отношениями порядка — абсолютно верно. И если уж подходить к вопросу с позиции отношения порядка, то как раз в вашем примере массив не является отсортированным, т.к. 7 < '13', но больше 6.
Было бы кстати очень узнать источник тех двух свойств отсортированных массивов, о которых вы говорите в своем комментарии чуть выше.
Сортировка — расположение элементов списка в определенном порядке. Когда вы отсортировали массив и получили [7, «13», «5», 6], вы делали это по вами же заданным правилам. Например я могу написать такой код:
arr = [7, "13", "5", 6];
arr.sort(function(a, b) {
return a - b;
});
Соответственно, я получу массив [«5», 6, 7, «13»] — массив, отсортированный по моим правилам (а именно ai < aj, j ⊆ {x | i+1 < x ≤ n}). По вашим правилам он не будет считаться отсортированным. Так вот, когда я удаляю элемент из массива предложенным вами методом, то по моим правилам он остается отсортированным, т.к. ваш метод корректно удаляет элемент.
Вы же придумали (или просто не задумывались о том, что оно есть) свое правило, которое является достаточно вычурным, а в своем методе удаления элемента это правило не учитываете. Вас же не удивляет, что при удалении элемента из сбалансированного двоичного дерева, иногда необходима операция поворота и перебалансировки?
Однако у меня появляется вопрос, откуда в часах появилось стремление выживать и размножаться? Или это таки вопрос к теории происхождения жизни, на который теория эволюции не пытается дать ответ? Если так, то хотелось бы узнать, что теория зарождения говорит по этому поводу.
Это вы о чем? В документации написано:
On Unix, with shell=False (default): In this case, the Popen class uses os.execvp() to execute the child program. args should normally be a sequence. A string will be treated as a sequence with the string as the only item (the program to execute).1. Имя класса следует писать с большой буквы в стиле CamelCase. Ввиду отсутствия (на данный момент) неймспейсов, хорошо бы было добавить к именам классов префикс, например, MySuperLib_Events.
2. Перечислять в «шапке» класса сигнатуры методов, наверное, не стоит. Для этого есть аутлайнер в среде разработки. Остальные поля неплохо бы прокомментировать.
3. Singleton. Без гласной на конце.
4. Я предпочитаю функцию is_null конструкции === null.
5. В методе load класса events наблюдается жесткая связка класса с неким классом mysqlLayer по имени. Вместо этого можно использовать метод-сеттер, в который передавать объект, реализующий некий интерфейс.
6. Метод load может вернуть false, хотя в докблоке заявлено, что возвращаемое значение — self (что тоже, строго говоря, некорректно; в этом случае, насколько я понимаю, придется писать имя класса).
7. Метод get класса events нечитаем. По-моему, ему нужна декомпозиция и правильное форматирование.
В общем, извините за такие придирки. По сути к проектированию классов только пятую можно отнести. Тем не менее, надеюсь они окажутся чем-то полезными.
Вообще, из кода класса довольно трудно понять, что он делает, и имена методов не подсказывают их назначения.
π — Да что ты о себе мнишь?!
Может быть так? :)
Когда я размышлял о вопросе локализации текстов, то мне на ум приходил вариант, который я бы назвал объектно-ориентированным. Зачастую переводить нужно не только надписи на кнопках и простые фразы, состоящие из одного-двух приложений, а целые письма, состоящие из нескольких абзацев, содержащие медиа-вложения и прочее.
Хотелось бы чтобы для всего этого использовался один подход (хотя бы идеологически). Сама собой приходит идея выделения всех переводных сущностей из текста и некий механизм привязки этих сущностей к тексту. Пока только к сожалению ничего конкретного не удалось придумать, т.к. хватает других задач.
Предложенный вами подход в целом интересен, для простых проектов использовать его может быть целесообразно. Еще раз прошу прощения, что невнимательно прочитал топик в первый раз :)
И я очень сомневаюсь, что такой результат вас устраивает, потому что '5' оказывается после 6, что это за сортировка такая? Будете удивляться, почему у вас «гладиолусы обыкновенные» ('5') выводятся позже «гладиолусов с секретом», хотя идентификаторы то идут в другом порядке, а строкой пятерку вы сделали, как сами признались, для того, чтобы «не путалось».
В итоге вам все равно нужно будет написать свое правило сортировки, которое вас удовлетворит. Пример не засчитан.
С чего же? Функция, которая задает сортировку, приведена. Если ей передать '5' и '13' она вернет отрицательное число, что значит, что '5' меньше '13' по тем правилам, которые я выбрал для данной конкретной сортировки. Где вы видите противоречие?
Мне кажется не стоит хаять языки программирования. Они даны — играйте по их правилам.
Любой упорядоченный набор элементов я могу назвать отсортированным, если смогу придумать для него условие сортировки, которому он удовлетворяет. Даже численную сортировку можно сделать двумя способами — в прямом и обратном порядке. Если вы привыкли сортировать в прямом, значит ли это, что массив, отсортированный в обратном, вовсе и не является сортированным?
То, что вы утверждаете, что операторы < и > в Яваскрипте и ПХП не являются отношениями порядка — абсолютно верно. И если уж подходить к вопросу с позиции отношения порядка, то как раз в вашем примере массив не является отсортированным, т.к. 7 < '13', но больше 6.
Было бы кстати очень узнать источник тех двух свойств отсортированных массивов, о которых вы говорите в своем комментарии чуть выше.
arr = [7, "13", "5", 6]; arr.sort(function(a, b) { return a - b; });Соответственно, я получу массив [«5», 6, 7, «13»] — массив, отсортированный по моим правилам (а именно ai < aj, j ⊆ {x | i+1 < x ≤ n}). По вашим правилам он не будет считаться отсортированным. Так вот, когда я удаляю элемент из массива предложенным вами методом, то по моим правилам он остается отсортированным, т.к. ваш метод корректно удаляет элемент.
Вы же придумали (или просто не задумывались о том, что оно есть) свое правило, которое является достаточно вычурным, а в своем методе удаления элемента это правило не учитываете. Вас же не удивляет, что при удалении элемента из сбалансированного двоичного дерева, иногда необходима операция поворота и перебалансировки?
А форматы без потерь — все-таки lossless.