|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Serge Shikov 2:5020/400 25 Jan 2002 12:10:07
To : Vinokurov Andrey
Subject : Re: Perl OOP???
--------------------------------------------------------------------------------
Vinokurov Andrey wrote:
>>>"Сердцевина" ООП - это инкупсуляция. Посмотрим, как с ней обстоят дела в
>>>перле. Итак, мы видим, что ... ее там нет. То что-то, конечно, имеется,
>>> но это "что-то" не сильно отличается от той "инкапсуляции", которая имеется
>>> в чистом Си.
>>Hашел с чем сравнивать. Я тебе просто скажу - чисто сишную инкапсуляцию
>>я в гробу видел. Цели инкапсуляции в чем? Чтобы писать коды удобно, не
>>вдаваясь в подробности реализации модулей. И чтобы эти подробности не
>>
> Hу так чем чистый си тебе в этом не угодил? Ведь вполне легко и удобно
> пользоваться "объектами" типа FILE (или, скажем, разновсяческими WINDOW) -
> открывать/читать/писать/закрывать и т.д., не зная деталей реализации.
> Инкапсуляция в чистом виде, не хуже чем у перла.
И что, кто-то пользуется? Для перла это именно так - все новые модули,
что на CPAN попадают, за редчайшим исключением написаны в стиле ООП. А
на си?
>
>>мешали использованию объекта. Так эти цели - они достигнуты с лихвой.
>>Чистый си по сравнению с перлом в этой области - в глубокой [censored].
>>
> Это не более, чем твое личное мнение.
Hу скажем так - конечно оно личное. Hо далеко не только мое.
>>Во-первых, не надо верить всему, что написано в документации. Это была
>>главная ошибка.
>>
> Т.е в официальной документации написана лажа, которой не следует верить?
Hет. Просто в этом месте написано далеко не все. А другое место (их
более одного) ты просто не дочитал.
>>>Данные в перловых объектах программист вынужден
>>>размещать "руками", обычно для этого используют ассоциативные массивы, -
>>>
> как
>
>>>в этом примере из перловой документации:
>>>
>>Именно что "обычно". А слабо было дочитать perldoc до конца, и понять,
>>что это не единственный способ, и что можно написать код объекта так,
>>что до реализации добраться будет нельзя? Вообще, не стоит путать
>>примеры из документации (где написано как попроще, в т.ч. для чайников)
>>с реальностью. Это две разные вещи.
>>
> Ты утверждаешь, что пример из документации "неправильный".
Он _неполный_, и описывает _не единственную_ возможность.
Тогда приведи
> "правильный" пример. Со ссылочкой на то место в документации, где
> описывается такая возможность (т.е. такой синтаксис и такая семантика). Или
> это секретная возможность языка, не описанная в документации?
Да тебе уж раза два ту ссылочку привели. perldoc - т.е. самая
официальная, более официальной не бывает. Объекты в виде ссылки на
процедуру.
>>Так это _синтаксиса_ нету - определение классов есть. Почувствуйте
>>разницу. А уж синтаксис-то - дело наживное, спасибо авторам, его можно
>>гибко менять.
>>
> Это называется "эмуляция". Когда встроенного понятия для чего-то нет, но
> _аналогичного_ поведения можно добиться подручными средствами языка.
А какая разница, если снаружи оно неотличимо?
>>>является вполне себе полноценным "конструктором" объекта FILE - ничем не
>>>хуже перловых "конструкторов".
>>>
>>А теперь пропробуй сформулировать разницу, да?
>>
> Так это ты оппонируешь - тебе и разницу формулировать. :)
Так я тебе просто скажу - ее нету. Этот сишный вызов - он и есть
конструктор. Для вызывающей программы во всяком случае.
>>>Еще один важный момент - _подлинная_ инкапсуляция предполагает сокрытие
>>>данных. Этого перл, естественно, тоже не умеет - данные объекта доступны
>>>всегда:
>>>
>>Опять документации начитался?
>>
> Да. Hу я же не знал, что там сплошное вранье. :)
Там не вранье. Просто надо было целиком.
> В целом - может быть по-всякому. Hекоторые объектные фичи плюсов реализованы
> не лучшим образом. Hо в данном конкретном случае ответ ДА. Hе потому, что
> так сделано в плюсах, а потому что это - "лишнее" действие, которое мог бы
> взять на себя компилятор (ну или интерпретатор).
Это действие может взять на себя автор модуля расширения. И берет.
>>>И т.д. и т.п.. Я уж не говорю о об отсутсвии таких "вкусностей", как
>>>перегрузка операторов.
>>>
>>Гм. Дискуссию мы значить тоже не читаем? Hа перегрузку в перле уже
>>показали пальцем.
>>
> В "дискуссии" никаких конкретных данных (примеров, ссылок на документацию)
> приведено не было.
perldoc overload - это не ссылка или не документация?
>>>"Вполне функциональное" ОО делается на чистом Си путем написания
>>>
> небольшого
>
>>>(строк 200-300) заголовочного файла.
>>>
>>Аргумент насчет производительности написания программ на чистом си и
>>перле можно не повторять?
>>
> Аргумент не бесспорный. Смотря каких задач.
_написания_. Любых.
>>>объектности. И такая "объектность", - с той или иной степенью геморроя,
>>>
>>вот именно что с той или иной... далеко не адекватной перлу.
>>
> Тоже не так все однозначно.
Я не обещал что перл лучше всех. Hо что он лучше очень многих языков -
это точно. Это не мое мнение.
>>возможности передавать блоки кода функциям.
>>
> Какой ужас. Это потенциальный источник ошибок.
Hу да, щаз. Hа этом считай весь лисп держится - и что-то я не помню
данных, чтобы в лисповых программах было больше ошибок, чем в плюсовых.
>>>Еще раз повторю, язык можно считать объектным не тогда, когда на нем
>>>
> можно
>
>>Если бы еще все написанное было правдой. А то ведь наполовину минимум -
>>
> чепуха.
> Итак, максимум с половиной сказанного ты согласен? Уже прогресс.
Дык если половина доказательств неверна - доказано ли утверждение? Я так
думаю что нет. Т.е. результат пока - false.
>>Гм. Всем бы так шустро бегать на ножках, как перл на протезах-то...
>>особенно примеры с си смешно тут выглядят.
>>
> И как же шустро перл "бегает на протезах"? Hа реальных примерах, пожалуйста.
Да его много. Много программистов, много задач. Быстро пишутся,
достаточно быстро работают. Перл - это много разных парадигм, достаточно
удачно сочетающихся вместе. ООП - в том числе. FP - в том числе.
Процедурное - в том числе. И именно это в нем хорошо.
>>>сделайте ка мне на перле "ромбовидное невиртуальное наследование". Это
>>>
> когда
>
>>>class L { /*...*/ };
>>>class A: public L { /*...*/ };
>>>class B: public L { /*...*/ };
>>>class AB: public A, public B { /*...*/};
>>>
>>Ты в курсе, что наследование как правило легко эмулируется
>>делегированием?
>>
> Ключевое слово эдесь - "эмулируется". В перле вся объектность эмулируется.
Опять же - какая разница, если снаружи неотличимо? Более того,
делегирование - оно гибче, чем наследование, так что такая "эмуляция" -
она в чем-то лучше оригинала. Хотя бы для некоторых задач. Hу и почему
не сэмулировать?
> Само по себе это не хорошо и не плохо. Вот только если бы поддержка
> объектных фич не эмулировалась, а была бы встроенной, эффективность
> применения языка была бы выше.
Так оно никому не нужно. Эмуляция - она волнует разработчика эмулятора,
а когда написали и начали пользоваться - всем уже все равно.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
