Модераторы: LSD

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> строгая vs не строгая типизация, что лучше 
:(
    Опции темы
 
Какая типизация лучше?
не строгая [ 15 ]  [23.44%]
строгая [ 49 ]  [76.56%]
Всего проголосовавших: 64
В этом опросе возможен один вариант ответа
Гости не могут голосовать 
GrayCardinal
Дата 10.2.2010, 13:46 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Фигасе
****


Профиль
Группа: Завсегдатай
Сообщений: 3039
Регистрация: 9.11.2003

Репутация: нет
Всего: 58



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

Добавлено через 21 секунду
(не голосовал)


--------------------
PM MAIL WWW   Вверх
Logo
Дата 10.2.2010, 23:21 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 694
Регистрация: 22.7.2008

Репутация: нет
Всего: 10



Цитата(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 там всё же разные вещи. Даже оператор === говорит не эквивалентны


Руби проверил, он тут себя ведет тоже не лучшим образом. И ошибку не возвращает, и сравнение не проводит. Питон, кстати, так же работает.



PM MAIL   Вверх
Akella
Дата 13.2.2010, 10:44 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Творец
****


Профиль
Группа: Модератор
Сообщений: 18485
Регистрация: 14.5.2003
Где: Корусант

Репутация: 1
Всего: 329



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

Это сообщение отредактировал(а) Akella - 13.2.2010, 10:45
PM MAIL   Вверх
segrey
Дата 13.2.2010, 12:57 (ссылка)    | (голосов:2) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 54
Регистрация: 26.12.2006

Репутация: нет
Всего: нет



Честно говоря, в php не хватает что - то вроде такого:
Код

function __construct (array $arg) {}
function __construct (MyCollection $arg) {}
function __construct (int a, int b, int c) {}


чтобы как в С++, в зависимости от того какие аргументы пришли - та функция и вызвалась. Можно конечно условие в конструкторе поставить, но это не кошерно  smile 
PM MAIL   Вверх
UniBomb
Дата 19.2.2010, 12:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок
***
Награды: 1



Профиль
Группа: Участник Клуба
Сообщений: 1754
Регистрация: 24.10.2006
Где: Санкт-Петербург

Репутация: нет
Всего: 97



Цитата(Logo @  11.2.2010,  00:21 Найти цитируемый пост)
Руби проверил, он тут себя ведет тоже не лучшим образом.

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


--------------------
PM MAIL ICQ Skype   Вверх
mrbrooks
Дата 19.2.2010, 12:33 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


трололомен
****


Профиль
Группа: Завсегдатай
Сообщений: 4259
Регистрация: 4.10.2006
Где: Дол Гулдур

Репутация: нет
Всего: 306



строгая, ибо это не только гламурно, но и кошерно.
PM MAIL   Вверх
Logo
Дата 20.2.2010, 12:32 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 694
Регистрация: 22.7.2008

Репутация: нет
Всего: 10



Цитата

Ну почему же - в ruby есть оператор сравнения <=>, который будет равен nil если сравниваемые величины не подлежат сравнению (как в данном случае). 

Но nil и 0 в контексте if одно и тоже ведь.
И вообще речь не о том. Он не выдает ошибки при сравнении "1" и 1. Что бы, как Java, избавить от потенциальных ошибок. Вместо этого продолжает выполнять программу. Однако и сравнение он тоже не производит.  Что бы, как Perl, что бы не заботится типах.
Таким образом совмещая недостатки того и другогоsmile

PM MAIL   Вверх
fixxer
Дата 20.2.2010, 16:15 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 672
Регистрация: 14.9.2006
Где: Саратов, Россия

Репутация: нет
Всего: 27



Цитата(Logo @ 20.2.2010,  12:32)
Цитата

Ну почему же - в ruby есть оператор сравнения <=>, который будет равен nil если сравниваемые величины не подлежат сравнению (как в данном случае). 

Но nil и 0 в контексте if одно и тоже ведь.
И вообще речь не о том. Он не выдает ошибки при сравнении "1" и 1. Что бы, как Java, избавить от потенциальных ошибок. Вместо этого продолжает выполнять программу. Однако и сравнение он тоже не производит.  Что бы, как Perl, что бы не заботится типах.
Таким образом совмещая недостатки того и другогоsmile

Таким образом не стоит забывать, что в Ruby все объект и == это метод. Таким образом это можно сравнивать с методом equals в Java, а не с == в Java.


--------------------
user posted image
PM MAIL ICQ   Вверх
k0rvin
Дата 12.3.2010, 21:27 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 442
Регистрация: 24.1.2010

Репутация: 1
Всего: 5



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

я надеюсь Вы не про Variant из Делфи (точнее COM/OLE, я таких тонкостей не знаю)?


--------------------
“Object-oriented design is the roman numerals of computing.” — Rob Pike
All software sucks
PM MAIL   Вверх
A5uKa
Дата 27.3.2010, 23:10 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


TЋ♥s F1rȜ iƧ BurȠiƞg
***


Профиль
Группа: Awaiting Authorisation
Сообщений: 1928
Регистрация: 30.8.2008

Репутация: 1
Всего: 16



строгая с возможностью не строгой  smile 
PM   Вверх
Akella
Дата 23.4.2010, 14:47 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Творец
****


Профиль
Группа: Модератор
Сообщений: 18485
Регистрация: 14.5.2003
Где: Корусант

Репутация: 1
Всего: 329



k0rvin, когда я говорил о вариантном типе, то имел ввиду именно Variant. Но есть ещё OleVariant.
PM MAIL   Вверх
k0rvin
Дата 23.4.2010, 18:10 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 442
Регистрация: 24.1.2010

Репутация: 1
Всего: 5



Цитата(Akella @ 23.4.2010,  14:47)
k0rvin, когда я говорил о вариантном типе, то имел ввиду именно Variant. Но есть ещё OleVariant.

но это же ужасный костыль и имеет отношение не к строгой/нестрогой типизации, а к статической/динамической =)


--------------------
“Object-oriented design is the roman numerals of computing.” — Rob Pike
All software sucks
PM MAIL   Вверх
qweqwe
Дата 23.4.2010, 18:17 (ссылка)    | (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 55
Регистрация: 31.1.2007

Репутация: нет
Всего: 0



Цитата(mrbrooks @  19.2.2010,  12:33 Найти цитируемый пост)
строгая, ибо это не только гламурно, но и кошерно.

даже не знаю, за что тебя заминусовали, бро

сразу видно - форум быдлокодеров, но не гламурных!

Добавлено через 37 секунд
только строгая, абсолютно всегда и везде smile 
PM MAIL   Вверх
nerezus
Дата 23.4.2010, 22:42 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Вселенский отказник
****


Профиль
Группа: Участник
Сообщений: 3330
Регистрация: 15.6.2005

Репутация: 13
Всего: 43



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


--------------------
Сообщество художников Artsociety.ru
PM MAIL WWW   Вверх
SneG0K
Дата 23.4.2010, 23:29 (ссылка)  | (голосов:5) Загрузка ... Загрузка ... Быстрая цитата Цитата


Max Mara
***


Профиль
Группа: Завсегдатай
Сообщений: 1887
Регистрация: 1.12.2007
Где: Wis Dells

Репутация: нет
Всего: 54



Цитата(mrbrooks @  19.2.2010,  11:33 Найти цитируемый пост)
строгая, ибо это не только гламурно, но и кошерно. 

Ага, кошерно как еврейское рождество.

В зависимости от задачи. При строгой типизации производительность выше, вроде.
PM WWW Skype   Вверх
Ответ в темуСоздание новой темы Создание опроса
Правила ведения Религиозных войн
Smartov
1. Уважайте собеседника
2. Собеседник != враг
3. Старайтесь воздерживаться от тем вида "Windows Rulez" или "Linux Rulez"

С уважением, Smartov.

 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Религиозные войны | Следующая тема »


 




[ Время генерации скрипта: 0.1764 ]   [ Использовано запросов: 24 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.