JS и его "недостатки"

Цитата MyNameIsIgor @ 22.02.12, 05:54

В данном случае это именно с ней и связано. Грубо говоря, в джаваскрипте == позволяет неявное приведение типов, а === не позволяет.

Так а что мешает нам написать метод?

Цитата MyNameIsIgor @ 22.02.12, 05:54

Я ведь даже код показал. Как это связано с джавовским сравнением ссылок и методом equalTo? Или вы покажете полный аналог на джаве моего примера на джаваскрипте?

Искаробки нет метода, эквивалентного JS(==), но мы можем его написать:

package ru.sources;
 
class Weak {
 
    private final Object value;
 
    public Weak (Object value) {
        this.value = value;
    }
 
    private String toString (Object x) {
        return (x instanceof String) ? (String) x : x.toString();
    }
 
    public final String toString () {
        return toString(value);
    }
    
    public final boolean equals (Object other) {
        String s = toString(value);
        String t = toString(other);
        return s.equals(t);
    }
 
    public static Weak toWeak (Object x) {
        return (x instanceof Weak) ? (Weak) x : new Weak(x);
    }
}
 
public class WeakTyping {
 
    public static boolean isEqual (Object x, Object y) {
        return Weak.toWeak(x).equals(Weak.toWeak(y));
    }
    
    public static void main (String[] args) {
        Weak a = new Weak("1");
        Weak b = new Weak(1);
 
        System.out.println(a == b);
        System.out.println(a.equals(b));
 
        System.out.println(isEqual( a,  b));
        System.out.println(isEqual( a,  1));
        System.out.println(isEqual("1", b));
        System.out.println(isEqual("1", 1));
    }
}

false
true
true
true
true
true

И юзать где, и как заблагорассудится.

Сообщение отредактировано: korvin - 22.02.12, 07:30

Цитата fatalist @ 22.02.12, 07:11

Нет, ты приведи пример, почему это тебе неудобно...

Тут вроде уже были примеры. Так сложно привести?
Разве тебе не кажется, что правильно так:

>>> print(a)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    print(a)
NameError: name 'a' is not defined

Цитата Астарот @ 22.02.12, 07:29

Вообще есть мнение, что нужно забыть о == и использовать ===, но это только мнение.

Т.е. всё же есть среди джавасркипт-прогеров те, кто врубается в ущербность слабой типизация? Должен признать - яфшоке.

Цитата korvin @ 22.02.12, 07:29

Так а что мешает нам написать метод?

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

Цитата korvin @ 22.02.12, 07:29

Искаробки нет метода

Искаропки нет слабой типизации, а не метода. Соответственно, нет необходимости в костыле-подпорке ===

Цитата D_KEY @ 22.02.12, 07:30

Цитата fatalist @ 22.02.12, 07:11

Нет, ты приведи пример, почему это тебе неудобно...

Тут вроде уже были примеры. Так сложно привести?
Разве тебе не кажется, что правильно так:

>>> print(a)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    print(a)
NameError: name 'a' is not defined

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

Добавлено 22.02.12, 07:36

Цитата MyNameIsIgor @ 22.02.12, 07:34

Т.е. всё же есть среди джавасркипт-прогеров те, кто врубается в ущербность слабой типизация? Должен признать - яфшоке.

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

Цитата Астарот @ 22.02.12, 07:34

Сколько открытий чудных тебя ждет, если ты таки признаешь за остальными людьми право на собственное мнение

Да я признаю это право. Только "если мнение расходится с мои, то оно неправильное" ©

korvin, а я тут на интересную темку на лоре наткнулся. Где некий korvin_ с вашим аватаром пинает JS в лице archimag'а за слабую типизацию

Сообщение отредактировано: MyNameIsIgor - 22.02.12, 07:39

На радость MyNameIsIgor:

Цитата

Избегайте неявного приведения типов
При сравнивании переменных интерпретатор JavaScript неявно
выполняет приведение типов переменных. Именно поэтому такие операции
сравнения, как false == Оили"" == 0, возвращают true.
Чтобы избежать путаницы, вызванной неявным приведением типов,
всегда используйте операторы === и !==, которые сравнивают и
значения, и типы выражений, участвующих в операции:

var zero = 0;
if (zero === false) {
// тело этой инструкции не будет выполнено,
// потому что zero - это 0, а не false
}
// антишаблон
if (zero == false) {
// тело этой инструкции будет выполнено

Существует другая точка зрения, согласно которой в некоторых
ситуациях, когда достаточно использовать оператор ==, оператор === может
оказаться избыточным. Например, когда вы используете метод typeof,
вы знаете, что он возвращает строку, поэтому в данном случае нет
смысла использовать более строгий оператор сравнения. Однако JSLint
требует использовать строгие версии операторов сравнения - они придают
непротиворечивость программному коду и упрощают его чтение. (Не
приходится думать: «данный оператор == использован намеренно или
это упущение программиста?»)

(с)Stoyan Stefanov

Сообщение отредактировано: Астарот - 22.02.12, 07:40

Цитата MyNameIsIgor @ 22.02.12, 07:34

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

Вообще-то в моем примере WeakTyping.isEqual работает для всех типов и для всех сочетаний типов.

Цитата MyNameIsIgor @ 22.02.12, 07:34

Искаропки нет слабой типизации, а не метода. Соответственно, нет необходимости в костыле-подпорке ===

Э-э-э... вообще-то Java(equals) == JS(===). Точнее даже: поведение Java(equals) не определено, а поведение Java(==) далеко не всегда то, что нужно, то, ИМХО, тут в строгой статической Джаве только больше причин для путаницы, чем в JS, где поведение (==) и (===) четко определено.

И да, динамическое субтипирование (наследование) ослабляет типизацию =)

Сообщение отредактировано: korvin - 22.02.12, 07:49

Цитата korvin @ 22.02.12, 07:44

Вообще-то в моем примере WeakTyping.isEqual работает для всех типов и для всех сочетаний типов.

Вам действительно надо объяснять, что такое слабая типизация? Или вам метода достаточно?

Цитата korvin @ 22.02.12, 07:44

Точнее, даже поведение Java(equals) не определено, а поведение Java(==) далеко не всегда то, что нужно

ЕМНИП, в джаве == сравнивает ссылки на объекты. А поведение equal (или как там метод зовётся?) поределяется пользователем. Возникающую путаницу можно пообсуждать, но, гля, при чём тут слабая типизация?

Цитата MyNameIsIgor @ 22.02.12, 07:39

korvin, а я тут на интересную темку на лоре наткнулся. Где некий korvin_ с вашим аватаром пинает JS в лице archimag'а за слабую типизацию

Странно, тема старая, специально искал темы про JS? =) Да, пинал, хотя "пинал" не совсем правильное слово, у нго опыт применения JS значительно больше моего.

ЕМНИП, там был спор о JS, как языке общего назначения, а веб затрагивался в несколько ином ключе (http, ftp и прочий зоопарк протоколов vs 9p/Styx).

Цитата Астарот @ 22.02.12, 07:34

Цитата D_KEY @ 22.02.12, 07:30

Цитата fatalist @ 22.02.12, 07:11

Нет, ты приведи пример, почему это тебе неудобно...

Тут вроде уже были примеры. Так сложно привести?
Разве тебе не кажется, что правильно так:

>>> print(a)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    print(a)
NameError: name 'a' is not defined

Тебя спрашивают "почему неудобно", а ты отвечаешь "кажется правильно так"

Я не знаю, как объяснить, что ошибки нужно отлавливать и исправлять, а не пропускать
Потому и спрашиваю, может быть есть ситуации, в которых данная особенность не будет являться ошибкой?

Сообщение отредактировано: D_KEY - 22.02.12, 07:50

Цитата D_KEY @ 22.02.12, 07:30

Разве тебе не кажется, что правильно так:

Если судить по C/C++, то да...
А если JS, то нет...
Я вообще как-то вот не привык судить язык... Я привык им пользоваться со всеми его особенностями... может поэтому я и не вижу минусов? потому что не задумываюсь "как правильно" или "как должно быть", а просто использую то, что есть...

Добавлено 22.02.12, 07:53

Цитата D_KEY @ 22.02.12, 07:50

Потому и спрашиваю, может быть есть ситуации, в которых данная особенность не будет являться ошибкой?

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

Цитата MyNameIsIgor @ 22.02.12, 07:49

Вам действительно надо объяснять, что такое слабая типизация? Или вам метода достаточно?

Извольте, ибо я не вижу, почему мой метод isEqual нельзя назвать слаботипизированным.

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

Цитата D_KEY @ 22.02.12, 07:50

Я не знаю, как объяснить, что ошибки нужно отлавливать и исправлять, а не пропускать

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

Цитата D_KEY @ 22.02.12, 07:50

Потому и спрашиваю, может быть есть ситуации, в которых данная особенность не будет являться ошибкой?

А тебя в который раз спрашивают чем тебе эта "ошибка" помешала, а в ответ "ну, разве это не ошибка?"

Цитата korvin @ 22.02.12, 07:54

Извольте, ибо я не вижу, почему мой метод isEqual нельзя назвать слаботипизированным.

Можно. На основании этого метода нельзя джаву назвать слаботипизированной. Или мы используем правило "используйте ===, потому что == неявной приводит типы", или правило "в этом модуле я рекомендую пользовать чудо-метод isEqual, потому что [подставить по вкусу]". Это разница между плохо спроектированным языком и "я тут метод на коленке написал".

Цитата korvin @ 22.02.12, 07:54

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

Угу, а микроскоп позволяет свести к нулю полезность молотка. Но до этого ещё додуматься извращённым мозгом надо. Это встретит как минимум неприятие в среде коллег/сообщества.

Сообщение отредактировано: MyNameIsIgor - 22.02.12, 07:59

Цитата Астарот @ 22.02.12, 07:55

Фактически вся твоя аргументация сводится к "я привык считать что это ошибка, от этого и оттолкнемся".

Астя, есть общие принципы проектирования языков программирования. Вот в вики например про строгую типизацию статья:
http://en.wikipedia.org/wiki/Strong_typing

И некоторые особенности сильной типизации я считаю преимуществом, например: "Strong guarantees about the run-time behavior of a program"