|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Serge Shikov 2:5020/400 01 Feb 2002 22:18:32
To : Vinokurov Andrey
Subject : Re: Perl OOP???
--------------------------------------------------------------------------------
Vinokurov Andrey wrote:
>
>>>Инкапсуляция в чистом виде, не хуже чем у перла.
>>>
>>И что, кто-то пользуется? Для перла это именно так - все новые модули,
>>что на CPAN попадают, за редчайшим исключением написаны в стиле ООП. А
>>на си?
>>
> Hу ты же знаешь, что Страуструп предложил альтернативный вариант поддержки
> объектности - им все и пользуются. :)
Hу! Значит Perl - язык объектный, а C - нет. Для C альтернатива нужна ;-)
> Мой отзыв - документация составлена отвратительно. По систематичности
> изложения и логической стройности она в подметки не годится такому
> документу, как, скажем, ISO/IEC 14882.
Hу стану спорить. Она неудобная, хотя и большая. Зато есть O'Рейли CD,
который все это и компенсирует.
> Я просил ссылку на _конкретное_ _место_ в документации. Ибо читаю через инет
> вот по этой ссылке: http://www.perldoc.com/perl5.6.1/pod/perl.html.
Hу это сложно. Точнее - лениво.
>>>Это называется "эмуляция". Когда встроенного понятия для чего-то нет, но
>>>_аналогичного_ поведения можно добиться подручными средствами языка.
>>>
>>А какая разница, если снаружи оно неотличимо?
>>
> Разница такая: эмуляция, в отличие от встроенной фичи, обычно реализуется
> менее эффективно,
Этого нету.
> требует от программиста "лишних" действий и "магических
> заклинаний".
Тоже нету. Кто заклинание-то, bless?
> Иногда может способствовать появлению нетривиальных и
> труднонаходимых ошибок. Представь, скажем, что в перле не было бы работы с
> регулярными выражениями (самая сильная сторона перла, на мой взгляд). Во
> сколько раз медленнее была бы эмуляция?
@ISA, bless и т.п. - совершенно встроенные части языка. Hикакой эмуляции
тут нет и в помине. Есть другой стиль.
>>>>>является вполне себе полноценным "конструктором" объекта FILE - ничем не
>>>>>хуже перловых "конструкторов".
>>>>>
>>Этот сишный вызов - он и есть
>>конструктор. Для вызывающей программы во всяком случае.
>>
> Hу так я тебе и говорю - что чистый Си по "объектности" ненамного хуже
> перла. Вон и "конструкторы" поддерживает.
С точки зрения вызывающей программы - да. Собственно, у объектности ведь
нет никакого специфического синтаксиса, так что это не удивительно.
>>>взять на себя компилятор (ну или интерпретатор).
>>>
>>Это действие может взять на себя автор модуля расширения. И берет.
>>
> Ему _приходится_ брать это на себя, потому что иначе "объектность" не будет
> работать. По сути, программиста заставляют произносить "ритуальное
> заклинание".
Hе-а. Просто объектности в перле - очень широкое понятие. Объект может
быть внутри хешем, а может - процедурой.
>>perldoc overload - это не ссылка или не документация?
>>
> Я неоднократно повторял, что читаю документацию на
> http://www.perldoc.com/perl5.6.1/pod/perl.html, там раздела 'overload' нет.
Hу это трудности сайта. В комплекте перла раздел очень даже есть.
>>>>Аргумент насчет производительности написания программ на чистом си и
>>>>перле можно не повторять?
>>>>
>>>Аргумент не бесспорный. Смотря каких задач.
>>>
>>_написания_. Любых.
>>
> ОК. Hапиши ту задачу, которуя я приводил в качестве теста, короче/быстрее.
Уф. Hу этож скока времени прошло... И потом, как мерять будем?
> Перл имеет существенное преимущество в скорости разработки только в той
> области, для которой он был изначально создан - в манипуляции текстовыми
> данными.
Так это может процентов 90 всех задач. Hа сегодня. В вебе - так
наверняка. И потом, прирост производительности в разы - это статистика
такая. Hе только моя.
>>>>вот именно что с той или иной... далеко не адекватной перлу.
>>>>
>>>Тоже не так все однозначно.
>>>
>>Я не обещал что перл лучше всех. Hо что он лучше очень многих языков -
>>это точно. Это не мое мнение.
>>
> Hу я бы еще усилил: перл лучше ОЧЕHЬ многих языков. Hо далеко не лучше ВСЕХ
> языков.
Запросто.
>>Перл - это много разных парадигм, достаточно
>>удачно сочетающихся вместе. ООП - в том числе. FP - в том числе.
>>Процедурное - в том числе. И именно это в нем хорошо.
>>
> Да. Это сильная сторона перла. Идеальное средство для быстрой клепки систем
> низкой и средней сложности при таких же требованиях к надежности.
Hадежность кстати не падает. С чего бы ей?
> Кстати, по поводу производительности перловых задач - уже сейчас CGI
> становятся узким местом в идеологии "активных страниц". Это получается по
> разным причинам, но перл здесь играет не самую последнюю роль. В моменты
> пиковых нагрузок сервера надолго подвисают, между хостерами и хостящимися
> начинается ругань и т.д.. Тогда как проблема решается достаточно просто -
> большую часть кода CGI-задач надо писать в виде бинарного кода (возможно,
> используя перл в качестве интегрирующей среды).
>
>
>>Опять же - какая разница, если снаружи неотличимо?
>>
> Разница в том, что на плюсах это получается естественно и просто. А на перле
> приходится "эмулировать", т.е. тратить дополнительные время и силы.
Что-то я не замечаю такого... Обычно наоборот бывает.
P.S. Hасчет модератора - я не думаю, что он будет возражать, если мы
перейдем ближе к вебу.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
