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

Цитата D_KEY @ 24.02.12, 11:51

Это не параметры - это один параметр.

Формально да. (Астарот сказал, у меня лучше не получится)
Но фактически мы туда можем запихать кучу всяких ПАРАМЕТРОВ и работать с ними, а не с отдельными аргументами...

Добавлено 24.02.12, 12:03

Цитата D_KEY @ 24.02.12, 11:51

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

А еще можно третьим аргументом добавить приведение к float, а четвертым ввести округление полученного float до определенного количества знаков...
А можно вместо этого передать один объект с именованными настройками данной операции...

Цитата fatalist @ 24.02.12, 11:58

Но фактически мы туда можем запихать кучу всяких ПАРАМЕТРОВ и работать с ними

Что это меняет? Я в каком-нибиудь С "фактически" могу затереть кусок памяти произвольного объекта, но это не говорит о том, что типы и объекты не имеют смысла в С.

Цитата D_KEY @ 24.02.12, 12:03

Что это меняет? Я в каком-нибиудь С "фактически" могу затереть кусок памяти произвольного объекта, но это не говорит о том, что типы и объекты не имеют смысла в С.

Не понял

Цитата fatalist @ 24.02.12, 12:05

Цитата D_KEY @ 24.02.12, 12:03

Что это меняет? Я в каком-нибиудь С "фактически" могу затереть кусок памяти произвольного объекта, но это не говорит о том, что типы и объекты не имеют смысла в С.

Не понял

То, что ты можешь обойти некий механизм, не означает, что механизм не нужен.

Цитата D_KEY @ 24.02.12, 12:07

То, что ты можешь обойти некий механизм, не означает, что механизм не нужен.

ну нужность я пока не ощутил...

korvin, на самом деле List я тебе для иллюстрации привел, а так можно воспользоваться стандартными парами:

make_pair(1, make_pair("two", make_pair(false, nil)));

Добавлено 24.02.12, 12:21

Цитата fatalist @ 24.02.12, 12:12

Цитата D_KEY @ 24.02.12, 12:07

То, что ты можешь обойти некий механизм, не означает, что механизм не нужен.

ну нужность я пока не ощутил...

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

Цитата D_KEY @ 24.02.12, 12:07

То, что ты можешь обойти некий механизм, не означает, что механизм не нужен.

Так никто в JS таким образом ничего и не обходит! Так делается из соображений удобства (если параметров например должно быть больше пяти, проще уже передать объект и именованными свойствами), а не для того ненужного механизма, которого к счастью нет

Добавлено 24.02.12, 12:24

Цитата D_KEY @ 24.02.12, 12:12

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

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

Сообщение отредактировано: fatalist - 24.02.12, 12:24

Цитата D_KEY @ 24.02.12, 12:12

korvin, на самом деле List я тебе для иллюстрации привел, а так можно воспользоваться стандартными парами:

make_pair(1, make_pair("two", make_pair(false, nil)));

Можно. Теперь ограничь типы элементов этого паровоза, например классом Printable

class Printable {
    void print();
}

Цитата fatalist @ 24.02.12, 12:21

Однако хочу сказать, что когда я перестал баловаться с C++ и стал писать на JS, я почувствовал довольно сильное облегчение безо всех этих ограничений...

Да причем тут этот самый С++? Никто с ним js не сравнивает. В других динамических языках ты не вызовешь функцию с неверным числом параметров.
Даже в лиспе:

>(defun f (x) (* x x))
F
 
>(f 10)
 
100
 
>(f 1 1)
 
 
Error: F [or a callee] requires less than two arguments.

Я вот думаю, есть ли еще хоть один динамический язык с таким же поведением, как js?..

Добавлено 24.02.12, 12:34

Цитата korvin @ 24.02.12, 12:29

Теперь ограничь типы элементов этого паровоза, например классом Printable

class Printable {
    void print();
}

Это не имеет смысла, работать ты будешь с такими списками только через шаблоны и все итак будет работать для всех типов, у которых есть метод print(), и не будет работать, если метода print() нет. Могу сделать ошибку времени компиляции, если тип не наследует от Printable, но это лишние(ИМХО).

Цитата D_KEY @ 24.02.12, 12:30

Да причем тут этот самый С++? Никто с ним js не сравнивает. В других динамических языках ты не вызовешь функцию с неверным числом параметров.

Значит js удобнее других динамических языков

Цитата D_KEY @ 24.02.12, 12:30

Это не имеет смысла, работать ты будешь с такими списками только через шаблоны и все итак будет работать для всех типов, у которых есть метод print(), и не будет работать, если метода print() нет. Могу сделать ошибку времени компиляции, если тип не наследует от Printable, но это лишние(ИМХО).

Мне не нужна ошибка в месте использования, мне нужна ошибка в месте определения (точнее в месте вызова make_pair с типами, не поддерживающими Printable) =)

Цитата korvin @ 24.02.12, 12:48

Мне не нужна ошибка в месте использования, мне нужна ошибка в месте определения (точнее в месте вызова make_pair с типами, не поддерживающими Printable) =)

"Не поддерживающими" Printable - это как? Если наследование - то можно, но лишнее, на мой взгляд. Если тебе нужна проверка без лишних манипуляций(вроде твоих instance или наследования), то нужны концепты.

Добавлено 24.02.12, 12:54
Собственно, мой вчерашний пример только через пары:

struct Nil_t {} nil;
 
void format_print(const char *s, Nil_t end = nil)
{
    std::cout << s;
}
 
template<typename T, typename H>
void format_print(const char* s, pair<T, H> lst)
{
   while (s && *s) {
      if (*s=='%' && *(s+1) !='%') {
         std::cout << lst.first;
         return format_print(++s, lst.second);
      }
      std::cout << *s++;
   }
}

format_print("a = %, b = %, c = %\n", make_pair(1, make_pair("aaa", make_pair(false, nil))));

Добавлено 24.02.12, 12:56
Там правда бага с %%, но фиг с ним

Сообщение отредактировано: D_KEY - 24.02.12, 12:56

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

Цитата D_KEY @ 24.02.12, 12:52

"Не поддерживающими" Printable - это как? Если наследование - то можно, но лишнее, на мой взгляд. Если тебе нужна проверка без лишних манипуляций(вроде твоих instance или наследования), то нужны концепты.

Ну вот смотри

Например пишу я библиотечный модуль

module GList (
    GList,
    GNil,
    Print(..),
    nil,
    (<+>),
    (<%>),
    list,
    test
) where
 
import Control.Monad
 
data GList a b = GCons a b | GNil
type GNil = GList () ()
 
nil :: GNil
nil =  GNil
 
class Print a where
    prn :: a -> IO ()
 
instance (Print a, Print b) => Print (GList a b) where
    prn  GNil        = return ()
    prn (GCons x xs) = do
        prn x
        putStrLn ""
        prn xs
 
instance Print Int where
    prn x = putStr $ show x
 
instance Print Bool where
    prn x = putStr $ show x
 
instance Print () where
    prn x = putStr $ show x
 
infixr <+>
(<+>) :: a -> GList b c -> GList a (GList b c)
x <+> xs = GCons x xs
 
infixr <%>
(<%>) :: (Print a, Print b, Print c) => a -> GList b c -> GList a (GList b c)
(<%>) = (<+>)
 
x :: Integer
x = 1
list = x <+> False <+> nil
 
test :: (Print a, Print b) => GList a b -> IO ()
test = prn

и в определении list использовал обычную функцию (<+>), не ограничивающую тип классом Print. Никаких ошибок компиляции при этом, что вполне логично. Однако при попытке применить test к list у кого-то возникнет ошибка компиляции. Неприятно. Хорошо еще, что можно доопределить instance Print Integer в любом другом месте, а если было б нельзя? А используй я вместо (<+>) более строгую (<%>), мне бы выдало ошибку уже при компиляции моего модуля и я бы сам на месте решил, что мне делать с моим определением list

Сообщение отредактировано: korvin - 24.02.12, 13:20

korvin, не понял к чему это
Суть в том, что без переменного числа аргументов я смогу обойтись почти таким же способом, который ты показал на псевдокоде. Вот только ...-шаблонны из нового стандарта удобнее
А относительно ограничений на параметры шаблона(нормальных, а не требование реализации интерфейса) - нужны концепты. Их (пока) в С++ нет.
В бусте есть костыли на эту тему

Добавлено 24.02.12, 13:43
korvin, вспомни вчерашний пример Игоря - стрелка Пирса(ну или штрих Шеффера) образует базис и через нее можно выразить любую другую булеву операцию. Но это не повод отказываться от систем с другими(и более громоздкими) базисами Особенно, если речь идет не о теории, а о практике - да, элементы или-не/и-не могут выразить любую логическую схему, но это не всегда удобно и выгодно

Добавлено 24.02.12, 14:20

Цитата korvin @ 24.02.12, 09:20

Я же говорил, что произвольные параметры не нужны.

Кстати, в том шаблонном коде с ... и не будет функции с произвольным количеством параметров. Этот шаблон будет генерировать функцию с нужным числом и типами аргументов.