рабочее

[avva]

Очередной глюк Перла.

Если обрабатывающий блок внутри таких команд циклической обработки, как grep, map итп., вызывает функцию, а эта функция каким-то образом меняет $_, это нарушает работу цикла. При этом обычное использование $_ внутри таких же grep/map или for/foreach не мешает, т.к. они локализуют $_ внутри себя, используя отдельную копию. Но в данном случае grep вызывал функцию, а она вызывала другую функцию, а та читала файл через конструкцию типа while(<>) — и это вызывало глюки в цикле grep, с которого всё началось. Потому что while(<>) не локализует $_, в отличие от for/foreach, а использует глобальную переменную.

Какого хрена стандартная контрольная конструкция в языке должна глючить отттого, что какая-то функция на несколько уровней вызовов ниже использует какую-то переменную тоже вполне стандартным способом? Где модуляризация, [censored]?

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

Сегодня я тоже Ненавижу Перл (tm).

Comments

[nice-beaver.livejournal.com]

It's a tool

[avva.livejournal.com]

Tou fucking ché.

[cema.livejournal.com]

Не люблю. Есть такое дело, да.

[ex-ilyavinar899.livejournal.com]

Switch to C#.

[squadette.livejournal.com]

у меня было ичсто интуитивное подозрение к $_ и @_ "как только я их увидел"

всегда пишу "foreach my $foo (@bar)"

[avva.livejournal.com]

Не дождётесь!

[onodera.livejournal.com]

Ну хоть на пхп (хотя только читать на нём умею ^^').
P.S.
А обзывают ли UNIX-программисты Си-шарп Си-хэшем?

[yorool-gui.livejournal.com]

Аналогично. В моих программах встретить $_ практически невозможно, если это не скрипт типа "написал, запустил и выбросил".
Честно говоря, Perl IMHO нуждается в каком-то стандартном наборе ограничений, более жестком, чем use strict. Потому что сейчас вести большие проекты на перле -- вид мазохизма.

[gaal.livejournal.com]

See also the long thread on comp.lang.perl.moderated.

[sova.livejournal.com]

What's "diagonality" as applied to programming languages?

[nine_k]

А почему? Язык-то вполне себе, а открытые реализации CLR существуют (mono, да).
Хотя ещё сырее перла, наверное. А java тяжелее (примерно как C#, наверное). А php не так быстр на нетривиальной логике. Некуда податься :-]

[nine_k]

Слышал название "ре-бемоль" (т. к. C# есть обозначение "до-диез").

[b-a-t.livejournal.com]

Та же фигня, поэтому когда у коллеги был аналогичный затык, очень дико удивлялся, как же так можно было сделать...

И вообще, взяв для себя за правило писать на Perl как на C, я избежал(IMHO) очень многих проблем..

то ж пердл...

[(Anonymous)]

пользуйтесь Python.

[avnik.livejournal.com]

Упс.
Я почему-то думал что local $_ это имплицитное свойство любого замыкания. А это оказывается у некотрых операторов/функций делающих цикл.

[alexcohn.livejournal.com]

а для чего ($_ = $tmp) в хвосте grep?

[avva.livejournal.com]

Чтобы восстановить разрушенное вызовом функции значение $_, т.к. grep по завершении блока выдаст наружу именно $_, а не мой $tmp.

[smilga.livejournal.com]

Это хуже, чем ре-бемоль. Это D-flat.

Ага

[egorfine.livejournal.com]

я это нутром чувствовал(c)

Не использую поэтому $_. Зато использую: warnings, use strict, ENGLISH. И если писать на перле как на C (т.е. достаточно строго), то действительно, можно избежать многих проблем. А держать большие проекты на перле также возможно, как и любом другом языке - все зависит от культуры программирования. Чем строже язык, тем ниже может быть культура программирования. И чтобы на таком языке, как perl, поддерживать больше проекты - нужно быть очень дисциплинированным программистом.

Говорю от имени опыта написания некоей большой системы. Мегабайты кода на перле.

Вот чего в перле никак нельзя делать - это деньги считать.

[alexcohn.livejournal.com]

То есть по крайней мере его grepa встроенному циклу этот $_ не помеха... И то ладно