Такие комментарии меня радуют. Значит, не зря статью опубликовал.
Учитывая, что он был придуман в 95-ом, сложно сказать, какие работы новые, а какие — уже нет. Но, например, абсолютно все статьи, указанные в списке литературы, можно найти в интернете. Можно начинать сразу с [3].
Естественно, муравьи используют и непосредственный обмен информацией, а не только стигмергию. Усиками они «обнюхивают» друг друга, насчет жестов — не знаю.
> Если честно, со Scheme я знаком исключительно по статье в википедии
В таком случае, не делайте поспешных выводов насчет операторов-функций и префиксной записи.
Я с Вами полностью согласен. Я, пожалуй, не совсем правильно выразился.
Я говорю о том, что если уж есть метод «instance.IsNullOrEmpty()», то ждать от него NullReferenceException довольно странно. Представьте, что Вы вызываете number.IsZero(), а он возвращает ZeroArgumentException.
Писать такой метод неправильно (именно в данном контексте, хотя тут все делают вид, что это какой-то неписаный закон ООП) — но это другой вопрос.
Мое мнение заключается вот в чем: абсолютно логично, когда метод с названием IsNull...() возвращает true у null. И абсолютно нелогично, если метод с таким названием не может обработать null. Если он так делает, он не может так называться. И неважно, как этот метод реализован (очевидно, что как extension, но дело не в этом).
Вы рассматриваете программиста, который вообще не знает об extension-методах, но при этом догадывается, что у экземпляра не написать проверку на null и не поверит названию? Это очень странный .NET-разработчик, по-моему.
Черт, я все перепутал. .Count() же выкинет исключение. Вы меня извините, в общем, но я беру свои слова назад. В этом вопросе я с Вами тоже не согласен :)
Советую капитанам-комментаторам и минусующим перечитать внимательно комментарий. || тут не при чем, вопрос в том, что [null].Count() не выкидывает NullReferenceException, а возвращает ноль. Тут я согласен, неочевидное поведение.
Не совсем понял Ваш комментарий. Т.е. это совсем не странно, что метод IsNull..() в случае null не возвращает true, а выкидывает исключение?
Вы хотите сказать, что написать такой метод для экземпляра невозможно? Естественно. Но при чем тут IsNullOrEmpty()?
Не совсем так, исправил в тексте. Большое спасибо.
Учитывая, что он был придуман в 95-ом, сложно сказать, какие работы новые, а какие — уже нет. Но, например, абсолютно все статьи, указанные в списке литературы, можно найти в интернете. Можно начинать сразу с [3].
Муравьиные алгоритмы и так не сваливаются в субоптимальные решения. Тому, как увеличить при этом эффективность, посвящена третья часть статьи.
Обеспечить высокую скорость сходимости, не застревая в локальных оптимумах — это проблема любых алгоритмов оптимизации, вообще говоря.
С каких пор?
> Легкоподдерживаемый код это простой код.
То есть рекурсию использовать нельзя, по-Вашему?
В таком случае, не делайте поспешных выводов насчет операторов-функций и префиксной записи.
Блестяще.
Что Вы имеете в виду? ООП?
> вызывается процедура объекта
Объекту посылается сообщение.
> В данном случае, объект не существует
В данном случае, объект — это null.
Я говорю о том, что если уж есть метод «instance.IsNullOrEmpty()», то ждать от него NullReferenceException довольно странно. Представьте, что Вы вызываете number.IsZero(), а он возвращает ZeroArgumentException.
Писать такой метод неправильно (именно в данном контексте, хотя тут все делают вид, что это какой-то неписаный закон ООП) — но это другой вопрос.
Думаю, дальше спорить бессмысленно.
Вы рассматриваете программиста, который вообще не знает об extension-методах, но при этом догадывается, что у экземпляра не написать проверку на null и не поверит названию? Это очень странный .NET-разработчик, по-моему.
Вы хотите сказать, что написать такой метод для экземпляра невозможно? Естественно. Но при чем тут IsNullOrEmpty()?