Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Религиозные войны > строгая vs не строгая типизация

Автор: Logo 10.2.2010, 10:18

Что лучше? Какие преимущества у одной перед другой?

Автор: azesmcar 10.2.2010, 10:20

Цитата(Logo @  10.2.2010,  10:18 ) Что лучше? Какие преимущества у одной перед другой?  Мое мнение - строгая, преимущества? Уменьшает количество потенциальных ошибок, делает код более понятным..по моему у нестрогой было только одно преимущество, которого после добавления в C# var не стало.

Автор: Lazin 10.2.2010, 10:36

строгая

Автор: nginx 10.2.2010, 10:54

Logo, строгая, ненавижу, что начал свое знакомство с программирование с PHP он не только динамично-типиз, он в свою очередь еще и слабо-типиз в отличии от Питона лучше начинать с .NET или Java любому начинающему

Автор: Logo 10.2.2010, 12:00

Я вот больше работал с языками с не строгой типизацией - PHP, Perl, JavaScript. Со строгими, вроде C++(относительно строгой), значительно меньше. Ну а начинал с бейсика) Цитата Уменьшает количество потенциальных ошибок Можно пример подобных ошибок?

Автор: azesmcar 10.2.2010, 12:11

Цитата(Logo @  10.2.2010,  12:00 ) Можно пример подобных ошибок? smile  ну например Код <?php     $i = 0;     $t = "";     if ($i == $t)         echo "true"; ?> да, этого можно избежать используя ===, но дело в том, что сравнение разных типов может являться ошибкой и тут нужно внимание программиста а не результат в виде false (или тем более true). В языках со строгой типизацией тут понадобился бы cast, тем самым вы сообщите компилятору/интерпретатору что вы на самом деле хотите сравнить два разных типа. Это нагляднее и для программиста, читающего код. Строгая типизация позволяет уберечься от многих ошибок, совершенных по невнимательности. К примеру в C++ у людей нередко возникают ошибки в связи с неявным приведением int-а к bool.

Автор: kemiisto 10.2.2010, 12:19

Logo, прежде чем говорить о типизации, предоставьте определения: что Вы называете строгой и нестрогой типизацией. А пока разговор ниачём.   К примеру, если в понятие строгая типизация включать невозможность неявного приведения типов (implicit type conversion), что, кстати говоря, делают часто, то Python нестрого типизированный язык. Иногда строгой считают типизацию, где вообще запрещены любые приведения типов - будь то неавные или явные. Так что - ждём-с определений.

Автор: Logo 10.2.2010, 12:36

Это да, операторы сравнения в некоторых языках черезчур перегружены, сравнивая числа и строки. Легко забыть, что имеет приоритет при сравнении разных типов, числовой или строковый. Здесь мне нравится подход Perl, в котором разные операторы сравнения строк и чисел Код $i = 0; $t = ""; if ($i == $t) {  #предупреждение о том что $t не число   print "сравнение как числа, равны" } if ($i eq $t) { } else {    print "сравнение как строки, не равны"; } С учетом этого, могут быть какие-то ошибки? А PHP вообще отдельная история  Код <?php   if("2" == "   2.000")     echo 'Я сравнил их как числа'; Но это не значит что это гуд.

Автор: Lazin 10.2.2010, 12:37

kemiisto, неявное приведение типов тоже бывает разным, к примеру, в приведении int к double я ничего плохого не вижу, а наоборот лучше только явно, причем функциями floor и ceil

Автор: Logo 10.2.2010, 12:38

Цитата К примеру в C++ у людей нередко возникают ошибки в связи с неявным приведением int-а к bool. А что там не понятного - 0 - false, остальное true, как везде

Автор: azesmcar 10.2.2010, 12:43

Цитата(Logo @  10.2.2010,  12:38 ) А что там не понятного - 0 - false, остальное true,  я не говорил что непонятно  я говорю проблемы возникают иногда..представь что переменная раньше была типа bool, хранила два статуса, потом расширили програмку (ну не учли этого) и сменили тип на int, вот забудешь в каком нибудь if -е поменять потом ищи проблему в логике, а ведь компилируется нормально. Кому как, по мне так лучше бы этого не было. Цитата как везде  если не ошибаюсь, джава этого не позволяет.

Автор: Logo 10.2.2010, 12:45

Цитата(kemiisto @ 10.2.2010,  12:19) Logo, прежде чем говорить о типизации, предоставьте определения: что Вы называете строгой и нестрогой типизацией. А пока разговор ниачём.   К примеру, если в понятие строгая типизация включать невозможность неявного приведения типов (implicit type conversion), что, кстати говоря, делают часто, то Python нестрого типизированный язык. Иногда строгой считают типизацию, где вообще запрещены любые приведения типов - будь то неавные или явные. Так что - ждём-с определений.  Да как и все - строгая, когда не производятся не явные приведения типов, не строгая - когда производятся. Динамическая - когда можно менять тип по ходу выполнения программы, и соответственно проверка типов на этапе исполнения - статическая, наоборот, на этапе компиляции. Добавлено через 2 минуты и 31 секунду Цитата как везде  ... при приведении типов

Автор: kemiisto 10.2.2010, 13:15

Цитата(Lazin @  10.2.2010,  13:37 ) kemiisto, неявное приведение типов тоже бывает разным, к примеру, в приведении int к double я ничего плохого не вижу, а наоборот лучше только явно, причем функциями floor и ceil Спасибо, что просветил, мил человек.  А то я ведь не знал. Думал, что только 2 типа данных существует на свете: int и bool.  Насчёт приведение целое -> http://en.wikipedia.org/wiki/IEEE_754: тут тоже есть свои подводные камни. Не всякое целое число точно представимо. Думаю, ты про это прекрасно знаешь и, конечно же, читал http://docs.sun.com/source/806-3568/ncg_goldberg.html. Но уж коли ты решил мне рассказать про общечеловеческие ценности, я тоже в долгу не останусь.   А так, да, согласен. В Oberon фенкция называиццо ENTIER(x). Аргумент - real type, тип результате - LONGINT. Возвращает largest integer not greater than x.

Автор: UniBomb 10.2.2010, 13:36

Цитата(azesmcar @  10.2.2010,  13:11 ) <?php     $i = 0;     $t = "";     if ($i == $t)         echo "true"; ?> В руби такое не проходит. 0 и nil там всё же разные вещи. Даже оператор === говорит не эквивалентны Цитата(Logo @  10.2.2010,  13:36 ) <?php   if("2" == "   2.000")     echo 'Я сравнил их как числа'; Раби и тут говорит, что ни о каком равенстве никакой речи и быть не может. Цитата(Logo @  10.2.2010,  13:38 ) 0 - false, остальное true, как везде Вы таки наверное уже догадались? Мне нравится нестрогая типизация в Ruby, но я в этом ничего не понимаю

Автор: MAKCim 10.2.2010, 13:42

юзайте аннотации и декораторы для проверки типов Код #!/usr/bin/python3 import inspect import functools def strictly_typed(function):     annotations = function.__annotations__     arg_spec = inspect.getfullargspec(function)     assert "return" in annotations, "missing type for return value"     for arg in arg_spec.args + arg_spec.kwonlyargs:         assert arg in annotations, "missing type for parameter '{1}'".format(arg)     @functools.wraps(function)     def wrapper(*args, **kwargs):         for name, arg in list(zip(arg_spec.args, args)) + list(kwargs.items()):             assert isinstance(arg, annotations[name]), "expected argument '{0}' of {1} got {2}".format(name, annotations[name], type(arg))         result = function(*args, **kwargs)         assert isinstance(result, annotations["return"]), "expected return of {0} got {1}".format(annotations["return"], type(result))         return result     return wrapper @strictly_typed def main(argv : tuple, value) -> int:     return value # main((), 1) # main((), 1.) # main([], 1) ps. код честно взят из одного источника ;)

Автор: GrayCardinal 10.2.2010, 13:46

Что значит лучше ? Юзать можно обе. А ошибки из-за невнимательности в любом случае будут... Добавлено через 21 секунду (не голосовал)

Автор: Logo 10.2.2010, 23:21

Цитата(azesmcar @  10.2.2010,  12:43 ) я не говорил что непонятно smile я говорю проблемы возникают иногда..представь что переменная раньше была типа bool, хранила два статуса, потом расширили програмку (ну не учли этого) и сменили тип на int, вот забудешь в каком нибудь if -е поменять потом ищи проблему в логике, а ведь компилируется нормально. Кому как, по мне так лучше бы этого не было. Да, согласен. Ситуация хотя и очень маловероятная, но возможная. Цитата(kemiisto @  10.2.2010,  13:15 ) Насчёт приведение целое -> The IEEE Standard for Floating-Point Number: тут тоже есть свои подводные камни. Не всякое целое число точно представимо. Думаю, ты про это прекрасно знаешь и, конечно же, читал What Every Computer Scientist Should Know About Floating-Point Arithmetic. Но уж коли ты решил мне рассказать про общечеловеческие ценности, я тоже в долгу не останусь. smile  Тоже верно, если с большими числами работать. Хотя с точность чисел с плавающей точкой и так надо держать ухо востро. Цитата(UniBomb @  10.2.2010,  13:36 ) Цитата(azesmcar @  10.2.2010,  13:11 Найти цитируемый пост) <?php     $i = 0;     $t = "";     if ($i == $t)         echo "true"; ?> В руби такое не проходит. 0 и nil там всё же разные вещи. Даже оператор === говорит не эквивалентны Руби проверил, он тут себя ведет тоже не лучшим образом. И ошибку не возвращает, и сравнение не проводит. Питон, кстати, так же работает.

Автор: Akella 13.2.2010, 10:44

Да, строгая лучше. Меньше потенциальных ошибок. Хотя иногда приходится и очень удобно применять вариантный тип, который как бы не имеет типа  Т.е. можно было бы в опрос добавить ещё пункт: строгая с применением вариантных типов

Автор: segrey 13.2.2010, 12:57

Честно говоря, в php не хватает что - то вроде такого: Код function __construct (array $arg) {} function __construct (MyCollection $arg) {} function __construct (int a, int b, int c) {} чтобы как в С++, в зависимости от того какие аргументы пришли - та функция и вызвалась. Можно конечно условие в конструкторе поставить, но это не кошерно

Автор: UniBomb 19.2.2010, 12:01

Цитата(Logo @  11.2.2010,  00:21 ) Руби проверил, он тут себя ведет тоже не лучшим образом. Ну почему же - в ruby есть оператор сравнения <=>, который будет равен nil если сравниваемые величины не подлежат сравнению (как в данном случае). Подмешанный оператор == основан на предыдущем и вероятно выдаёт false всегда, когда не true. По-моему тут всё логично.

Автор: mrbrooks 19.2.2010, 12:33

строгая, ибо это не только гламурно, но и кошерно.

Автор: Logo 20.2.2010, 12:32

Цитата Ну почему же - в ruby есть оператор сравнения <=>, который будет равен nil если сравниваемые величины не подлежат сравнению (как в данном случае).  Но nil и 0 в контексте if одно и тоже ведь. И вообще речь не о том. Он не выдает ошибки при сравнении "1" и 1. Что бы, как Java, избавить от потенциальных ошибок. Вместо этого продолжает выполнять программу. Однако и сравнение он тоже не производит.  Что бы, как Perl, что бы не заботится типах. Таким образом совмещая недостатки того и другого

Автор: fixxer 20.2.2010, 16:15

Цитата(Logo @ 20.2.2010,  12:32) Цитата Ну почему же - в ruby есть оператор сравнения <=>, который будет равен nil если сравниваемые величины не подлежат сравнению (как в данном случае).  Но nil и 0 в контексте if одно и тоже ведь. И вообще речь не о том. Он не выдает ошибки при сравнении "1" и 1. Что бы, как Java, избавить от потенциальных ошибок. Вместо этого продолжает выполнять программу. Однако и сравнение он тоже не производит.  Что бы, как Perl, что бы не заботится типах. Таким образом совмещая недостатки того и другого Таким образом не стоит забывать, что в Ruby все объект и == это метод. Таким образом это можно сравнивать с методом equals в Java, а не с == в Java.

Автор: k0rvin 12.3.2010, 21:27

Цитата(Akella @ 13.2.2010,  10:44) Да, строгая лучше. Меньше потенциальных ошибок. Хотя иногда приходится и очень удобно применять вариантный тип, который как бы не имеет типа  Т.е. можно было бы в опрос добавить ещё пункт: строгая с применением вариантных типов  я надеюсь Вы не про Variant из Делфи (точнее COM/OLE, я таких тонкостей не знаю)?

Автор: A5uKa 27.3.2010, 23:10

строгая с возможностью не строгой

Автор: Akella 23.4.2010, 14:47

k0rvin, когда я говорил о вариантном типе, то имел ввиду именно Variant. Но есть ещё OleVariant.

Автор: k0rvin 23.4.2010, 18:10

Цитата(Akella @ 23.4.2010,  14:47) k0rvin, когда я говорил о вариантном типе, то имел ввиду именно Variant. Но есть ещё OleVariant. но это же ужасный костыль и имеет отношение не к строгой/нестрогой типизации, а к статической/динамической =)

Автор: qweqwe 23.4.2010, 18:17

Цитата(mrbrooks @  19.2.2010,  12:33 ) строгая, ибо это не только гламурно, но и кошерно. даже не знаю, за что тебя заминусовали, бро сразу видно - форум быдлокодеров, но не гламурных! Добавлено через 37 секунд только строгая, абсолютно всегда и везде

Автор: nerezus 23.4.2010, 22:42

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

Автор: SneG0K 23.4.2010, 23:29

Цитата(mrbrooks @  19.2.2010,  11:33 ) строгая, ибо это не только гламурно, но и кошерно.  Ага, кошерно как еврейское рождество. В зависимости от задачи. При строгой типизации производительность выше, вроде.

Автор: k0rvin 24.4.2010, 00:39

Цитата(nerezus @ 23.4.2010,  22:42) При динамической(как правило в нестрогой она, ну за исключением всяких там C) все равно приходится вести xxxdoc теги, в итоге кода больше выходит... что? переформулируйте мысль на более литературном или техническом языке. Цитата(nerezus @ 23.4.2010,  22:42) При динамической ... проферок типизации нету. Код CL-USER> (numberp 1) T CL-USER> (numberp "a") NIL CL-USER> (stringp "a") T CL-USER> (type-of 1) FIXNUM CL-USER> (type-of "a") SIMPLE-TEXT-STRING ня?

Автор: qweqwe 24.4.2010, 09:52

Цитата(nerezus @  23.4.2010,  22:42 ) а проферок типизации нету есть, но только в рантайме Цитата(SneG0K @  23.4.2010,  23:29 ) В зависимости от задачи. как вы все ### тыкать сюда эту абсолютную истину вот приведи пример задачи, которая выигрывает от нестрогой типизации Цитата(SneG0K @  23.4.2010,  23:29 ) При строгой типизации производительность выше, вроде. товарищ главнокомандующий, вы путаете строгую типизацию и статическую типизацию

Автор: JackYF 24.4.2010, 19:00

Цитата(qweqwe @  24.4.2010,  08:52 ) вот приведи пример задачи, которая выигрывает от нестрогой типизации Любая задача, выполнение которой занимает меньше времени, чем написание кода для неё. Например, скрипты.

Автор: kemiisto 24.4.2010, 19:11

Цитата(JackYF @  24.4.2010,  20:00 ) Любая задача, выполнение которой занимает меньше времени, чем написание кода для неё. Например, скрипты. Хм... Что-то я сомневаюсь.  Итак, Цитата(Logo @  10.2.2010,  13:45 ) Да как и все - строгая, когда не производятся не явные приведения типов, не строгая - когда производятся. Динамическая - когда можно менять тип по ходу выполнения программы, и соответственно проверка типов на этапе исполнения - статическая, наоборот, на этапе компиляции. JackYF, я бы ещё понял, если бы речь шла о преимуществах динамической типизации в плане высокой скорости прототипирования. Но нестрогая будет только мешать. Если исходить из вышеупомянутых определений, то, скажем, в Python типизация динамическая строгая, а в PHP - динамическая нестрогая. Бенефиты от динамической типизации получим и там и там, а вот об грабли нестрогой типизации, расставленные в PHP, мы весь лоб расшибём. P.S. В Python типизация не совсем строгая...

Автор: k0rvin 24.4.2010, 19:49

Цитата(qweqwe @ 24.4.2010,  09:52) как вы все ### тыкать сюда эту абсолютную истину вот приведи пример задачи, которая выигрывает от нестрогой типизации пример: Код (let ((x (assoc 'b '((a . 1) (b . 2) (c . 3)))))   (when x (cdr x))) ; => 2 будь типизация сильно строгой, результат assoc необходимо было бы писать "(when (not (null x)) ..." или типа того мелочь, но чем больше кода, тем количество таких мелочей растет в геометрической прогресси => растёт трудность восприятия кода Цитата(qweqwe @ 24.4.2010,  09:52) товарищ главнокомандующий, вы путаете строгую типизацию и статическую типизацию не совсем, чем строже типизация, тем уверенней компилятор может производить оптимизации, ведь он может однозначно установить тип, а не думать "тут возможны такие типы: ..."

Автор: kemiisto 24.4.2010, 20:14

Цитата(k0rvin @  24.4.2010,  20:49 ) пример k0rvin, я смотрю ты Лисп(?) используешь строго по назначению - толстый троллинг.  Ты бы хоть пояснял нам, императивным нищебродам, что там происходит.   Цитата(k0rvin @  24.4.2010,  20:49 ) не совсем, чем строже типизация, тем уверенней компилятор может производить оптимизации, ведь он может однозначно установить тип, а не думать "тут возможны такие типы: ..." qweqwe, вот, смотри. И ещё один путает. Речь идёт о том, что со строгой типизацией нужно явно указывать свои намерения при приведении типов. Таким образом транслятор языка со строгой типизацией будет увереннее находить ошибки, которые транслятор языка с нестрогой типизацией будет "проглатывать", предполагая неявное приведение типов. Эти ошибки очень часто являются логическими ошибками. Чем раньше они будут отловлены, тем лучше. Логическую ошибку можно: отловить в compile-time; отловить в run-time; не отловить вовсе. Чем раньше - тем лучше. Вероятность успешного "отлова" в compile-time будет максимально в случае использование компиляторов языков со строгой типизацией. Если для этих языков использовать интерпретаторы - мы просто спускаемся на уровень ниже. Вероятность локализовать ошибку - та же. В случаем нестрогой типизации ошибку очень трудно локализовать.

Автор: nerezus 24.4.2010, 20:23

Цитата что? переформулируйте мысль на более литературном или техническом языке. какие слова не понятны? буду разъяснять их значение. Цитата Любая задача, выполнение которой занимает меньше времени, чем написание кода для неё. Например, скрипты.  Попробуйте скрипты документировать. И сравните )

Автор: kemiisto 24.4.2010, 20:24

k0rvin, кстати говоря, все Лиспы, вроде как, строго типизированные языки.

Автор: qweqwe 24.4.2010, 20:44

Цитата(k0rvin @  24.4.2010,  19:49 ) не совсем, чем строже типизация, тем уверенней компилятор может производить оптимизации, ведь он может однозначно установить тип, а не думать "тут возможны такие типы: ..." нестрогая типизация, это когда компилятор видит, скажем сравнение строки и null, и генирирует такой код, который проверяет, пустая ли строка, и если она пустая - сравнение возвращает true, это крайне весело и остроумно, но к счастью - не ведет к ускорению программ (иначе ПэХаПэ был бы самым быстрым языком на свете)   Цитата(kemiisto @  24.4.2010,  20:24 ) все Лиспы, вроде как, строго типизированные языки так точно, лиспы не пальцем деланы

Автор: k0rvin 24.4.2010, 21:26

Цитата(kemiisto @ 24.4.2010,  20:14) k0rvin, я смотрю ты Лисп(?) используешь строго по назначению - толстый троллинг.  Ты бы хоть пояснял нам, императивным нищебродам, что там происходит.   Нет такого языка "лисп". а Common Lisp весьма императивный язык. в том числе. Код (assoc 'b '((a . 1) (b . 2) (c . 3))) ; => (b . 2) (cdr '(b . 2)) ; => 2 (macroexpand '(when x (cdr x))) ; => (if x (progn (cdr x))) Добавлено @ 21:27 Цитата(nerezus @ 24.4.2010,  20:23) какие слова не понятны? буду разъяснять их значение. все слова понятны. по-отдельности. вместе же они у Вас составляют кашу Добавлено @ 21:37 Цитата(kemiisto @ 24.4.2010,  20:24) k0rvin, кстати говоря, все Лиспы, вроде как, строго типизированные языки. откуда такая уверенность? "диалектов лиспа больше, чем программ, написанных на нём". в Common Lisp типизация не сильно строгая: nil используется и как пустой список, и как "ложь", истиной является значение любого типа, кроме nil. ну и полиморфизм никто не отменял, благо CLOS предоставляет классы для всех встроенных типов, соответственно можно написать свои сколь угодно нестрогие функции =) в Scheme чуть по-строже, есть специальные булевы константы: #t и #f, пустой список '() не является "ложью", однако как и любое другое значение, отличное от #f, является "истиной" ну и конечно же и в том, и в другом списки и массивы гетерогенны однако типизация в CL и Scheme построже Сишной

Автор: k0rvin 24.4.2010, 21:43

Цитата(qweqwe @ 24.4.2010,  20:44) нестрогая типизация, это когда компилятор видит, скажем сравнение строки и null, и генирирует такой код, который проверяет, пустая ли строка, и если она пустая - сравнение возвращает true, это крайне весело и остроумно, но к счастью - не ведет к ускорению программ (иначе ПэХаПэ был бы самым быстрым языком на свете)   я разве писал, что нестрогая типизация приводит к ускорению программы? впрочем Вы правы, для статически типизированных языков разницы в производительности никакой. для динамически типизированных разница есть, ведь проверки типов придётся проводить в рантайме

Автор: qweqwe 24.4.2010, 23:13

Цитата(k0rvin @  24.4.2010,  21:43 ) впрочем Вы правы, для статически типизированных языков разницы в производительности никакой. для динамически типизированных разница есть, ведь проверки типов придётся проводить в рантайме  проверки типов есть всегда, только в случае строгой типизации - проверка приведет к одному результату, а в случае не строгой - к другому

Автор: nerezus 25.4.2010, 16:26

Цитата вместе же они у Вас составляют кашу  Жаль ( Тогда советую перечитывать до тех пор, пока полностью не поймете смысл, но не более 4 часов подряд. Добавлено через 4 минуты и 39 секунд Цитата При динамической(как правило в нестрогой она, ну за исключением всяких там C) все равно приходится вести xxxdoc теги, в итоге кода больше выходит... При динамической типизации(как правило она "в комплекте" с нестрогой типизацией, за исключением языков типа C) все равно приходится вести phpdoc/etc теги для работы автокомплита типов и документации, в итоге кода больше выходит...

Автор: qweqwe 25.4.2010, 18:04

Цитата(nerezus @  25.4.2010,  16:26 ) При динамической типизации(как правило она "в комплекте" с нестрогой типизацией, за исключением языков типа C) все равно приходится вести phpdoc/etc теги для работы автокомплита типов и документации, в итоге кода больше выходит...  у вас PHP головного мозга, уважаемый нестрогая и динамическая типизация - ортогональные вещи

Автор: nerezus 25.4.2010, 20:39

qweqwe, а у вас ПГМ) читаем первую часть моего поста, долго думаем. Специально же РАЗДЕЛИЛ эти понятия в сообщении.

Автор: qweqwe 25.4.2010, 20:43

Цитата(nerezus @  25.4.2010,  20:39 ) ПГМ Православие Головного Мозга?  Добавлено через 1 минуту и 57 секунд Цитата(nerezus @  25.4.2010,  20:39 ) читаем первую часть моего поста, долго думаем. Специально же РАЗДЕЛИЛ эти понятия в сообщении.  зачем? мысль я понял, она не оригинальна, во первых, а во вторых, нестрогими могут быть и статические ЯП, а не только PHP

Автор: k0rvin 25.4.2010, 21:13

так значительно лучше ----- Цитата(nerezus @ 25.4.2010,  16:26) автокомплита типов что это? Добавлено через 1 минуту и 25 секунд Цитата(qweqwe @ 25.4.2010,  20:43) нестрогими могут быть и статические ЯП, а не только PHP ну так он и написал "обычно, за исключением всяких С" =)

Автор: qweqwe 25.4.2010, 21:19

Цитата(k0rvin @  25.4.2010,  21:13 ) что это? он имел ввиду автокомплит в IDE, в php можно указывать аннотации, по которым IDE разберется что показывать в автокомплите

Автор: k0rvin 25.4.2010, 21:57

Цитата(qweqwe @ 25.4.2010,  21:19) Цитата(k0rvin @  25.4.2010,  21:13 ) что это? он имел ввиду автокомплит в IDE, в php можно указывать аннотации, по которым IDE разберется что показывать в автокомплите  эээ... а типы тут при чём? или имеется в виду для конструкций вида (хз как в пхп, пишу в С-подобном синтаксисе): Код myObject->myMeth<нажимаем хоткей для автокомплита и имя метода дополняется> ?

Автор: nerezus 25.4.2010, 23:52

Цитата myObject->myMeth<нажимаем хоткей для автокомплита и имя метода дополняется>  Да. Т.е. IDE будет знать тип myObject, то сможет правильно дополнить. Именно поэтому для PHP есть нормальные IDE, а для python - нету и не будет.

Автор: k0rvin 26.4.2010, 06:58

Цитата(nerezus @ 25.4.2010,  23:52) Цитата myObject->myMeth<нажимаем хоткей для автокомплита и имя метода дополняется>  Да. Т.е. IDE будет знать тип myObject, то сможет правильно дополнить. Именно поэтому для PHP есть нормальные IDE, а для python - нету и не будет. откуда такая уверенность? может гвидо разрешит питонистам что-то типа того же, что есть в пхп для этого. ну и да, что в пхп, что в пейтоне объектная модель -- уг =)

Автор: nerezus 26.4.2010, 07:09

Цитата откуда такая уверенность?  В невозможности определить тип в питоне в IDE, т.к. он нигде не указан. Цитата может гвидо разрешит питонистам что-то типа того же, что есть в пхп для этого.  Когда разрешит - тогда и поговорим. Сейчас этого нету. Цитата ну и да, что в пхп, что в пейтоне объектная модель -- уг =)  Это твои эротические фантазии ;) PHP копирует джаву. На вскидку нету видимости пакетов, анонимных классов, перегрузки сравнения. Остальное вполне себе скопировано и переделано в динамику с кучей добавлений.

Автор: NLspieler 26.4.2010, 07:55

У php не строгая типизация? В общем то это так, но нельзя забывать, что в php есть несколько операторов сравнения, а именно не только == , != ,  но и === , !==   которые требуют строгое совпадение типа. Код if ('' === FALSE)  {     echo 'TRUE' ; } else  {     echo 'FALSE' ; } //Выведет FALSE   if ('' ==   FALSE)  {     echo 'TRUE' ; } else  {     echo 'FALSE' ; } //Выведет TRUE ; Таким образом, при необходимости можно пользоваться любым видом типизации. И при некотором опыте, никаких ошибок  от этого больше не возникает. Правда, в php можно производить операции над разными типами данных, например Код echo 10 / "0.5" ;  //Деление целого числа на строку, которая преобразуется в double, результат 20 Возможно это и может привести к ошибках, но в моей практике никогда такого не было. С другой стороны это очень удобно. Можно сразу, без преобразования типов, приступить к вычислениям.  Обращаемся к скрипту по get-ссылке test.php?a=10&b=0.5 Код <? echo $_GET['a'] / $_GET['b'] ; //Результат опять же 20 ?> Не смотря на то, что оба значения представляют собой строки, можно тут же использовать их в математических вычислениях. Удобно.

Автор: k0rvin 26.4.2010, 12:27

Цитата(nerezus @ 26.4.2010,  07:09) Это твои эротические фантазии ;) PHP копирует джаву. На вскидку нету видимости пакетов, анонимных классов, перегрузки сравнения. Остальное вполне себе скопировано и переделано в динамику с кучей добавлений. Это факт, лучшие объектные модели в SmallTalk и CLOS Добавлено @ 12:30 Цитата(NLspieler @ 26.4.2010,  07:55) У php не строгая типизация? В общем то это так, но нельзя забывать, что в php есть несколько операторов сравнения, а именно не только == , != ,  но и === , !==   которые требуют строгое совпадение типа. Код if ('' === FALSE)  {     echo 'TRUE' ; } else  {     echo 'FALSE' ; } //Выведет FALSE   if ('' ==   FALSE)  {     echo 'TRUE' ; } else  {     echo 'FALSE' ; } //Выведет TRUE ; Таким образом, при необходимости можно пользоваться любым видом типизации. И при некотором опыте, никаких ошибок  от этого больше не возникает. ты не прав, это нифига не строгая типизация, при строгой === должно выбрасывать исключение на этапе компиляции при статической или в рантайме при динамической типизации

Автор: neutrino 28.4.2010, 23:57

Панацеи нет. Плохо везде использовать нестрогую типизацию. Но иногда она спасает делая код легкочитаемым => легкоподдерживаемым.  Код         private static void DefineAcceptingStates(Dictionary<State, HashSet<State>> dStates)         {             foreach (var kvp in dStates)             {                 foreach (State state in kvp.Value)                 {                     if (state.IsAccepting)                     {                         kvp.Key.IsAccepting = true;                         break;                     }                 }             }         } Код         private static void DefineAcceptingStates(Dictionary<State, HashSet<State>> dStates)         {             foreach (KeyValuePair<State, HashSet<State>> kvp in dStates)             {                 foreach (State state in kvp.Value)                 {                     if (state.IsAccepting)                     {                         kvp.Key.IsAccepting = true;                         break;                     }                 }             }         }

Автор: qweqwe 29.4.2010, 05:22

neutrino, вывод типов <> нестрогой типизации

Автор: Sentox 30.5.2012, 11:30

k0rvin,  Цитата ты не прав, это нифига не строгая типизация, при строгой === должно выбрасывать исключение на этапе компиляции при статической или в рантайме при динамической типизации Это один из способов типизации, да же мануал по этому говорит что проверка происходит на тип. Так же в PHP есть is_... int,string,array и instanceof что позволяет вручную делать проверку на типы.

Автор: k0rvin 30.5.2012, 13:53

Цитата(Sentox @ 30.5.2012,  11:30) Это один из способов типизации, да же мануал по этому говорит что проверка происходит на тип. Так же в PHP есть is_... int,string,array и instanceof что позволяет вручную делать проверку на типы. Конечно спасибо, капитан, но что ты этим хотел сказать?

Автор: Sentox 30.5.2012, 14:11

Цитата(k0rvin @ 30.5.2012,  13:53) Цитата(Sentox @ 30.5.2012,  11:30) Это один из способов типизации, да же мануал по этому говорит что проверка происходит на тип. Так же в PHP есть is_... int,string,array и instanceof что позволяет вручную делать проверку на типы. Конечно спасибо, капитан, но что ты этим хотел сказать? Пожалуйста. Сказать хотел что оператор эквивалента проверяет и типы значений, что само по себе говорит о строгости типизации  именно этого оператора, потому что кто то говорил Цитата ты не прав, это нифига не строгая типизация, при строгой === должно выбрасывать исключение на этапе компиляции при статической или в рантайме при динамической типизации .  И почему в обязательном порядке должно быть именно так Цитата должно выбрасывать исключение на этапе компиляции при статической или в рантайме при динамической типизации Всё остально привёл просто в информативном поле.

Автор: Logo 31.5.2012, 01:55

Хороший принцип нестрогой типизации есть в perl/perl6(все еще разрабатываемом) Там в для базовых типов используется свой тип оператора. Таким образом происходит приведение типов, и программист всегда явно указывает, что он имел ввиду. Так, операции с числами/строками в perl  Код +    .    # сложение/конкатенация <=>  cmp  # сравнение ==   eq   # равно (equal) >    gt   # больше (greater to) >=   ge   # больше или равно (greater or equal) в perl5 из коробки вообще нет способов определить, является ли переменная строкой, или числом, да и это в подавляющем большинстве случаев и не нужно, т.к. операция определяется оператором. в perl6 пошли еще дальше, теперь многие операторы, допускающие двойное использование, начинаются с соответствующего символа. + числовой контекст ~ строковый контекст (~ теперь оператор конкатенации) ! логический контекст так, +| побитовое или для чисел, а ~| побитовое или для строк В результате операторов в perl 6 довольно много http://glyphic.s3.amazonaws.com/ozone/mark/periodic/Periodic%20Table%20of%20the%20Operators%20A4%20300dpi.jpg

Автор: k0rvin 31.5.2012, 07:52

Цитата(Sentox @ 30.5.2012,  14:11) Сказать хотел что оператор эквивалента проверяет и типы значений, что само по себе говорит о строгости типизации  именно этого оператора. Нет, не говорит. Добавлено через 1 минуту и 19 секунд Цитата(Sentox @ 30.5.2012,  14:11) И почему в обязательном порядке должно быть именно так Потому что строгая типизация не разрешает неявное приведение типов.

Автор: Nikolja 1.7.2012, 12:02

проголосовал за строгую типизацию

Автор: Karadul 24.7.2012, 06:16

Цитата(Logo @  10.2.2010,  12:00 ) Можно пример подобных ошибок? В питоне Код "s" + 1 Написал по привычке из явы. Ошибка выяснилась у клиента, который запустил прогу с другими параметрами. Цитата(MAKCim @  10.2.2010,  13:42 ) юзайте аннотации и декораторы для проверки типов Это только в тройке? Мое имхо: для маленьких программ лучше динамическая типизация (меньше мозги себе паришь), для больших - статическая (поддержка ide на порядки лучше, не начинает мутить от одной мысли сделать какой-то глобальный рефакторинг). Edit: плохо прочитал заголовок темы. Конечно же строгая, перл и неявные преобразования str<->unicode в питоне двойке не нужны.

Автор: Karadul 24.7.2012, 06:38

Цитата(nerezus @  26.4.2010,  07:09 ) может гвидо разрешит питонистам что-то типа того же, что есть в пхп для этого.  Когда разрешит - тогда и поговорим. Сейчас этого нету. Разрешил, но никто этим не пользуется. Срач http://python.su/forum/post/87539/.

Автор: ТарасАтавин 16.9.2013, 09:03

Цитата(Logo @  10.2.2010,  10:18 ) Что лучше? Какие преимущества у одной перед другой?  В процедурной и алгоритмической парадигме лучше строгая явная, так как типы любых величин однозначно вытекают из задачи, а всякие приведения вроде округления действительного и присоединения к целому нулевой дробной части или не нужны вовсе, или чётко прописаны в алгоритме решения конкретной задачи, в объектно-ориентированной - смешанная: не строгая не явная для родственных классов и строгая явная для остальных, так как объект может быть экземпляром нескольких классов одновременно. Например амфибия - это автомобиль, или судно? А гидроплан - катер, или самолёт? А гигантский гидроэкраноплан Каспийский Монстр - самолёт, обычный корабль, или корабль на воздушной подушке? Здесь неясностей столько, что заранее определить классы всех объектов не всегда возможно, а привидения родственных классов предусмотреть не возможно почти ни когда.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)