Mozilla Phones for Apps

Здорово! Работает. Но в интернетах пишут, что __proto__ — deprecated, так что не пойдёт :(

Ты сейчас не понимаешь пространств «класса» и объекта в js, потому не можешь осилить наследование, при этом мне питон не нужен, а тебе js нужен, и кто из нас буратино, скажи мне.

Так зачем всё мешаешь в одну кучу? Класс — определяет, как создаются объекты. Поэтому если хочешь изменить поведение _всех_ объектов этого класса — меняй класс. Где ты узрел нелогичность?

Я то всё прекрасно понимаю, просто приемлимого пути решения проблемы в js не существует. От тебе и гибкость прототипов во все поля.

Ну и ещё: не нужен тебе питон — не используй его на здоровье, но зачем тогда с умным видом рассуждать, какой он непутёвый?

но js без отладчика использовать абсолютно не готов

А я вообще не готов использовать js напрямую. Ни с отладчиком, ни без. Ужасный язык с невыносимым количеством «бордерплейта».

Кстати, а что мне юнит-тесты то, трейсбеки дадут в оттранслированном коде, и что с ними делать?

Зачем смотреть в оттранслированный код, если есть исходник?

Если же проблема заключается в оттранслированном коде, а не в вашем исходнике, то это проблема Coffeescript'a. В этом случае следует создать issue, чтобы проблему нашли, опять же, используя тесты.

Но со мной такого ни разу не случалось, всегда все транслируется корректно. Я даже sourcemaps еще не пробовал использовать по этой причине. special-k, пригодились?

Но в интернетах пишут, что __proto__ — deprecated

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

Где ты узрел нелогичность?

Смотри

Класс — определяет, как создаются объекты.

объекты реализуют свой функционал.

Как два этих назначения связаны - никак. Так какого лешего свойства класса и объекта - это одно и то же, непонятно.

Вот мне и интересно было, понятно что скриптовые языки там быстро появятся, а вот что с компилируемыми.

Как две эти функции связаны - никак. Так какого лешего свойства класса и объекта - это одно и то же, непонятно.

Ещё раз: почитай про MRO, мне не хочется рассказывать тебе про ООП.

ndk?

ты хотел написать JDK ? ))))

Питон при обращении к аттрибуту объекта если не находит его в самом объекте, ищет по аттрибутам класса (точнее цепочки наследования).

Так я ж говорю: тесты будут запускаться js-движком, соответственно, и трейсбеки будут давать в оттранслированном коде, и как дальше жить?

Дык, если a.x == undefined, то можно сказать, что св-ва то и нет?

Вообще-то свойство то и есть и имеет значение - undefined.

Или как тогда проверять? hasOwnProperty?

if («x» in a) ...

цитату

Источник, пожалуйста.

тогда с помощью Object.create будешь спокойно наследовать.

Object.create будет не наследовать, а копировать, эт не то.

Ну да, про in как-то не подумал.

Зачем смотреть в оттранслированный код, если есть исходник?

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

Мой недогадливый недоверчивый друг

var Plugin1 = function(){console.log('ia plugin')};
//классовые методы
Plugin1.metainformaciyayi = {}
Plugin1.metainformaciyayi.m1 = 'метаинформация1'
Plugin1.metainformaciyayi.m2 = 'метаинформация2'
//объектные методы
Plugin1.prototype.v1 = 1
Plugin1.prototype.v2 = 2

//наследуем поочередно

////1. сначала функцию конструктор (в js не существует понятия super)
var Plugin2 = function(){
  Plugin1.apply(this, arguments)
};

////2. затем наследуем метаинформацию
Plugin2.metainformaciyayi = Object.create(Plugin1.metainformaciyayi)

////3 прототип "объекта"
Plugin2.prototype = Object.create(Plugin1.prototype)

//проверяем наследуемость
Plugin1.metainformaciyayi.m3 = 'метаинформация3'
Plugin2.metainformaciyayi.m4 = 'метаинформация4'
console.log(Plugin2.metainformaciyayi.m3) //наследовалось
console.log(Plugin1.metainformaciyayi.m4) //пусто
console.log((new Plugin2).v1)

конечно.. -_- интерпретатор тыкает тебя носом в место ошибки и все сразу ясно.

интерпретатор тыкает тебя носом в место ошибки и все сразу ясно.

Ага, В фигню типа __ref64 undefined. И смотришь в гору генерированных исходников и медитируешь - а что же это может компилится в _ref64 чтобы понять, а что собственно undefined.

О, это уже что-то. Правда, если это не костыль, то что? :)

Конструирование объекта, причем такое, какое ты сам хочешь.

Cделай теперь функцию createPluginClass, чтобы работала, например, так

var Plugin2 = createPluginClass(Plugin1, function(){ Plugin1.apply(this,arguments) })

и наслаждайся.

Там тоже с поддержкой браузерами не всё гладко, оно только в js 1.8.5 появилось. Но уже хоть что-то.

Вот и получается, что в js каждый тащит для себя какой-то костыль для того, чтобы можно было как-то имитировать нормальное ООП. А за что хвалят прототипы — так никто и не раскололся, почему-то.

О, это уже что-то. Правда, если это не костыль, то что? :)

Вообщето вызывать в наследном классе классовый метод парента чери именование наследника - это извращение без какого-либо практического смысла.

Смысл простой: оставить у плагина депенденсы, как у родителя, если не указано иного.

чтобы можно было как-то имитировать нормальное ООП

Наследовать классовые методы - это никакого отношения к «нормальному ООП» не имеет.

Ты не видишь ситуации в целом. В js явные прототипы, в питоне неявные. Класс это и есть прототип объекта в питоне (и это не правильно с м.т.з.). В руби прототип объекта как бы внутри класса, при этом есть прототип самого класса, т.е. для объекта отдельный прототип так же как и в js, но опять же неявно. Здесь все явно, делай что хочешь, прототип внутри, прототип снаружи.. генерируй прототип налету.. и т.п., в общем, если в др ЯП все прибито гвоздями, то здесь нет. И все начинает зависеть от рук.

Так и без классовых методов: у каждого свой костылик.

Так то оно, может, и так, только вот где он, хороший код на прототипах? Дайте взглянуть?

Я вот с примером на Object.create так полностью и не разобрался: как потом в методах глядеть эти свойства правильно? Чтобы если метод из Plugin1 вызван из Plugin2, то он видел метаинформацию от Plugin2?

Учитывая, что сабж сравнивается с питоном, в котором, «классовые» методы добавляются к объекту, все становится особенно забавно.

Вообще, наверно, сделаю отдельно структуру с метаданными, да буду передавать в конструктор при инстанцировании. Просто в питоне я бы обошёлся просто классом, по мне так удобно.

Я то хотя бы свой синдром утёнка не замалчиваю ;)

он будет

Хто? Хороший код? Когда? А то уж полночь близится.. :)

Только ты пойми, что это разные пространства, объект и «класс», т.е. у объекта нет метаданных, к ним надо обращаться более явно: this.constructor.metainformaciyayi.m3 (если из объекта). А из класса this.metainformaciyayi.m3

Я понимаю, так и делаю через constructor, но почему-то получаю всё равно от Plugin1. Сам не пойму, чё такое.

объект Plugin1 видимо

Нет, инстанцируюсь от Plugin2:

p2 = new Plugin2();

а потом

Plugin2.meta.m1 = 'plugin2'
p2.constructor.meta.m1 // даёт объект из Plugin1

А что, кто-то ещё по доброй воле пользуется изделиями мозиллы?

Я пользуюсь, ибо вимператор.

Да и громоптице конкрурентов нет.

Ну нафиг, надоело это ковырять, я уже на диван ушёл валяться, лучше сделаю структуру уровнем выше, будет проще. Не везде можно как в питоне, придётся смириться :)

да в мире вообще все не для всех)

И Б-г бы с ним, с жс, так ведь куда ж от него денешься? Я б даже руби лучше б юзал, ей богу.

Только ему это всё равно не поможет. У пестона нет будущего. В пестоне, например, нельзя дополнять встроенные типы (строку например), что сводит на нет полезность данной фичи. Она как раз и нужна главным образом для этого, в остальных случаях её полезность невелика. Вообще пестон производит впечатление убогой недоделки. Одно смешение код конвеншнов в стандартной либи о многом говорит. То ли дело руби. Тут это ровно и красиво.

даже

Какой злобный питоновод :}

Акция Phones for Apps напоминает похожие акции от Nokia в прошлом, которые позволили в свое время развить экосистему MeeGo/Maemo.

Где здесь Qt?

Где здесь Qt?

В интерфейсах телефонов Nokia. // Ваш К.О.
http://qt-project.org/wiki/Support_for_Maemo

Всё мобильное ПО должно бытъ на компилируемых в машинный код языках со строгой типизацией.

Ага, а писать его должен исключительно Линус в целях экономии батареи.

Всё же с бОльшим интересом жду Убунтофон.

Акция Phones for Apps напоминает похожие акции от Nokia в прошлом, которые позволили в свое время развить экосистему MeeGo/Maemo.

Они много лет пилят небольшую ОС, сколько же времени мозилловцам надо будет на создание экосистемы?