дык Удобнее, чем просто написать: Код (Text): метод(параметр1, параметр2){ делай раз } метод(параметр1, параметр2, параметр3){ делай два } ? При том, что параметры отличаются не просто количеством и названиями, но и типами и назначением. Если же все упирается только в количество параметров, то тогда можно юзать параметры по умолчанию, да. Но перегрузка-то в пыхе все равно дурацкая.
ммм вы можете всегда написать вот так: Код (Text): метод(параметр1, параметр2, параметр3 = null){ if (параметр3) { делай раз } else { делай два } } вы считаете что это жуть-жуть? =) более того т.к. нет типов, вы можете задать один метод для обработки и числа и массива чисел, и внутри сделать что-то типа: Код (Text): метод(параметр){ if (is_array(параметр)) { делай раз } else { делай два } }
Дык: НО, это не рулит, когда: Еств могу, а что остается? Другое дело в том, что в других языках это делается изящнее. И да, ремарка: Нет, это не жуть-жуть. Этот механизм называется "параметры по умолчанию". Речь же шла о перегруженных методах. Перегрузка и параметры по умолчанию - это инструменты, решающие разные задачи. Параметры по умолчанию исторически появились в языках программирования после появления перегрузки, дабы решить проблему дублирования кода в перегруженных методах, где вся логика идентична на 99%, за исключением использования дополнительных параметров. Перегрузка же решает проблему, состоящую в использовании одноименных методов с разной логикой, оперирующей уникальным набором параметров для каждой реализации. И ВОТ ЭТО уже жуть жуть.
Я вас не понимаю, мистер. просто проверяете параметр на его тип и решаете что делать дальше. Добавлено спустя 2 минуты 47 секунд: изящность тут не при чем. изящности классической конструкции перегрузок позавидовала бы разве что корова. Это вынужденная мера в языках со строгой типизацией. В пхп же у вас одна точка входа и вы можете принимать любые решения основываясь на типах параметров и любых их комбинаций. Наверное поэтому неглупые люди не стали изобретать ненужный велосипед, чтобы потрафить нежеланию системщиков осмысмыслять концепции некомпилируемого языков. ты ж со мной согласен? =)
Увы, это было ожидаемо. Есть еще такое дело, как семантика: Код (Text): get_rows(int[] ids){} get_rows(string column_name){} get_rows(data $modif_time){} Вот примерно такой набор методов я и имел ввиду. Любая IDE же покажет всего лишь один метод с возможностью выбора нужного набора параметров. В том вся и соль, что я не хочу принимать решение о передаче управления в какую-то часть метода, если это за меня может сделать сам исполняемый процесс. Точно так же берет единую точку входа, сам проверяет что к чему и передает управление конкретной реализации метода. Такой код правильно структурирован, его очень легко сопровождать. Каждая реализация метода имеет возможность самостоятельного развития, включая наборы параметров. Плюс ко всему, это называется "автодокументация". При виде вышеописанного набора методов, сразу можно понять, что и как они делают и что просят. Несколько нагляднее, чем Код (Text): get_rows($param){} , для использования которой надо лезть в доки и искать список всех вариантов $param, плюс возвращаемые значения для каждого из них. А теперь представим случай, где у каждого метода разный набор параметров и по количеству... Вы ноги сломаете об это. И решением станет: Код (Text): get_rows_by_ID($ids){} get_rows_by_column_etc($column_name,$etc){} get_rows_by_time_etc($odif_time,$etc,$etc1){} Три метода, делающие одно и то же по сути. Вынужденная чем? Нет, потому что велосипед они-таки изобрели. Только одно колесо квадратное, другое треугольное, а вместо сидения - костыль заточенный. - http://php.ru/manual/language.oop5.overloading.html З.Ы. Это не затравка к холивару насчет видов типизации. Это просто к тому, что вот конкретно перегрузка в PHP, как элемент ООП, сделана, пока что, просто сказочно. Авось исправят.
Вы просто не хотите понять новую концепцию. Я понимаю и принимаю обе. Я понимаю почему и где какая. А вы просто не можете принять новое. Меня всегда интересовал вопрос, когда развитие человека останавливается и почему. Почему когда-то вы принимали любые новые и интересные концепции, а сейчас говорите, что какая-то "правильная" а другая - нет. При том что я вам описал почему и как обстоят дела, какие это дает преимущества, и почему именно так оно устроено в пхп. При этом при всем вы слепо отвергаете всю аргументацию и говорите "я не хочу" что является признаком нежелания раздумывать. Ну... дело ваше. Добавлено спустя 4 минуты 18 секунд: вам надо маляш осмыслить в чем фишка скриптовых языков. я отквотил, а вы через годик приходите, почитаете, удивитесь, как ваше взгляды изменятся.
Это - http://php.ru/manual/language.oop5.overloading.html - не новая концепция Это кривая попытка костыльной адаптации уже устоявшихся стандартов. Я не пустословил же в предыдущем посте. Я привел аргументы, привел конкретный пример использования, привел юзкейс. Дело не в концепции, а в том, что вы, вероятно, все же не до конца понимаете, что я описывал, равно как и то, что на данный момент задача, для которой используется классический механизм перегрузок, физически не решаема на PHP без роста лишней сопровождающей документации и вброса новых имен методов в неймспейс. Ды я точно так же пользуюсь теми же костылями, что и вы приводили в пример Я не говорю "не хочу", я говорю "хочу по-человечески". Без свитчей и ифов, проверяющих тип/значение входящих параметров, дабы передать управление какой-то части метода. Исключение, конечно, это использование методов с параметрами по умолчанию. Там да, это все нужно и к месту. Сама перегрузка как раз и была создана как новая концепция решения подобных задач, заодно расширяющая возможности разработчика Просто ООП в PHP еще молодо. Но все встанет на свое место со временем. Добавлено спустя 1 минуту 32 секунды: Вся соль в том, что то, что я описываю, прекрасно можно реализовать на PHP, при том, что он является скриптовым языком. Но пока что не реализовали.
это НЕ НУЖНО реализовывать =) вы просто не хотите принять иную концепцию, кроме известной. в скриптовых языках то что вы говорите делается проще. Просто вы привыкли к другому.
Согласен. Куча лишнего кода, проверок, это разве называется проще? О том и речь, что все эти проверки на типы входных данных можно было бы сделать в ядре. Концепция простая - абы как сделали, чтобы хоть что-то было. Добавлено спустя 43 секунды: Может, тема нужна специальная: перезагрузка методов в PHP и в других языках?
Срач это хорошо только кроме меня никто иную точку зрения не поддерживает, а мне лень вообще иметь хоть какую-то точку зрения по данному вопросу. =) вот че меня реально ЕБЕТ так это отсутствие ассоциативных массивов в js и конкатенатора тоже.
Строки в JS конкатенируются через "+". Конструкция += также справедлива. ЧТо не так? Добавлено спустя 1 минуту 32 секунды: О_о и давно они там отсутствуют?
... там даже массивов нет А ассоциативные массивы в JS - это объекты, элементы которого можно перебрать с помощью for in
Бритва Оккама намекает, что для языка, не имеющего прямого доступа к памяти машины, этого более чем достаточно
1 + 1 = 11 в js суровая реальность - раз два, объекты это не массивы, свойства не сортируются со всеми вытекающими.
Открываем консоль браузера, вбиваем Код (Text): alert(1+1); , удивляемся чуду. Все же (1+1); и ("1"+"1"); - несколько разные вещи, верно? Эммм.... http://javascript.ru/Array/sort или вот тут, поподробнее http://www.internet-technologies.ru/articles/article_1383.html
ну если умничать не будешь, то можем обсудить когда и что не так в js =) верно? ибо если тебе не интересно, то какой смысл? олимпиада не для меня.
Сорь, если обидел, и в мыслях не было. Но 1+1 все же 2 получилось? Если же хочется складывать строки как числа, то есть же в JS приведение типов. А то так же можно начать ругаться на PHP, что там при попытке через точку "." обратиться к свойству объекта, какая-то хрень случается. Просто на JS писать как на JS, а на PHP как на PHP.
в js нет типов как в пхп но в пхп + это математическое сложение и неебет а точка - сложение строк. потому что php заточен под http user input, а он всегда текст. даже если число. в js может в переменной быть число которое не число, и его надо парсить, ибо иначе может случиться вышеописанная ситуация. Добавлено спустя 1 минуту 39 секунд: просто в пхп это один символ на две переменных, а в js не один =) ну с этим можно жить. а вот без сортировки ассоциативных массивов как-то совсем не весело.
Ситуация такая, есть setter, getter. Логика. Обычно так всегда. Главный объект состоящий из команд, которые вызывают указанные за ранее действия "скрипт-код", тем самым приводить все к одному объекту для вызова. Удобно. Можно назвать как 'Listener::get('param'[, mixed $...]) а в новых версиях php можно и еще намудрить с Listener::get('param'[, mixed $...])[]", проектирование программы будет в главной роли. (в этом выражении может быть любой тип и вернуть может, что захочем и укажем) Когда пишут без проектирования сразу видно. (есть такие кто мысленно без записей, умно), сразу видно знает. Но так, чтобы просто набросать все горазды. =)
Я написал не так, почитайте вообще, для чего создавать методы и переменные. Вы считаете, что если писать много методов, переменных, классов, объектов и т. д.,-это будет нормально? Говорит человек который занимается программированием. Строгость типа есть только определением класса или array. Другой строгости нет. По этому я повторяю, нет необходимости лепить много пользовательских методов, когда есть команды вызова, скрипта из одного метода. Навигация по реализации получится.
Лучше, чем 500-строчные методы-простыни, разделенные внутри кейсами и брейками. Автокаст переменных не значит, что в момент времени они не имеют тип. Типы переменных в PHP есть. И функции для проверки типов тоже есть. Другое дело, что там, где в том же C# я буду писать a = b.toString(); , в PHP я напишу $a=$b, а дальше она сама в строку конвертнется, если я попробую оперировать с ней как со строкой. Это не значит, что типов нет. Это значит, что они приводятся автоматически.
ну тебе всё равно придется описать вызовы этих методов и передачу в них параметров внутри твоего метода. =) так зачем это и не проще ли сразу это описать в свиче.