плюсы и минусы для неявного преобразования в динамическом языке?

Question

Я действительно не использую динамические языки / языки сценариев. Так что я не знаю недостатков, хороших частей и т. Д. Во время разговора с кем-то он упомянул, что python может неявно преобразовать объект в то, что вы хотели, но даже не пытается.

Люди, кажется, любят питона. Так неявное ли преобразование в динамическом языке плохо? Это плохо? (он хотел) Каковы плюсы и минусы неявных преобразований в динамическом языке?

Answer 1

Плюсы:

• «Делает, что вы имеете в виду» в большинстве случаев.
• Это позволяет вам полу-свободно трактовать, скажем, строки как числа, и наоборот. Я немного использовал это в Perl для выполнения строковых операций над числами, которые в противном случае включали бы кучу неочевидной математики.

Минусы:

• Когда он терпит неудачу, он часто терпит неудачу таинственными способами. Например, начальные нули могут вызывать странные проблемы в языках, которые знают о восьмеричных числах. «00» - «07» будут работать нормально, но «08» и «09» сломаются.
• Иногда вы действительно хотите хотите узнать тип. Пример: PHP и его привычка возвращать false в случае сбоя. Если strpos($a, $b) возвращает 0, то $ b было найдено в начале $ a; false означает, что он вообще не был найден. Но неявные преобразования делают сравнение 0 и false равным. (К счастью, PHP имеет оператор ===, чтобы смягчить это.)
• Преобразование занимает циклы процессора. Это немного, но если вам не нужна скрытая магия преобразования, зачем платить за это?

Answer 2

Мне нравится видеть это в аспекте варианта использования; Итак, мой ответ: это действительно зависит от того, что вы хотите сделать .
Если вы пишете веб-приложение, то это поможет вам писать более чистые коды (коды без большого количества вызовов функций и методов для простого преобразования типов), а в противном случае это потенциально может создать некоторые загадочные ошибки и в этой ситуации (веб-приложение) написание Более чистые и понятные коды помогают снизить затраты на разработку и изменения, и, таким образом, затраты на исправление этих потенциальных ошибок можно игнорировать.
Но если, например, вы пишете прошивку для критически важного оборудования (например, космического челнока), то любая потенциальная ошибка может стоить миллионы долларов, годы и годы времени и энергии, поэтому в этом случае было бы целесообразно терпеть боль написание некоторых функций и методов преобразования для защиты всей цели проекта.