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

пример?

Вот пример. Как ни пробую, прототип анонимной функции не работает, хотя компилятором принимается.

проверка прототипов происходит во время компиляции.

А зачем тогда разрешается указывать прототипы в анонимных функциях?
Кстате так тоже не работает

прототип привязан к имени функции. Т.е. проверка и преобразование агрументов к прототипу происходит на этапе лексического анализа.. (это хак если желаете).

А для анонимных функции просто не стали запрещать, возможно в будущем реализуют.

Вообщем прототипы - довольно редко бывают необходимы.

Жаль :(

Logo, чего вам жаль ?
прототипы - это НЕ средство типизации. Перлу они не нужны (по задумке =))
прототипы полезны когда вы хотите дописать функционал на уровне близком к синтаксическому анализу..
т.е. расширить язык. 

Например, вы хотите передавать массив по ссылке, но что бы для пользователя это было красиво (как в push/pop), или хотите передавать ссылку на процедуру, но что бы пользователь писал ее просто как блок кода. Вот тут то и нужны прототипы.



См.. Error.pm


Это сообщение отредактировал(а) sir_nuf_nuf - 23.7.2009, 10:10

Вообще-то прототипы предназначены для того, чтобы передавать аргументы как в нормальных языках программирования, т.е. обязательные/необязательные параметры, функция сама знает, взять ей аргумент по ссылке или по значению.

Logo, 
 .. это наезд на perl ?   


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

Обязательные /  необязательные.. опять таки - это того нет по задумке в перле. Все - необязательные.

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


Ну да, было бы удобно и привычно написать переменную массива, а функция уже сама взяла ссылку, как в остальных языках.

Самое обидное же, что хотя прототипы  в анонимных функциях не работают, их там почему-то можно записать, что оставляет ощущение недоделанности языка.

 их надо удалить (см. Фаулер, Рефакторинг). =)



Не заблуждайтесь.. Код самой функции (как текст, так и то, во что оно скомпилируется) не зависит от прототипов самой функции.  От прототипов функции зависит код того, кто ее вызывает.



  У меня perl зачастую вызывает ощущение переделанности =)

А еще в нем можно писать так

нафиг надо - тоже не ясно..

Но без прототипов perl не скажет о том, что функция принимает параметры, которые все равно не используются.




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



Я включение возможности, которая не работает (сабж), иначе как недоработку не вижу.

Мой опыт показал, что от прототипов много проблем. Гораздо продуктивней использовать модули - валидаторы, например MooseX::Params::Validate или Params::Validate . Это менее производительно, но во многих отношениях лучше, так как происходит использование функций в более явном виде и без странных преобразований.

mvsgt, +1 - я же и говорю - прототипы не для бизнес логики, а для расширений языка.

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

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

Ну к примеру.. функция которая собирает url из частей.
можно написать так:

и тогда программер пока не выучит как ее вызывать каждый раз будет смотреть документацию.. а еще скорее - код, потому, что прототип ($$;\@$$) ничего не говорит ему. Почему это порт идет после параметров запроса ? а потому что юзается редко и что бы не писать каждый раз undef..


Можно так:

передача через хеш - запоминается быстрее. А если прогер затупил и забыл передать путь - это он узнает через die.

Если количество параметров становится громадным или его сложно описать в одной строчке - нужно создавать классы.  При таком подходе программеру будет просто неудобно использовать код неправильно.

Это сообщение отредактировал(а) sir_nuf_nuf - 27.7.2009, 11:55