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

пример?

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

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

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

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

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

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

Жаль :(

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

Теперь у меня функции оформляются так:




или так




Так как каждый параметр имеет тип, во втором случае можно контролировать и типы, хотя учитывая coerce в Moose это тоже не очень надёжно. Но в большинстве случаев работает.

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

баги перла ? ну - ну =)

баги перла ? ну - ну =)

Ну да=)

Вобще мне концепция и многие фитчи Perl очень нравятся, но когда попробовал написать на нем программу для практической задачи, сразу наткнулся на множество непоняток. Для начала в поворачивать картинки на дробный угол GD отказывается http://forum.vingrad.ru/forum/topic-265977.html, причем аналогичная библиотека PHP делает это спокойно. Ладно, берем ImageMagick. Так он отказывается читать файлы  с путями, в которых есть русские буквы. Пришлось открывать файл через open и дескриптор ему уже передавать. Прототипы опять же эти для анонимных функций, вроде они есть, но оказывается не работают. Когда же интерпретатор стал вылетать на одной строке без каких бы то нибыло сообщений об ошибке, мое терпение лопнуло.


Вобщем язык сыроват.

пошел плакать

Кстате, любопытно что прототип через функцию prototype он видит

Logo, ничего любопытного.. Прототип скорее всего хранится вместе с самой функцией (дерево PP - кодов), а функция prototype обращается к нему..



Не хочу вас переубеждать - дело ваше. Учтите, что перл - это первый язык в своем классе. Python, PHP, Ruby, Lua (?) появились позже, и учитывали опыт перл. Поэтому: 
а) перле много унаследованного, что не могут выкинуть из соображений совместимости
б) перл СТАБИЛЕН. Те баги которые вы привели - это баги не перла, а библиотек.. ну что поделаешь - есть хорошие, а есть и плохие. Это скорее минус перла..
в) В перле (таков уж стиль авторов) мног вещей которые сделаны на будущее. Т.е. то на что компилятор не ругается, но что пока не имеет эффекта. Это НЕ баги. Такие фичи (как и прототипы анонимок) либо не указывают в документации, либо пишут, что это на будущее.

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

Согласен, разве что за исключением пункта в).

Добавлено через 3 минуты и 35 секунд
Но все равно обидно, что вот по крайней мере обработка изображений так глючит. Идеального инструмента не существует выходит. Ждем перл 6. А пока перл буду попробовать применять в других вещах, когда будет потребность.

bingo!

И чем дольше работаешь - тем больше понимаешь, что это общее свойство всего..