В ООП вы управляете объектами. Представим что вы — объект, человек. От того что я у вас номер на машине поменял — у вас машина тут же не обновилась до соответсвующего номера? Более того невозможно проверить существует ли машина с таким номером без запроса в базу.
ID — это то, что связывает сущность внутри приложения с строкой в таблице в базе. Это нельзя менять вот так вот просто
Вы опять спустились до уровня SQL. ID — это свойство сущности, но вы работаете с объектами. Доктрина позволяет делать так:
$user = new User();
$user->setFriend($em->find(3, 'Blabla\User'));
В данном случае на место друга встанет прокси объект с единственным определенным свойством — id:3, до тех пор пока вы не запросите какие-то свойства друга — ничего из базы загружено не будет. Вроде как можно даже что-то поменять и опять же грузиться ничего не должно, только обновится при $em->flush()
оО вот уж не думал что это проблема. Зачем тогда придумали интерфейс Serializable? Просто раз уж AR — кеширование должно быть через сам объект статическим методом
Недостатки DataMapper надуманные.
Дольше думать над чем? Управление сущностями ничем не отличается, кроме $dm->save($user); $user->save(); Но это на мой взгляд вообще не отличие. Ровно как и преимущество DM над AR в том что невозможно измнить mapper, просто не надо хардкодить PDO в конструкторе вот и все. На основе той же доктрины можно сделать AR, они сами описали в кукбуке этот момент.
Да, я хотел бы чтобы производители договорились об едином разъеме, но не чтобы производителей заставили о них договориться. На фотографии ужасающий разъем от какого-то производителя, который экономит на этом самом зарядном устройстве. На мой взгляд оно должно быть удобно, легко, а не удленитель с мундштуком для ноутбука. У Apple не идеальный зарядник, но наиболее близкий к идеалу. Надеюсь если когда-то производители договорятся о единой форме зарядника — она будет более удобна, чем у apple сейчас.
Я никак не мог побывать на php fw days, потому хотел бы спросить тут SamDark, каким образом DI загрязняет API кода?
Когда DI используется как ConainerAware(пример тому phalcon) — да, я понимаю, это не красиво.
Но когда у нас класс принимает класс через сеттер/конструктор — что в этом плохого, или не красивого? Возможно надо потратить чу-чуть больше времени на написание конфига для этого класса, но это же сократит время на написание «некрасивых», как вы сами выразились тестов.
И на счет слоев вопрос. Вы привели в пример кешер: stackoverflow.com/a/8900283/2252648, никаких слоев)
Конечно нет, вроде какая-то движуха есть с идеей «перенесем всю информации россиян с буржуйских серверов», еще они законы бы туда начали выкладывать. А тем более все будут следить за ходом законотворчества.
PS кстати интересная идея: данные по изменению законов открыты, можно взять например конституцию и создать репозиторий, а потом изучать изменения, я думаю там много чего интересного можно найти
Нет, я предлагаю хранить в отдельном репозитории зависимости. Например в разработке под ноду вообще считается правильным. Но если мы не хотим засорять историю апдейтами зависимостей — хранить их в отдельном репозитории уже скачанные
Мне казалось Satis — вариант легкого packagist. Просто статическое хранилище репозиториев.
Как вариант — хранить один отдельный репозиторий с vendor + composer.lock, и подтягивать его через git modules
Называется неблагодарность такое. Какой-то проект взял и открыл апи, а ему фидбек, ребята, что вы нам апи подсовываете, давайте шустро наши приложение в ваш сервис интегрируйте, и доплачивайте нам за то что мы разрешили
Это явно не разработчику решать, на что мне память нужна. Программа должна быть оптимизирована по максимому, а для ребят которые ставят свой продукт как mobile first такие цифры странны.
/**
* Main JS file for Casper behaviours
*/
/*globals jQuery, document */
(function ($) {
"use strict";
$(document).ready(function(){
// On the home page, move the blog icon inside the header
// for better relative/absolute positioning.
//$("#blog-logo").prependTo("#site-head-content");
});
}(jQuery));
Надеюсь таких косяков будет меньше, проект интересный, но сырой
То есть от того что у вас чего-то много — можно не задумываться об этом чем-то? Богатые люди являются таковыми не от того что они тратят деньги на лево и право. Ровно как и производителен компьютер до того момента, пока все его ресурсы не исчерпались.
Это цитаты из инициативы. На мой взгляд это манипуляция людьми, которые не вникают в ситуацию, а внимательно слушают лозунги, то что модно. Так или иначе тему надо раскрывать полностью, если все так как ниже написал ImGxx — значит надо сноску сделать на статью поясняющую это, но этого нет.
Есть куча стран, гораздо менее богатых чем наша, а общий уровень жизни там выше, есть свои проблемы, но как без них.
Спрос рождает предложение, да и от того что труд мигрантов не высокооплачиваемый он не становится качественным. На мой взгляд лучше сделать раз, но качественно (возможно дорого), чем каждый год чинить асфальт. Подобное надо в корне пересматривать, есть куча нюансов
Ну допустим я не хочу играть с компьютером. Я добавляю socket.io, и хочу сделать игру для двух юзеров. Передавать x, y шарика не рентабельно, я знаю скорость и конечную точку, на стороне другого игрока ее отрисовать пара пустяков. Как узнать конечную точку, куда летит шарик?)
ID — это то, что связывает сущность внутри приложения с строкой в таблице в базе. Это нельзя менять вот так вот просто
В данном случае на место друга встанет прокси объект с единственным определенным свойством — id:3, до тех пор пока вы не запросите какие-то свойства друга — ничего из базы загружено не будет. Вроде как можно даже что-то поменять и опять же грузиться ничего не должно, только обновится при
$em->flush()Дольше думать над чем? Управление сущностями ничем не отличается, кроме
$dm->save($user); $user->save();Но это на мой взгляд вообще не отличие. Ровно как и преимущество DM над AR в том что невозможно измнить mapper, просто не надо хардкодить PDO в конструкторе вот и все. На основе той же доктрины можно сделать AR, они сами описали в кукбуке этот момент.Когда DI используется как ConainerAware(пример тому phalcon) — да, я понимаю, это не красиво.
Но когда у нас класс принимает класс через сеттер/конструктор — что в этом плохого, или не красивого? Возможно надо потратить чу-чуть больше времени на написание конфига для этого класса, но это же сократит время на написание «некрасивых», как вы сами выразились тестов.
И на счет слоев вопрос. Вы привели в пример кешер: stackoverflow.com/a/8900283/2252648, никаких слоев)
PS кстати интересная идея: данные по изменению законов открыты, можно взять например конституцию и создать репозиторий, а потом изучать изменения, я думаю там много чего интересного можно найти
Как вариант — хранить один отдельный репозиторий с vendor + composer.lock, и подтягивать его через git modules
Надеюсь таких косяков будет меньше, проект интересный, но сырой
Есть куча стран, гораздо менее богатых чем наша, а общий уровень жизни там выше, есть свои проблемы, но как без них.
Спрос рождает предложение, да и от того что труд мигрантов не высокооплачиваемый он не становится качественным. На мой взгляд лучше сделать раз, но качественно (возможно дорого), чем каждый год чинить асфальт. Подобное надо в корне пересматривать, есть куча нюансов