Цепочки объектов.

[Crazy]

Автор оригинала: zerkms
из этого следует, что ты соглашаешься что классы удобнее функций?

Странный вопрос. Что вкуснее -- арбуз или свиной хрящик? Классы не могут быть априори удобнее функций. И наоборот.

если да, то к чему ты вообще затеял этот спор?

Я? Ты меня определенно с кем-то путаешь. Я поспел к этому спору к середине, отвечая на вполне конкретный твой вопрос.

Ответ, кстати, понятен?

 

[dark-demon]

trigger_error по определению не сможет предоставить столько же информации, сколько и эксепшн

например?

как связан синглтон и класс? как можно сравнивать по определению разные термины? или я отстал от жизни?

а как связаны классы с ООП?

класс - это ещё и предки

то есть, класс без предков - уже и не класс?

и свойства.

у функций тоже есть свойства. правда только приватные...

 

[zerkms]

например?

эксепшн возвращает причины ошибки, раписанные подробно, ибо текст эксепшна писал программист

а как связаны классы с ООП?

ты на мой вопрос не ответил таки...

то есть, класс без предков - уже и не класс?

ещё и == в том числе и

у функций тоже есть свойства. правда только приватные...

можно ли статические переменные называть свойствами?

Crazy
неа, не понятен - особенно эта вот часть

про проектировании диаграммы классов здоровые головой люди назначают синглетону стереотип "Singleton". Если человек пририсовывает ему метод getInstance -- это уже что-то с головой. Или учили не тому и не там.

 

[StUV]

вот блин куда заехало... - при чем тут вообще сравнение методов, классов и функций? - мы кажется говорили о механизме exception's вообще
мне например иногда гораздо удобнее сделать что-то вроде:
try
{
...
throw true;
...
throw false;
}
catch(bool b)
{
...
}
чем
...
return (...) ? true : false;
...

=)))

 

[Crazy]

Автор оригинала: zerkms
неа, не понятен - особенно эта вот часть

Ok, "продолжаем разговор" (c) Карслон-который-живет-на-крыше

Уточним, что именно непонятно:

1. Почему при проектировании синглетону назначается стереотип Singleton?
2. Почему не добавляется метод getInstance?
3. Чем проектирование отличается от кодирования?

 

[dark-demon]

эксепшн возвращает причины ошибки, раписанные подробно, ибо текст эксепшна писал программист

а trigger_error видимо где-то теряет этот текст?

можно ли статические переменные называть свойствами?

а почему нет?

ты на мой вопрос не ответил таки...

значит мы квиты функция со статическими переменными принципиально равносильна классу-синглетону с одним методом и приватными полями.

 

[Crazy]

Автор оригинала: StUV
мне например иногда гораздо удобнее сделать что-то вроде:

В твоем коде (который я поскипал) throw true и throw false действительно стоят в местах, где возникает нештатная ситуация?

 

[dark-demon]

return (...) ? true : false;

этапять! =^_^=

 

[StUV]

dark-demon
просто ты не пробовал
механизм exception'ов в крупных оо-системах гораздо более гибок и расширяем
если ты кодишь процедурно скрипты на 100 строк - зачем ты вообще завел этот спор ?
- ради "прикольно пофлеймить" ? или "приятно быть клоуном" ? =)))

 

[Crazy]

Автор оригинала: dark-demon
этапять! =^_^=

Тебе смешно, а я в Java-коде senior programmer'а встретил вот такой код, да простят меня за оффтопик:

return (true == someVariable) ? false : true;

На вопрос "а зачем так?" был получен парадоксальный ответ (цитирую): "если поставить true справа то случайно может произойти присваивание".

 

[StUV]

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

 

[dark-demon]

goto ещё более гибок

 

[Crazy]

Автор оригинала: StUV
механизм exception'ов в крупных оо-системах гораздо более гибок и расширяем

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

-~{}~ 25.05.07 14:33:

Автор оригинала: dark-demon
goto ещё более гибок

Увы, менее. В современных языках его применение очень ограничено.

 

[StUV]

этапять! =^_^=

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

 

[Crazy]

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

Я, собственно, спросил потому, что имеется практика неправильного применения исключений. Пример такого неправильного использования (sorry -- на вражеском языке):

int getZeroIndex(int[] data) {
  int i = -1;
  try {
    while (true) {
      if (data[++i] == 0) {
        return i;
      }
    }
  } catch (Throwable t) {
  }
  return -1;
}

 

[dark-demon]

StUV, и что не так у пхп с приведением типов?

 

[StUV]

Crazy
хм
у меня есть собственный пример неправильного использования - фактически подмена условного перехода:
http://phpclub.ru/talk/showthread.php?s=&threadid=90032

есть еще несколько подобных решений... плохо это или хорошо - пока не определился
но мне удобно (не нужно дополнительных строк на логирование/итп... - "где-то" "оно" уже все есть =)))

-~{}~ 25.05.07 14:46:

dark-demon
к сожалению, в большом коллективе всегда найдется пара кодеров, не очень хорошо разбирающихся "во всех ньюансах" приведения типов и могут вкоммитить какую-нить хрень, которую потом фик отловишь.... - вот для них как правило такой код и пишут

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

 

[Crazy]

Автор оригинала: StUV
у меня есть собственный пример неправильного использования - фактически подмена условного перехода

Так писать можно. Проблема в том, что у многих при этом используется ловля "исключений вообще". В результате порождается код, плохо реагирующий на изменения.

 

[StUV]

а по поводу
catch(...)
{
}
- имхо, чаще всего это заплатка-запарки-в-день-релиза... - за это руки отрывать надо

-~{}~ 25.05.07 14:57:

хотя, каюсь, и сам грешил - но руки при мне - пронесло

 

[Crazy]

Автор оригинала: StUV
а по поводу
catch(...)
{
}
- имхо, чаще всего это заплатка-запарки-в-день-релиза... - за это руки отрывать надо

Ага. Я заставляю народ при возникновении реальной необходимости сделать пустой catch писать что-то типа такого:

} catch (...) {
  // ignore exception
}

или даже так:

} catch (...) {
  Util.doNothing();
}

Дело в том, что есть тулза, которая умеет ругаться на пустые catch'и в Java-коде. А catch с комментарием, увы, она считает пустым.