Походу ты опять просрал смысл: http://ideone.com/TzNsY2

spidermonkey - это не стандартный движок. На него в разработке не ориентируются. В в node chrome firefox все работает. Дальше не проверял

Походу ты опять просрал смысл: http://ideone.com/TzNsY2

откуда там pop взялся идиот? или ты троллишь меня?

Долго молчать будем?

Обосрался хомячек, долго отмазы лепил, прикинулся троллем, но в итоге слился

http://ideone.com/4CpUCX Не в спайдерманки тоже все работает.

Ну надоже хомячишко, доже не поленился ссылки за собой подчистить, где обосрался. Репутация то она дороже, да.

Може он изначальна пытался «типа троллить»?

Я вообще не понял, чего он хотел сказать. Какая-то ссылка на строчку кода и баттхерт следом.

«Дети, что хотел сказать автор в этом романе вбросе?»

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

откуда там pop взялся идиот?

Оттуда же, куда исчезают запятые в твоих постах. Подумай над этим.

И еще над этим, например. Это к слову о гибкости.

Но я смотрю, тебя и так бомбануло нехило, можно поселок начинать отстраивать.

В твоем коде второй объект работает совершенно независимо от первого. Ты внутри него переопределил x. Что ты этим хотел сказать? Как это относиться к делу?

И еще над этим, например. Это к слову о гибкости.

Ты хочешь сказать что программирование в js непредсказуемо? Там нет классов? Но тогда зачем ты влепил мой код в начале? Какая связь? Я не могу понять твою логику!

Оттуда же, куда исчезают запятые в твоих постах. Подумай над этим.

Ты что вручную код вбивал чтоле? Нафига?

А, сейчас дошло, ты хочешь сказать что наш «объект» работает не так как нативный. Ну так никто и не говорил что он полностью идентичен нативному. Там много чего еще нет. Это был просто наколеночный пример «для понимания принципа»

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

Насколько я понял, анонимус имел в виду, что для создания даже такого примитивного «объекта», если бы не было этой фичи, пришлось бы писать портянку вроде этой:

var ob=function(arg){
   var prop=1;
   var meth=function(x){return x+x}
   var dispatcher=function(arg){
       if(arg==="prop") return prop;
       if(arg==="meth") return meth;
   }
   return dispatcher(arg)
}

console.log(ob("prop"))  // 1
console.log(ob("meth"))  // [Function]

//А вызов пришлось делать как-то так:

console.log(ob("meth")(ob("prop")))

Поэтому выгрыш в выразительности как-бы, действительно есть.

function(arg){var a=1; eval(arg)} //--> 1

ШТА? Почему какой-то внешний объект должен знать об имени переменной внутри функции?

За eval вообще расстреливать надо...

tst=function(arg){var a = 1; return eval(arg)};
console.log(tst("a"))

Там дальше есть пояснения

Да, так все щас думают. Это мейнстрим

Вот как раз про это я и подредактировал свой пост.

1. Какой смысл в объекте (функции tst), который сломается, если скормить ему что-то кроме «a»?
http://ideone.com/zvGxr2

2. Выхватить «нечто» с помощью eval() это конечно здорово, но в чём цимус $username?

Забегая наперёд: и не надо мне объяснять суть замыканий.

не надо мне объяснять суть замыканий

Причем тут суть замыканий В этом объекте вообще смысла нет. Это игрушечный пример который показывает выразительные возможности языка.

Это игрушечный пример который показывает выразительные возможности языка.

Про «there's more than one way to do it» слышали, знаем. Только ничего поразительного в том примере нет. Смысл такой «выразительности»?

Вот альтернативный вариант без этой фичи (new_1 написал парой постов выше):

var ob=function(arg){
   var prop=1;
   var meth=function(x){return x+x}
   var dispatcher=function(arg){
       if(arg==="prop") return prop;
       if(arg==="meth") return meth;
   }
   return dispatcher(arg)
}

console.log(ob("prop"))  // 1
console.log(ob("meth"))  // [Function]

//А вызов пришлось делать как-то так:

console.log(ob("meth")(ob("prop")))

Let's do this traditional way

var ob = {
    a: 1,
    meth: function (x) { return x + x; }
};
console.log( ob.meth(ob.a) );

Ну или если «красиво»:

Cls = function (a) { this.a = a; }
Cls.prototype.meth = function (x) { return x + x; }
var ob = new Cls(1);
console.log(ob.meth(ob.a));

По твоей логике получается, что фекспры круче макросов но они не кошерны потому что макросы не «работают» внутри них.

В том посте речь шла не о «лучше», а о том, что если в языке есть фекспры, то нету макросов. То, что макросы лучше - это отдельная тема.

В Io любая скобка потенциально недо-«макрос», потому что получает свои аргументы в виде дерева «как есть» прямо в рантайме.

Ну это и есть ебучие фекспры. Тут ведь дело в чем - фекспры можно реализовать, если есть макросы, но не наоборот. Отсюда следствие - макросы строго выразительнее.

Ты не можешь понять, что это просто пример, я не говорю, что Прототипная система JS чем то плоха, как раз наоборт. Я говорю о том, что js настолько гибок, что если ты хочешь свою объектную систему, ты получишь ее легко.

фекспры можно реализовать

Как ты их реализуешь, если это по сути, функции, полноценные объекты, которые «can be applied, passed around, and debugged»

Как ты их реализуешь, если это по сути, функции, полноценные объекты, которые «can be applied, passed around, and debugged»

Очевидно, в виде функций, полноценных объектов, которые «can be applied, passed around, and debugged».

Макросы, кстати, тоже обычные функции «can be applied, passed around, and debugged».

ничего общего

В этом объекте вообще смысла нет.

выразительные возможности языка.

Выразительность такая выразительная.

Макросы, кстати, тоже обычные функции «can be applied, passed around, and debugged»

Я немножко представляю как работают макросы в scheme:

(define (a) 1)
(define (alpha) (a))
(alpha)             ;  1
(define (a) -1)
(alpha)             ; -1

(define-syntax b (syntax-rules () ((_) 2)))
(define (beta) (b))
(beta)              ;  2
(define-syntax b (syntax-rules () ((_) -2)))
(beta)              ;  2 still!

с необычными концепциями, альтернативам ООП.

Не совсем «язык», но, в общем, Flow-based programming. Это такие мега-юникс пайпы, где есть произвольное число потоков вместо 3 стандартных, и данные бинарные, а не текстовые. Можно рисовать диаграммы. Есть вот свежая реализация - NoFlo, для ноды.жс, мде...

Можно пример того, что пишется в этой штуке, но не пишется в параметрически полиморфной (+ад-хок, что есть синтаксический сахар без high-rank) лямбде?

Ну, вот задачка. Нужно сделать множества. Множество должно хранить в себе отсортированный список элементов произвольного типа; при этом, конечно, тип элементов должен быть одинаковый. Должны быть стандартные операции — empty, insert, isMember... ну, этого хватит. Кроме того, нужно уметь делать объединение двух множеств.

Единственное (кроме самих элементов множества), что мы имеем право использовать — это компаратор. Т.е., функцию сравнения двух элементов, позволяющую их сортировать.

А теперь сложный момент: компаратор для элементов одного и того же типа может быть разный. При этом объединение двух множеств должно делаться тогда и только тогда, когда не только типы элементов в них совпадают, но и компараторы.

Вот, как это примерно выглядит в OCaml:

type ordering = LT | EQ | GT
module type Ordered =
sig
  type t
  val cmp : t -> t -> ordering
end
module type SetFunctor =
  functor (T : Ordered) ->
    sig
      type t
      val empty : t
      val insert : T.t -> t -> t
      val is_member : T.t -> t -> bool
      val union : t -> t -> t
    end
module Set : SetFunctor =
  functor (T : Ordered) ->
    struct
      type t = ... (* some implementation *)
      let empty : t = ...
      let insert (x : T.t) (s : t) : t = ...
      let is_member (x : T.t) (s : t) = ...
      let union (s1 : t) (s2 : t) : t = ...
    end
module T1 : Ordered with type t = int
  = struct
    type t = int
    let cmp a b = if a > b then GT else if a < b then LT else EQ
  end
module T2 : Ordered with type t = int
  = struct
    type t = int
    let cmp a b = if a < b then GT else if a > b then LT else EQ
  end
module S1 = Set(T1)
module S2 = Set(T2)
let s1 = S1.empty
let s2 = S2.empty
(* let b = s1 = s2 *)

В Scala можно сделать то же самое с помощью path-dependent types. В Haskell98 это не делается. В Haskell с расширением RankNTypes можно вывернуться, используя вариант runST-трюка. В C++ можно вынести Set в шаблон и с его помощью нагенерить нужных типов — но скомпилировать его отдельно от S1 и S2 нельзя.

Ну, навскидку:

module type MT1 =
  sig
    type t
  end
module type MT2 =
  sig
    type t
    val f : t -> t
  end
let g m =
  let module I = (val m : MT1) in
  let module R =
    struct
      type t = I.t
      let f x = x
    end
  in (module R : MT2)

(module MT1) -> (module MT2)

Я говорю о том, что js настолько гибок, что если ты хочешь свою объектную систему, ты получишь ее легко.

Во-первых, ни разу не легко.

А во-вторых, да-да, js Тьюринг-толстый, и чо с того? Сейчас этот факт нейтрально воспринимается, а через пару лет это уже будет считаться недостатком языка.

Здесь я согласен. Дизайн ентерпрайз-языка ориентируется на среднестатистического кодера. Не исключено, что js вообще умрет через десять лет, или деградирует. Уже сейчас все признаки этого наблюдаются. Та же судьба что и у лиспов.

По моему lua и js имеют идентичную семантику, хотя луа я не знаю, смотрел просто.

Нет. ООП в lua делается посредством метатаблиц, когда же в js это извращения с функциями.
Метатаблицы намного проще и естественнее.

***

Ваша ушербная луа уже научилась с нормальными типами чисел работать хотя бы?

Смотря, что ты имеешь в виду под «нормальными типами чисел».

Неправильно представляешь. В module-level контексте и вариант с define и с define-syntax - одинаково некорректные записи, будет ошибка. В топ-левел контексте и то, и то одинаково корректно и будет работать.

В Scala можно сделать то же самое с помощью path-dependent types.

Да ну. Вообще 1в1 переписывается же.

В Haskell98 это не делается.

С чего вдруг? Пишем тайпкласс Ordered и тайпкласс SetFunctor (переписывается 1в1), при этом тип в Ordered боксим уникальным тагом на каждый компаратор. И будет работать 1в1, и.к. у нас для каждого компаратора свой тип (ну как и у тебя в окамле, собственно).

Понятно. Короче, это урезанные имплициты из скалы.

Вообще 1в1 переписывается же.

Покажи.

Пишем тайпкласс Ordered и тайпкласс SetFunctor

Угу. А ты в курсе, что даже Haskell98 позволяет иметь разные инстансы одного тайпкласса для одного и того же типа? И что встроенный Set (построенный как ты сказал) таким образом вполне можно превратить в тыкву?

Понятно. Короче, это урезанные имплициты из скалы.

Всё на свете — урезанные имплициты из скалы.

Нет, не все. Просто в данном случае модули окамла работают в точности так же, как тайпклассы, за исключением того, что в хаскеле передача исключительно неявна, а потому тайпкласс не является рантайм-значением. Если в ЯП можно сделать тайпкласс - то можно сделать рантайм-левел модулей в окамле, если можно передавать и неявно - можно сделать тайп-левел.

А ты в курсе, что даже Haskell98 позволяет иметь разные инстансы одного тайпкласса для одного и того же типа?

Чего? Может наоборот _не_ позволяет? Если позволяет - то все еще проще, не надо боксить тип в Ordered.

data Ordering = LT | EQ | GT

class Ordered t where 
    cmp :: t -> t -> Ordering

class (Ordered t) => SetFunctor t where
    insert :: ...
    isMember :: ...
    ...

data Foo a = Value a

instance (Ordered a) => SetFunctor a where
    ...

instance Ordered Foo Integer where
    ...

как-то так

Просто в данном случае модули окамла работают в точности так же, как тайпклассы

Опять-таки: нет. Модули существенно строже.

Чего?

Того.

При помощи orphan instances можно и не такое замутить. Просвещайся: http://stackoverflow.com/questions/12735274/breaking-data-set-integrity-witho... — важен не столько вопрос, сколько мой ответ. И, заодно, http://migmit.livejournal.com/48276.html — там эта проблема решена по-настоящему.

Если позволяет - то все еще проще

Нет, сложнее.

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

Опять-таки: нет. Модули существенно строже.

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

Того.

Но это же очевидная ошибка. Зачем рассматривать ошибочный код? Это надо в багзилу скидывать, если чекер пропускает.

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

Да с чего вдруг? С разными компараторами будут разные типы.