какой ещё компиляции?

мне бы и в голову не пришло проверять типы на этапе компиляции, и почему бы такими вещами не заниматься именно компиляторам. В жизни этого не делал! И зачем это нужно? (пожалуйста, не отвечайте на этот вопрос)

perl в принципе "другой", это лингвистическое изобретение, очень особенное и эффективное, если его правильно понимать, а не бросаться в критике странными фразами

Это сообщение отредактировал(а) everyone - 3.6.2009, 23:15

в книге написано, что в С++ компилятор дописан на Си, дописано ООП, точно так же как и на perl (какая разница не чем оно написано на Си или на perl?)

в smaltalk в его архитетуре есть ООП! и java наверное так же...

разве сама суть сильно отличатеся во всех языках ООП? там как правило играют роль дополнительные возможности (или модули) которые управляют всем этим, шаболоны и т.д.?

там еще есть видел на атрибутах http://search.cpan.org/~jjordan/Attribute-...hod/Typeable.pm
http://search.cpan.org/search?query=CLASS%...ER&mode=all


Это сообщение отредактировал(а) gcc - 4.6.2009, 06:37

Каких типов? Вы мое первое сообщение читали? Perl - нетипизированный язык, так что вопрос некорректен.
Если конечно не считать за типы хэши, скаляры и списки, что вообще-то неправильно. Тем не менее для них можно сделать проверку на этапе компиляции.

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

вот нашел еще

Clone::Fast - Natively copying Perl data structures
Moose - A postmodern object system for Perl 5.
Mouse - Moose minus the antlers
Class::Prototyped - Fast prototype-based OO programming in Perl
Class::Closure - Encapsulated, declarative class style
Class::Spiffy - Spiffy Framework with No Source Filtering


это наверное для больших как-то проектов?



Оригинал: http://laziness-impatience-hubris.blogspot.../blog-post.html

сборка примеров и шаблонов ООП

http://perldesignpatterns.com/perldesignpatterns.html

TOPH, а какой язык есть не простой? этот тот у которого мало возможностей?

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




но ошибка будет обнаружена только при выполнении, что неприятно. Так что типизированный перл или нет - а типы на нём сделать можно, запрет на неправильное присвоение типов сделать можно, но только на время выполнения, не компиляции.

Это сообщение отредактировал(а) mvsgt - 3.7.2009, 16:41

Я вам даже больше скажу: MooseX::Declare позволяет выполнять проверки на этапе компиляции (с помощью сигнатур методов). Тем не менее Perl не становится от этого типизированным языком.
Мы говорим о разных вещах. Я о языке, а вы о надстройке (тем более, что она работает в рантайме). Типизация должна быть реализована на уровне примитивов.

Это сообщение отредактировал(а) KSURi - 3.7.2009, 17:32

Прошу прощения, я ошибся по поводу MooseX: (вернее будет сказать MooseX::Types) и проверки типов на этапе компиляции. На самом деле все делается в рантайме. Вобщем-то это только укрепило мое мнение).

UPD:
если совсем точно, то стоит упомянуть, что использование вообще не существующих типов все-таки ловится на этапе компиляции

Это сообщение отредактировал(а) KSURi - 16.7.2009, 12:33

KSURi, а eval не проверит на этапе компиляции?
eval выполняет код на этапе компиляции

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

Не хочу вмешиваться в ваш спор, ибо для меня самый лучший перл - процедурный перл   
Но не могу не вставить свои три копейки, собственно в пользу процедурного.... Я даже не буду уходить в инкапсуляцию и т.п. А пойду проще.. Вот я недавно сменил работу, на пердыдущей писал на процедурном перле и малость на ООП Java. Сейчас ООП Perl... Сталкиваюсь с подобным кодом



И почти весь проект состоит из подобного.. Хотя я конечно погорячился насчет ООП Perl'а. Стараюсь конечно держать себя в руках, ибо я человек новый в фирме, но иной раз так и хотса надавать некоторым по одному месту   

И это далеко не в первый раз когда я вижу такое(т.е. не только в этой фирме). Лично я в теории тоже могу много порассказать и написать о том, что и как нужно писать и через какие инструменты языка реализовывать, но на практике не всегда все получается так как нужно.. И по объективным и по субъективным причинам. Поэтому мой принцип - делай проще... Умное процедурное программирование гораздо лучше глупого ООП.

Вот в том примере, в котором привел я - самое ужасное - что не понятно, что именно за объект должен был вернуться в $step.

Понимаете, если в Java мне приходится писать



Дык вот, я четко знаю какой объект мне приходит, и могу с легкостью разобраться... А в перловом примере, мне сначала приходится искать то место, где в поле присвоили искомый объект $step, а это еще не факт, что легко и быстро... А потом еще разбираться и с методом, а он мож вообще "прародительский"   
Хотя, меня как разработчика, проблемы с которыми я сталкиваюсь в перле при ОО стиле - не должны были бы интересовать...

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

Да и мое мнение, не важно процедурно или ОО, главное чтобы грамотно... но к сожалению, многие кто пытается писать на ОО стиле и выдает свой код за оный - далеки от этого, а вот писать на процедурном не многие стремятся.. не знаю, мож потому что типа "не модно"... Типа гнем пальцы и пишем на ООП.. А я видел очень хороший и грамотный код на процедурном стиле, не без изъянов конечно, но очень достойный.... не многие даж на процедурном смогут так писать. 

предложите MVC Catalyst использовать

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

и еще можно писать парадигму которая максим. подходит под данную программу...





Это сообщение отредактировал(а) gcc - 19.11.2009, 07:52

Это полиморфизм. И это прекрасно. Это дает вам возможность писать абстрактные алгоритмы.
Тут необходимо уточнить два момента:
- в языках с динамической типизацией - это опасно, т.к. у вас нет гарантий что полученный "объект реализует нужный интерфейс"
- полиморфизм начинает помогать в Больших системах. Если программный комплекс не очень большой, или разбит на отдельные сервисы, то это просто усложняет код.