Июль 2009 (Обсуждаем)

[Paul_ls]

Ну вот, выслали по почте, дали скачать, можно начинать (почти стихи ).
Вы знаете, предыдущие номера я просматривал уже чисто номинально, ибо сравнения типа Ubuntu vs Mandriva и им подобные приелись уже. Из номера в номер практически одно и то же, а самые интересные мне статьи остались за бортом при "похудении" журнала.
Надо отметить, что июльский номер вышел на славу! Конечно, и здесь не обошлось без Ubuntu и Mandriva, ну куда же от них денешься.
В общем моё впечатление - давненько таких полезных и интересных номеров не было. Даже сложно сказать какая статья понравилась больше всех.
Верной дорогой идёте, товарищи!

[eddy]

сравнения типа Ubuntu vs Mandriva и им подобные приелись уже.

+1 Достали, честное слово. Особенно с бубунтой, как будто это самый популярный дистрибутив.
Кроме того, хорошо было бы, если б на диске был софт из обзоров. Например, хочется попробовать CAD'ы, о которых писали, а на диске их нет.

[Minton]

сравнения типа Ubuntu vs Mandriva и им подобные приелись уже.

+1 Достали, честное слово. Особенно с бубунтой, как будто это самый популярный дистрибутив.

Убунту действительно самый популярный дистрибутив, с этим-то надо как-то жить.

[Val]

а самые интересные мне статьи остались за бортом при "похудении" журнала.

Это, кстати, какие?

Верной дорогой идёте, товарищи!

Спасибо.

[vinny]

Например, хочется попробовать CAD'ы, о которых писали, а на диске их нет.

а что уже есть живые аналоги? год назад протестировали всё существующие... и не нашли продукта, который было бы можно поставить клиентам и не краснеть за это целыми днями.

[Cossack]

хм, это только у меня не оказалось LXFDVD в комплекте?

[sash-kan]

хм, это только у меня не оказалось LXFDVD в комплекте?

mailto:info@linuxcenter.ru

[Cossack]

хм, это только у меня не оказалось LXFDVD в комплекте?

mailto:info@linuxcenter.ru

я в курсе, уже не раз с ними общался просто мож всем так же пришло

[transkontrol]

ужос!!!

учебник по GData, стр.61, код удаления имеющегося документа и пояснение этому коду:

"Удивительно, но в случае отсутствия требуемого документа метод ... не возвращает null или пустой объект ...., а выбрасывает исключение. Это не очень удобно, ..." (и далее)

Извините, но это вообще как понимать!? Это ведь и новички читают, а они могут эту дезу и на веру принять! А потом не каждый может понять почему так не надо делать. С каких это пор вместо исключений стало удобнее возвращать нечто, не имеющее отношения к затребованному объекту? Если уж на то пошло, то после удаления (совершенно лишней) "специальной логической переменной", код получается примерно таким:

Код: Выделить всё

try{
    $doc = $mydocuments->getDocumentListEntry($query);
    echo 'Удаляю...', $doc->title;
    $doc->delete();
}catch(Exception $e){
    //нет, ну и не надо
}

[Val]

Извините, но это вообще как понимать!? Это ведь и новички читают, а они могут эту дезу и на веру принять!

Это надо понимать так, что возвратить что-то вроде null в данном случае совершенно естественно - отсутствие документа, удовлетворяющего условию запроса, не является исключительной ситуацией (в отличие, например, от попытки получить объект по неустановленному соединению). Кидать здесь исключение равносильно требованию "любой запрос должен давать непустой ответ". Вы много знаете API баз данных, для которых синтаксически верный SELECT из нормальной таблицы, возвративший пустой рекордсет, выбрасывает исключение? Вот то-то же.
Поэтому не надо дезинформировать новичков магией исключений - у них есть давно сложившаяся область применения. Я уж молчу о том, что для PHP (имхо, конечно) они чужеродны by design, ну так GData не для него и проектировался.

нечто, не имеющее отношения к затребованному объекту?

Вот именно, исключение в неисключительной ситуации - нечто, не имеющее отношения к затребованному объекту. А вот объект, представляющий ноль записей, для синтаксически корректного запроса, которому соответствует ноль записей - это именно то, что имеет отношение к затребованному. Просто по определению.

[transkontrol]

Извините, но это вообще как понимать!? Это ведь и новички читают, а они могут эту дезу и на веру принять!

Это надо понимать так, что возвратить что-то вроде null в данном случае совершенно естественно - отсутствие документа, удовлетворяющего условию запроса, не является исключительной ситуацией (в отличие, например, от попытки получить объект по неустановленному соединению). Кидать здесь исключение равносильно требованию "любой запрос должен давать непустой ответ". Вы много знаете API баз данных, для которых синтаксически верный SELECT из нормальной таблицы, возвративший пустой рекордсет, выбрасывает исключение? Вот то-то же.
Поэтому не надо дезинформировать новичков магией исключений - у них есть давно сложившаяся область применения. Я уж молчу о том, что для PHP (имхо, конечно) они чужеродны by design, ну так GData не для него и проектировался.

нечто, не имеющее отношения к затребованному объекту?

Вот именно, исключение в неисключительной ситуации - нечто, не имеющее отношения к затребованному объекту. А вот объект, представляющий ноль записей, для синтаксически корректного запроса, которому соответствует ноль записей - это именно то, что имеет отношение к затребованному. Просто по определению.

Здесь метод запрашивает __конкретный__ документ, а не __список__ документов, удовлетворяющих условию. Иначе, тогда где проверка количества возвращённых документов, и почему удаляется только один и без оглядки на остальные? А select из базы - это запрос списка. Пустой список тоже список. Так что это разные вещи. Исключение для селективного запроса - это как раз отсутствие соединения, синтаксическая ошибка. Встречный вопрос - что вернёт синтаксически корректный запрос к базе при неверно указанной (отсутствующей) таблице? Цитирую классика: "Вот то-то же".

А для новичков могу напомнить одно из простых мнемонических правил, если метод (функция) говорит "дайОбъектТакойТо()", то и возвращать этот метод(функция) всегда должны объект, а не пустоту. А уж реакция на отсутствующий объект: исключение или создание нового объекта этим методом "на лету" - детали реализации конкретного метода.

PS Конечно же, речь идёт о сущностях, имеющих понятия об исключениях, и бесполезно требовать исключений, например, от PHP3

[Val]

Здесь метод запрашивает __конкретный__ документ, а не __список__ документов, удовлетворяющих условию.

Я так и думал, что Вы к этом прицепитесь Разве это принципиально? Замените во фразе выше "объект с нулем записей" на "пустой объект", он же null. Относительно конкретности документа - см. ниже: мы все же делаем запрос.

А select из базы - это запрос списка. Пустой список тоже список. Так что это разные вещи.

Собственно, у нас с Вами разница во мнении как раз в этом. Для меня пустой объект - тоже объект, да и запрос "SELECT COUNT(*) FROM t WHERE ..." вернет не список, а скаляр, причем в продвинутых API (вроде, страх сказать, ADO.NET) есть специальные методы для выполнения именно такого скалярного запроса (можно, конечно, и "SELECT 1" ему подсунуть, но он никогда не пуст). И да, они вернут null или аналогичный пустой результат, если в таблице нет строк, удовлетворяющих условию WHERE.

Исключение для селективного запроса - это как раз отсутствие соединения, синтаксическая ошибка. Встречный вопрос - что вернёт синтаксически корректный запрос к базе при неверно указанной (отсутствующей) таблице? Цитирую классика: "Вот то-то же".

Не "то-то же", не надо менять пример Ни у кого не вызывает вопросов исключение, выбрасываемое, если $mydocuments указывает на недопустимый объект. Речь о том, что я прошу из него некую запись - и хочу иметь за собой право запросить что угодно, не считаясь ненормальным (т.е. не получая исключений).

А для новичков могу напомнить одно из простых мнемонических правил, если метод (функция) говорит "дайОбъектТакойТо()", то и возвращать этот метод(функция) всегда должны объект, а не пустоту. А уж реакция на отсутствующий объект: исключение или создание нового объекта этим методом "на лету" - детали реализации конкретного метода.

А это правило нигде не нарушается: пустота (с точки зрения синтаксиса языка) есть объект любого типа, в том смысле, что конструкция, аналогичная "object = null" допустима для любого object.

PS Конечно же, речь идёт о сущностях, имеющих понятия об исключениях, и бесполезно требовать исключений, например, от PHP3

Я имел в виду, что от PHP5 их требовать можно, но не нужно (как было написано в одной хорошей книге поп программированию: "если вы можете вставить горошину в ухо, не значит, что вы должны это делать"). Однако, это мое лично мнение, и к рассматриваемому вопросу оно имеет косвенное отношение - я его никому не навязываю.

Надо сказать, что исключению при отсутствии документа можно придать некий смысл, если рассматривать работу с Google Docs не как взаимодействие с БД, а как файловую систему. Вполне ожидаемо, что вызов File.Open("some_absent_file") должен выкинуть исключение типа FileNotFound. Разница здесь такая: во втором случае предполагается, что я знаю имя файла (то есть его уникальный идентификатор), который хочу открыть, в первом я составляю *запрос*, т.е. описываю свойства элемента, который мне нужен, ничего не зная о нем самом: исключение в File.Find() кажется уже менее логичным.

Но вот беда: стандартная PHP'шная fopen() при отсутствии файла возвращает FALSE (попутно генерируя E_WARNING, конечно, ну так что с того?)

[transkontrol]

Здесь метод запрашивает __конкретный__ документ, а не __список__ документов, удовлетворяющих условию.

Я так и думал, что Вы к этом прицепитесь Разве это принципиально? Замените во фразе выше "объект с нулем записей" на "пустой объект", он же null. Относительно конкретности документа - см. ниже: мы все же делаем запрос.

Это "очень принципиально"! Объект и список объектов - это разные вещи: целое и массив целых.

А select из базы - это запрос списка. Пустой список тоже список. Так что это разные вещи.

Собственно, у нас с Вами разница во мнении как раз в этом. Для меня пустой объект - тоже объект, да и запрос "SELECT COUNT(*) FROM t WHERE ..." вернет не список, а скаляр, причем в продвинутых API (вроде, страх сказать, ADO.NET) есть специальные методы для выполнения именно такого скалярного запроса (можно, конечно, и "SELECT 1" ему подсунуть, но он никогда не пуст). И да, они вернут null или аналогичный пустой результат, если в таблице нет строк, удовлетворяющих условию WHERE.

Эти запросы всегда возвращают объекты, "указатели на результат", которые в свою очередь могут быть пустыми. Не так ли?

Исключение для селективного запроса - это как раз отсутствие соединения, синтаксическая ошибка. Встречный вопрос - что вернёт синтаксически корректный запрос к базе при неверно указанной (отсутствующей) таблице? Цитирую классика: "Вот то-то же".

Не "то-то же", не надо менять пример Ни у кого не вызывает вопросов исключение, выбрасываемое, если $mydocuments указывает на недопустимый объект. Речь о том, что я прошу из него некую запись - и хочу иметь за собой право запросить что угодно, не считаясь ненормальным (т.е. не получая исключений).

угу, запросить список и получить опять же список, но не конкретный объект. Что-то не совсем понял мысль про исключение, если некорректный $mydocuments. Прошу пояснить

А для новичков могу напомнить одно из простых мнемонических правил, если метод (функция) говорит "дайОбъектТакойТо()", то и возвращать этот метод(функция) всегда должны объект, а не пустоту. А уж реакция на отсутствующий объект: исключение или создание нового объекта этим методом "на лету" - детали реализации конкретного метода.

А это правило нигде не нарушается: пустота (с точки зрения синтаксиса языка) есть объект любого типа, в том смысле, что конструкция, аналогичная "object = null" допустима для любого object.

Что в таком случае вернёт $doc->title ? Зачем мне лишние телодвижения, если я знаю, что возвращается то, что я запросил? А если что-то пошло не так, то и обрабатываться возникшая ситуация будет, там где это нужно. Хуже всего, когда люди только не понимают смысла происходящего, только в силу костности мышления, к "методам с исключениями" прикручивают обёртки:

Код: Выделить всё

function wrapperGetObject(){
    try{
        $object = $this->GetObject();
    }catch(Exception $e){
        $object = false;
    }
    return $object;
}

Как потом применяется этот "метод", думаю, очевидно. Если автору самому не нравится исключения по каким-либо причинам, то, моё ИМХО, не стоит культивировать неприятие этого у остальных.

PS Конечно же, речь идёт о сущностях, имеющих понятия об исключениях, и бесполезно требовать исключений, например, от PHP3

Я имел в виду, что от PHP5 их требовать можно, но не нужно (как было написано в одной хорошей книге поп программированию: "если вы можете вставить горошину в ухо, не значит, что вы должны это делать"). Однако, это мое лично мнение, и к рассматриваемому вопросу оно имеет косвенное отношение - я его никому не навязываю.

Надо сказать, что исключению при отсутствии документа можно придать некий смысл, если рассматривать работу с Google Docs не как взаимодействие с БД, а как файловую систему. Вполне ожидаемо, что вызов File.Open("some_absent_file") должен выкинуть исключение типа FileNotFound. Разница здесь такая: во втором случае предполагается, что я знаю имя файла (то есть его уникальный идентификатор), который хочу открыть, в первом я составляю *запрос*, т.е. описываю свойства элемента, который мне нужен, ничего не зная о нем самом: исключение в File.Find() кажется уже менее логичным.

Но вот беда: стандартная PHP'шная fopen() при отсутствии файла возвращает FALSE (попутно генерируя E_WARNING, конечно, ну так что с того?)

ИМХО, рассматривать работу с ГуглоДоком надо просто как работу с хранилищем, без привязки к тому, БД это, ФС, либо что-то ещё. И снова, поиск возвращает список, набор, перечисление найденных объектов. А стандартная fopen растёт далеко не из PHP5

[Val]

Это "очень принципиально"! Объект и список объектов - это разные вещи: целое и массив целых.

В объектно-ориентированном проектировании хорошо известен паттерн "Composite" (или, по-русски, "Компоновщик"), задача которого - обеспечить унифицированную работу с целым и массивом целых на уровне интерфейса. Настоятельно рекомендуется к использованию, ибо сильно упрощает жизнь (хотя панацеей, как и все остальное, не является). Технические различия между целым и массивом целых в данном случае роли не играют - см. "инкапсуляция".

Эти запросы всегда возвращают объекты, "указатели на результат", которые в свою очередь могут быть пустыми. Не так ли?

Если говорить конкретно про ADO.NET, то он возвращает банальный Object, ибо скаляр, возвращенный SELECT, может быть любого типа. Или null, если SELECT не вернул ничего. Конкретно в .NET для упрощения интеграции с базами данных придуманы даже nullable-типы. Нет, я не фанат ADO.NET и ничего давно на нем не писал - просто пришлось к слову В других API это может быть реализовано как-то по-другому.

угу, запросить список и получить опять же список, но не конкретный объект. Что-то не совсем понял мысль про исключение, если некорректный $mydocuments. Прошу пояснить

Например, в промежутке между созданием $mydocuments В программе и вызовом getDocumentListEntry() у меня пропала связь с сервером Google. Объект формально есть, но он стал внутренне некорректен. В таком случае я морально готов получить исключение. Опять же, я морально готов получить исключение при запросе элемента по id (т.е. прямо URL), но не при поисковом запросе. Зачем было объединять метод, выполняющий запрос и метод, возвращающий один конкретный результат, я не знаю - но ноги у проблемы, имхо, растут отсюда.

Что в таком случае вернёт $doc->title ?

Вы не поверите... Оно выкинет исключение! Причем в полном соответствии с его назначением: при нормальном течении программы null разыменовываться не должен.

Зачем мне лишние телодвижения, если я знаю, что возвращается то, что я запросил?

"Самоуверенность в программировании ведет к провалу" (кажется, Триджелл или Эллисон). Запрос на поиск чего-то от требования выдать что-то уникально заданное отличается как раз тем, что может не вернуть ничего (или вернуть много всего) - и это нормально.

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

Такой подход хорошо работает в Java и других языках с checked expections (если вспомнить, что API GData изначально разрабатывался для них, надо признать, что смысл в этом есть). В других же языках, как показывает практика, они не будут обрабатываться нигде (при этом проверку на null народ почему-то не забывает). Впрочем, к нашему вопросу это имеет мало отношения.

ИМХО, рассматривать работу с ГуглоДоком надо просто как работу с хранилищем, без привязки к тому, БД это, ФС, либо что-то ещё. И снова, поиск возвращает список, набор, перечисление найденных объектов. А стандартная fopen растёт далеко не из PHP5

Тут вы опять же правы. Но если рассматривать его как вещь в себе, то понятия "удивительно", "удобно" и т.п. неприменимы - они обретают смысл только в контексте остального мира.

[transkontrol]

Это "очень принципиально"! Объект и список объектов - это разные вещи: целое и массив целых.

В объектно-ориентированном проектировании хорошо известен паттерн "Composite" (или, по-русски, "Компоновщик"), задача которого - обеспечить унифицированную работу с целым и массивом целых на уровне интерфейса. Настоятельно рекомендуется к использованию, ибо сильно упрощает жизнь (хотя панацеей, как и все остальное, не является). Технические различия между целым и массивом целых в данном случае роли не играют - см. "инкапсуляция".

Не уловил связи. Вообще.

угу, запросить список и получить опять же список, но не конкретный объект. Что-то не совсем понял мысль про исключение, если некорректный $mydocuments. Прошу пояснить

Например, в промежутке между созданием $mydocuments В программе и вызовом getDocumentListEntry() у меня пропала связь с сервером Google. Объект формально есть, но он стал внутренне некорректен. В таком случае я морально готов получить исключение. Опять же, я морально готов получить исключение при запросе элемента по id (т.е. прямо URL), но не при поисковом запросе. Зачем было объединять метод, выполняющий запрос и метод, возвращающий один конкретный результат, я не знаю - но ноги у проблемы, имхо, растут отсюда.

Скорее у проблемы ноги растут от того, что вы почему-то рассматриваете этот метод, как метод возвращающий множественное значение. Почему - мне не понятно. Я же считаю, что по логике задачи здесь требование уникального документа. Если это рассматривать как поисковый запрос, то где обработка более чем одного найденного документа?

Кроме этого, при разрыве соединения и при отсутствии запрошенного документа должны быть разные исключения, которые и обрабатываться могут не только по-разному, но и в разных местах. Если нет соединения, то и добавлять новый документ смысла нет. Здесь же прибиваются все вылетающие исключения. По моему так. Но это, я думаю, вы согласитесь, тема отдельного обсуждения.

Что в таком случае вернёт $doc->title ?

Вы не поверите... Оно выкинет исключение! Причем в полном соответствии с его назначением: при нормальном течении программы null разыменовываться не должен.

КТО!? Кто оно? Объекта нет, значит он и не сможет ничего выкинуть, значит если и будет ругань, то только из-за настроек самого пхп.

Зачем мне лишние телодвижения, если я знаю, что возвращается то, что я запросил?

"Самоуверенность в программировании ведет к провалу" (кажется, Триджелл или Эллисон). Запрос на поиск чего-то от требования выдать что-то уникально заданное отличается как раз тем, что может не вернуть ничего (или вернуть много всего) - и это нормально.

Опять же, запрос на поиск - возврат набора объектов. Здесь же запрос одного документа.
Опять же есть здесь поиск нескольких документов, то где обработка (удаление) остальных?
И если мы не уверены в возвращаемом результате, то надо бы проверять результат не на принадлежность к null, а удостоверяться, что вернулся объект нужного типа (класса, размерности и тд).

ИМХО, рассматривать работу с ГуглоДоком надо просто как работу с хранилищем, без привязки к тому, БД это, ФС, либо что-то ещё. И снова, поиск возвращает список, набор, перечисление найденных объектов. А стандартная fopen растёт далеко не из PHP5

Тут вы опять же правы. Но если рассматривать его как вещь в себе, то понятия "удивительно", "удобно" и т.п. неприменимы - они обретают смысл только в контексте остального мира.

Тут скорее в контексте реального субъекта. Например, в рассматриваемом случае, ИМХО очень неудобно вместо конкретного объекта получать пустышку. Очень не информативно.

[Val]

Не уловил связи. Вообще.

Ну Бог с ним. Это опять же непринципиально.

Скорее у проблемы ноги растут от того, что вы почему-то рассматриваете этот метод, как метод возвращающий множественное значение. Почему - мне не понятно. Я же считаю, что по логике задачи здесь требование уникального документа. Если это рассматривать как поисковый запрос, то где обработка более чем одного найденного документа?

Эти вопросы надо задать разработчику API - меня они тоже интересуют (собственно, в связи с этим в статье и было сделано примечание). Тот факт, что аргументом getDocumentListEntry() может быть URL записи или поисковый запрос (query), утвержден в документации, к каким неудобствам это приводит, я уже указал. А что будет, если моему запросу удовлетворяют два элемента списка? А если десять? Исходя из общего опыта знакомства с API доступа к различным системам хранения данных, я не смогу дать ответ на этот вопрос - скорее всего, тоже выбросится исключение. Именно это и имеется в виду, когда говорится о неудобстве: в этой части API нарушает сложившиеся паттерны.

Кроме этого, при разрыве соединения и при отсутствии запрошенного документа должны быть разные исключения, которые и обрабатываться могут не только по-разному, но и в разных местах. Если нет соединения, то и добавлять новый документ смысла нет. Здесь же прибиваются все вылетающие исключения. По моему так. Но это, я думаю, вы согласитесь, тема отдельного обсуждения.

Разумеется - я просто проиллюстрирвоал, какие (на мой взгляд) ситуации в вызове этого метода будут исключительными.

Что в таком случае вернёт $doc->title ?

Вы не поверите... Оно выкинет исключение! Причем в полном соответствии с его назначением: при нормальном течении программы null разыменовываться не должен.

КТО!? Кто оно? Объекта нет, значит он и не сможет ничего выкинуть, значит если и будет ругань, то только из-за настроек самого пхп.

Оно - среда времени выполнения PHP, конечно. Или виртуальная машина Java. Или CLR. Или, в случае компилируемого языка, аж ядро ОС, хотя и опосредованным путем. В любом случае, исключение в той или иной форме будет. Касательно PHP, самое веселое то, что в моем дистрибутиве ругани никакой не будет - его надо специально пощекотать, чтобы он начал показывать тексты ошибок и исключений. Настройка прекрасна для хостинга и не очень - для разработчика, особенно прибегающего к PHP эпизодически

Опять же, запрос на поиск - возврат набора объектов. Здесь же запрос одного документа.
Опять же есть здесь поиск нескольких документов, то где обработка (удаление) остальных?

Здесь имеет место поиск _одного_ документа с заданными свойствами. Я (в общем случае) не уверен, что он там есть - но прошу систему вернуть его или сказать мне, что его нет. Исключение здесь, конечно, вариант, но не самый распространенный и не самый естественный.

И если мы не уверены в возвращаемом результате, то надо бы проверять результат не на принадлежность к null, а удостоверяться, что вернулся объект нужного типа (класса, размерности и тд).

Зависит от API. Некоторые вернули бы в любом случае объект типа Entry, но у него бы бы метод типа isEmpty(). Другие вернули бы null и не задумывались, отметив это в документации как признак отсутствия записей, удовлетворяющих моим требованиям. Вопрос не в том, что именно вернуть, вопрос в том, что исключение "ничего не найдено" для операции поиска (пусть даже одно-единственного элемента) - не самое удобное решение.

Тут скорее в контексте реального субъекта. Например, в рассматриваемом случае, ИМХО очень неудобно вместо конкретного объекта получать пустышку. Очень не информативно.

Пустышка (в смысле, гипотетический объект Entry, для которго isEmpty() вернул бы TRUE) здесь была бы неудобна. А вот конструкция типа if ($doc = $mydocuments->GetDocumentListEntry($query)) здесь прямо-таки напрашивается. Хотя, возможно, я просто перпрограммирвоал на неправильных языках и платформах

[transkontrol]

Эх, "у попа была собака...."

Вы твёрдо уверены, что имеет место поисковый запрос, но не требование конкретного документа?

[Val]

Эх, "у попа была собака...."

Вы твёрдо уверены, что имеет место поисковый запрос, но не требование конкретного документа?

getDocumentListEntry (line 119)
...
* mixed $location: The location for the entry, as a URL or Query

(см. http://framework.zend.com/apidoc/core/Zend...umentListEntry). В примере в статье создается именно запрос, как можно видеть по строке

Код: Выделить всё

$query = new Zend_Gdata_Docs_Query();

И как утверждается в справочном руководстве разработчика по GData, Query - это поисковый запрос (http://code.google.com/intl/ru/apis/gdata/docs/2.0/reference.html#Queries), для обращения к конкретному объекту у него есть уникальные URL. Поэтому таки да, я уверен, что мы делаем запрос (который, по идее, должен вернуть ровно один объект, но может также не вернуть ничего или вернуть несколько записей, благо Google Docs не требует, чтобы title у всех объектов был разный). Если бы мы хотели получить конкретный документ, мы бы сделали вызов $mydocuments->getDocumentListEntry(URL), но идея была попутно показать возможности поиска.

[transkontrol]

Эх, "у попа была собака...."

Вы твёрдо уверены, что имеет место поисковый запрос, но не требование конкретного документа?

getDocumentListEntry (line 119)
...
* mixed $location: The location for the entry, as a URL or Query

(см. http://framework.zend.com/apidoc/core/Zend...umentListEntry). В примере в статье создается именно запрос, как можно видеть по строке

Код: Выделить всё

$query = new Zend_Gdata_Docs_Query();

И как утверждается в справочном руководстве разработчика по GData, Query - это поисковый запрос (http://code.google.com/intl/ru/apis/gdata/docs/2.0/reference.html#Queries), для обращения к конкретному объекту у него есть уникальные URL. Поэтому таки да, я уверен, что мы делаем запрос (который, по идее, должен вернуть ровно один объект, но может также не вернуть ничего или вернуть несколько записей, благо Google Docs не требует, чтобы title у всех объектов был разный). Если бы мы хотели получить конкретный документ, мы бы сделали вызов $mydocuments->getDocumentListEntry(URL), но идея была попутно показать возможности поиска.

Отлично! Однако, в этом же коде :
1) есть

Код: Выделить всё

$query->setTitleExact(true);

2) нет обработки остальных найденных документов

стало быть ждём один-единственный конкретный документ.

Пойду пока посмотрю, про уникальность имени. Был уверен, что уникальное...

[Val]

Отлично! Однако, в этом же коде :
1) есть

Код: Выделить всё

$query->setTitleExact(true);

И что? Я хочу получить документ с именем "test.txt", а не "bigtest.txt".

2) нет обработки остальных найденных документов

Читайте выше - я и не предполагаю, что их будет несколько (подозреваю, что в этом случае будет получено исключение).

стало быть ждём один-единственный конкретный документ.

Нет. Почувствуйте разницу между "не более одного" и "один-единственный". Я готов получить ноль документов (в этой программе сие было бы странно, но в принципе - почему нет? Искать-то можно далеко не только по имени, но и по другим параметрам). Обработка "ноль или один документ" в коде есть.

Пойду пока посмотрю, про уникальность имени. Был уверен, что уникальное...

Мне помнится, мы их по ошибке создавали, но еще раз - идейно это ничего не меняет. А вопрос о том, что будет, если запрос вернет более одного документа, надо задать тому, кто решил принимать запрос в качестве аргумента функции, возвращающей (по его задумке) ровно одно значение.

[transkontrol]

Отлично! Однако, в этом же коде :
1) есть

Код: Выделить всё

$query->setTitleExact(true);

И что? Я хочу получить документ с именем "test.txt", а не "bigtest.txt".

2) нет обработки остальных найденных документов

Читайте выше - я и не предполагаю, что их будет несколько (подозреваю, что в этом случае будет получено исключение).

стало быть ждём один-единственный конкретный документ.

Нет. Почувствуйте разницу между "не более одного" и "один-единственный". Я готов получить ноль документов (в этой программе сие было бы странно, но в принципе - почему нет? Искать-то можно далеко не только по имени, но и по другим параметрам). Обработка "ноль или один документ" в коде есть.

Пойду пока посмотрю, про уникальность имени. Был уверен, что уникальное...

Мне помнится, мы их по ошибке создавали, но еще раз - идейно это ничего не меняет. А вопрос о том, что будет, если запрос вернет более одного документа, надо задать тому, кто решил принимать запрос в качестве аргумента функции, возвращающей (по его задумке) ровно одно значение.

Про уникальность имени требования не нашёл. Что в общем-то логично, если учесть возникшее дублирование документов и рассматриваемую задачу удаления. Признаю, мой "косяк". Значит этот вопрос с моей стороны отпадает.

Честно говоря, я не совсем понимаю вашу логику. Если мы ищем "не более одного", значит ищем __конкретный__ документ. И при отсутствии __этого__ документа сам собой напрашивается выброс исключения. К сожалению, сейчас не могу поставить зендГдата, сижу на жпрс-е (тоже ужос =) форумные странички по полчаса грузятся), скачать проблемно. (жаль, на диске нет) Дней через десять постараюсь поставить и посмотреть поиск и проверку документов.

Ладно, примем условием задачи, что возвращается всегда один документ либо выбрасывается исключение. Для чего нужно преобразования со "специальной логической переменной"?

[Val]

Честно говоря, я не совсем понимаю вашу логику. Если мы ищем "не более одного", значит ищем __конкретный__ документ.

Почти что да, но, как говорят в старом одесском анекдоте, есть один нюанс. Мы именно ищем. Представьте, что Вы пошли в лес по грибы, благо, сезон как раз тот. Будет ли исключительной ситуацией то, что грибов в лесу не оказалось? Нет, это не самый приятный, но допустимый исход. Однако на ситуацию можно смотреть с другой стороны: Вы ищете сотовый телефон у себя в кармане. Испугает ли Вас его отсутствие (при условии что, как Вы точно знаете, с утра Вы его с собой брали). Скорее всего, да. В этом и вся разница.

Применительно к GData, все еще проще: я могу запросить документ по URL: http://spreadsheets.google.com/ccc?key=tJN...CgHjBp5HlAewkgA (это таблица с секретными планами LXF на сентябрьский номер), а могу поискать по имени: "LXF122.workflow". Первое идентифицирует объект абсолютно точно, и если такого объекта нет, значит, что-то не так. Второе является лишь указанием на то, какой объект объект я хотел бы видеть - есть ли он, и сколько таких документов в принципе есть, никто заранее не знает.

Ладно, примем условием задачи, что возвращается всегда один документ либо выбрасывается исключение. Для чего нужно преобразования со "специальной логической переменной"?

Это просто нагляднее. В коде без переменной не сразу видно, где может выбрасываться исключение - например, это может быть и метод delete(). Но я не вижу проблем в том, чтобы разместить и Ваш вариант кода: "There is more than one way to do that" (жаль, что для Perl не сделали реализацию API GData, и приходится работать с AtomPub напрямую).

[transkontrol]

Честно говоря, я не совсем понимаю вашу логику. Если мы ищем "не более одного", значит ищем __конкретный__ документ.

Почти что да, но, как говорят в старом одесском анекдоте, есть один нюанс.

А вы пошляк! Однако, не скучный собеседник. =)

Мы именно ищем. Представьте, что Вы пошли в лес по грибы, благо, сезон как раз тот. Будет ли исключительной ситуацией то, что грибов в лесу не оказалось? Нет, это не самый приятный, но допустимый исход. Однако на ситуацию можно смотреть с другой стороны: Вы ищете сотовый телефон у себя в кармане. Испугает ли Вас его отсутствие (при условии что, как Вы точно знаете, с утра Вы его с собой брали). Скорее всего, да. В этом и вся разница.

Применительно к GData, все еще проще: я могу запросить документ по URL: http://spreadsheets.google.com/ccc?key=tJN...CgHjBp5HlAewkgA (это таблица с секретными планами LXF на сентябрьский номер), а могу поискать по имени: "LXF122.workflow". Первое идентифицирует объект абсолютно точно, и если такого объекта нет, значит, что-то не так. Второе является лишь указанием на то, какой объект объект я хотел бы видеть - есть ли он, и сколько таких документов в принципе есть, никто заранее не знает.

С грибами исключительной ситуацией будет, если я не найду тот единственный и неповторимый, за которым и отправился. Я же иду за грибом, а не с проверкой есть он там или же его там нет. Если же я иду просто за _сколько_нибудь_куча_грибов_, то в полученном множестве, конечно же, может быть пусто. Множество-то, я получу.

Ну, и с остальными примерами тоже самое. Я понял вашу мысль. И даже признал, что в данном случае об уникальности речи не идёт. Скорее здесь несовпадение задачи и используемого инструмента. Про целесообразность выбора инструмента ничего сказать не могу, так как ещё не смотрел на сам ЗендГдата.

Ладно, примем условием задачи, что возвращается всегда один документ либо выбрасывается исключение. Для чего нужно преобразования со "специальной логической переменной"?

Это просто нагляднее.

Ну вот этого я уже, наверное, никогда не смогу понять...

В коде без переменной не сразу видно, где может выбрасываться исключение - например, это может быть и метод delete(). Но я не вижу проблем в том, чтобы разместить и Ваш вариант кода: "There is more than one way to do that" (жаль, что для Perl не сделали реализацию API GData, и приходится работать с AtomPub напрямую).

А в коде без переменной и не надо знать __откуда__ вылетело исключение. А вот __что__ именно случилось - будет видно.

PS Дальнейшее, наверное, уже будет холивар?

[Val]

С грибами исключительной ситуацией будет, если я не найду тот единственный и неповторимый, за которым и отправился.

"Неурожай, - подумал Штирлиц, - и сел в сугроб"? Я с той целью и привел грибы, что их число и прочие характеристики заранее неизвестны, ну да ладно - раз мысль понятна, в пример можно не вникать.

Скорее здесь несовпадение задачи и используемого инструмента. Про целесообразность выбора инструмента ничего сказать не могу, так как ещё не смотрел на сам ЗендГдата.

Не удивлюсь, если отыщутся и другие способы. В целом, с инструментом все в порядке: Вы просто придаете слишком большую роль одному-единственному примечанию.

А в коде без переменной и не надо знать __откуда__ вылетело исключение. А вот __что__ именно случилось - будет видно.

Это видно и вообще без всякой обработки (если PHP пощекотать, чтобы текст ошибок выводил) - интерпретатор их отлавливает на самом высоком уровне. Но еще раз: можно было написать так, как сделали Вы - просто автор предпочел другой вариант. В этом нет ничего противозаконного

PS Дальнейшее, наверное, уже будет холивар?

Со мной холиваров как-то не получается...

[transkontrol]

Скорее здесь несовпадение задачи и используемого инструмента. Про целесообразность выбора инструмента ничего сказать не могу, так как ещё не смотрел на сам ЗендГдата.

Не удивлюсь, если отыщутся и другие способы. В целом, с инструментом все в порядке: Вы просто придаете слишком большую роль одному-единственному примечанию.

А в коде без переменной и не надо знать __откуда__ вылетело исключение. А вот __что__ именно случилось - будет видно.

Это видно и вообще без всякой обработки (если PHP пощекотать, чтобы текст ошибок выводил) - интерпретатор их отлавливает на самом высоком уровне. Но еще раз: можно было написать так, как сделали Вы - просто автор предпочел другой вариант. В этом нет ничего противозаконного

Здесь имеется ввиду, будет видно во время выполнения сценария. И без всякого щекотания. То есть можно будет реагировать соответственно уже во время выполнения, а не постфактум читать логи. В данном случае, например, при выбросе исключения ПипецСязьОтвалилась() и не стоит пытаться закачать новый документ, а вывести на моду "ой, гугл потерялся". При выбросе ПипецУчётнойЗаписиНет(), вывести "Жаль, но вас уже удалили, вместе со всеми вашими документами." Если же прилетит ПипецЭтогоДокуметаНет(), - махнём рукой и начнём закачку нового документа. Хотя чего это я, основы излагать взялся...

И, да, я очень негативно отношусь к тому, что прибивают информативное исключение и вместо этого создают лишнюю переменную. Из-за того, что потом люди не понимают, почему не стоит делать такие обёртки, а наоборот стараются к каждому методу (функции) выбрасывающему исключения приклеить обёртку с возвратом false. А на разъяснения следует "я пишу хороший код - он не выбрасывает исключения". Статья-то "курс молодого бойца", соответственно, рассчитана в первую очередь на новичков. И приведённый вами код - это для них (как и для всех в начале пути) не просто пример для подражания, а истинная истина. И многие потом так и остаются и обёртками...

PS Кстати, вы говорите и "Автор выбрал", и "мы ... создавали". Вы - тоже автор?

[Val]

Здесь имеется ввиду, будет видно во время выполнения сценария. И без всякого щекотания. То есть можно будет реагировать соответственно уже во время выполнения, а не постфактум читать логи. В данном случае, например, при выбросе исключения ПипецСязьОтвалилась() и не стоит пытаться закачать новый документ, а вывести на моду "ой, гугл потерялся". При выбросе ПипецУчётнойЗаписиНет(), вывести "Жаль, но вас уже удалили, вместе со всеми вашими документами." Если же прилетит ПипецЭтогоДокуметаНет(), - махнём рукой и начнём закачку нового документа. Хотя чего это я, основы излагать взялся...

Все верно, так тоже можно. И идейно это даже правильнее, чем перехватывать все исключения, что делает и журнальный, и ваш код. Ведь тому, что GetDocumentListEntry() не вернул нужный документ, могло быть десятки причин. Увы, полноценной обработкой ошибок в журнальных примерах зачастую приходится жертвовать в угоду читаемости и компактности.

И, да, я очень негативно отношусь к тому, что прибивают информативное исключение и вместо этого создают лишнюю переменную. Из-за того, что потом люди не понимают, почему не стоит делать такие обёртки, а наоборот стараются к каждому методу (функции) выбрасывающему исключения приклеить обёртку с возвратом false. А на разъяснения следует "я пишу хороший код - он не выбрасывает исключения". Статья-то "курс молодого бойца", соответственно, рассчитана в первую очередь на новичков. И приведённый вами код - это для них (как и для всех в начале пути) не просто пример для подражания, а истинная истина. И многие потом так и остаются и обёртками...

Стоп, где обертки? Ваш и наш код эквивалентны друг другу, а также такому:

Код: Выделить всё

try {
  $doc = $mydocuments->getDocumentListEntry($query);
  $exception_caught = FALSE;
}
catch (Exception $e) {
  $exception_caught = TRUE;
}

if ($exception_caught) {
  // Something
}

Это, разумеется, не самый оптимальный вариант, но синтаксически он полностью эквивалентен такому:

Код: Выделить всё

try {
  $doc = $mydocuments->getDocumentListEntry($query);
}
catch (Exception $e) {
   // Something
}

и никаких оберток, которых Вы так боитесь, здесь не используется: никто не пытается упихать в объект $doc значение FALSE и скрыть таким образом исключение.

Если уж на то пошло, то и в обертках особой крамолы нет, иногда они могут быть полезны. Классический пример: функция, возвращающая число из массива или 0, если индекс находится вне допустимых границ. Конструкция (псевдокод)

Код: Выделить всё

try {
  r = array[i];
}
catch (IndexOutOfBoundsException e) {
  r = 0;
}

так и напрашивается на рефакторинг в отдельную функцию или метод.

PS Кстати, вы говорите и "Автор выбрал", и "мы ... создавали". Вы - тоже автор?

Как редактор, я в той или иной степени участвую в создании абсолютно всех материалов журнала. Где-то больше, где-то меньше... В данном случае мне повезло - этот код (и пояснения к нему) написал лично я, чтобы занять место на полосе. В кои-то веки можно не додумывать, чего хотел автор, а писать, как есть

[transkontrol]

Стоп, где обертки?

Обёртки - это про ситуацию из здесь: Июль 2009

Если уж на то пошло, то и в обертках особой крамолы нет, иногда они могут быть полезны. Классический пример: функция, возвращающая число из массива или 0, если индекс находится вне допустимых границ. Конструкция (псевдокод)

Код: Выделить всё

try {
  r = array[i];
}
catch (IndexOutOfBoundsException e) {
  r = 0;
}

так и напрашивается на рефакторинг в отдельную функцию или метод.

А это не та обёртка, которая имеется ввиду.
Во-первых, здесь возвращается "объект" затребованного "типа": 0 - тоже число.
Во-вторых, перехватывается/обрабатывается конкретное исключение: исключение ВообщеНетМассива() улетит куда надо.

PS Кстати, вы говорите и "Автор выбрал", и "мы ... создавали". Вы - тоже автор?

Как редактор, я в той или иной степени участвую в создании абсолютно всех материалов журнала. Где-то больше, где-то меньше... В данном случае мне повезло - этот код (и пояснения к нему) написал лично я, чтобы занять место на полосе. В кои-то веки можно не додумывать, чего хотел автор, а писать, как есть

Радует, что информация из первых рук!

[Val]

Обёртки - это про ситуацию из здесь: Июль 2009

Я понимаю. Так к статье это имеет мало отношения?

[transkontrol]

Не угадал я со сроками, прошу извинить.

Обёртки - это про ситуацию из здесь: Июль 2009

Я понимаю. Так к статье это имеет мало отношения?

К стаье - мало, к _тому_самому_ куску кода - непостредственное. Это пример для многих. И такие примеры развиваются в функции-обёртки. Кроме того, плодится лишняя сущность.


Ну, и возвращаясь к напечатанному. Всё-таки, имеет мосто требование единственного документа: Июль 2009

Код: Выделить всё

getDocumentListEntry (line 119)

Retreive entry object representing a single document.

    * access: public

Zend_Gdata_Docs_DocumentListEntry getDocumentListEntry ([mixed $location = null])

    * mixed $location: The location for the entry, as a URL or Query

Правда методом выше (ДайДокумент) возвращаемым значением стоит void, но это просто в описании метода не указано @return.

[Val]

Ну, и возвращаясь к напечатанному. Всё-таки, имеет мосто требование единственного документа:

Имеет место запрос (что отмечено в документации). И, я думаю, не имеет смысла начинать все сначала: все равно вы останетесь при своем мнении, а я - при своем. Если Вам кажется естественным подобное API - прекрасно, значит, у Zend оно не плохое, а просто создано не для меня