Надеюсь ты и правда больше не будешь отвечать. Для всех адекватных людей:
CoreData нельзя назвать ORM по нескольким причинам — во-первых, в качестве хранилища может быть использована не только SQLite, но и нереляционные хранилища (ссылка); во-вторых (на самом деле следствие первого) нельзя использовать базу SQLite и напрямую, и через CoreData (или привязать CoreData к готовой базе (ссылка)). То есть замапить что-то куда-то действительно нельзя.
Не совсем понятна реализация многопоточности. Допустим:
var flag = false,
runnable = new java.lang.Runnable({
run: function() {
print("I'm running!");
flag = true;
}
});
new java.lang.Thread(runnable).start();
while (!flag){}
print("Done");
Собственно, этот тезис и хотелось бы покритиковать (слегка). Все таки в начале такая оценка дается:
разработчик — 2-3 года,
ведущий разработчик — плюс 2 года,
архитектор решения — плюс 3–5 лет
А тут получается вместо 10 лет 2. Не слишком ли круто?
Причем очевидно — архитекторами, которым требуются подобные компетенции, станут единицы, а технические предметы, на которые можно было выделить вместо этого время, были бы полезны многим.
Может, конечно, что-то изменилось, но когда я учился в технопарке (1ый семестр), там было всего два предмета в семестр. Это очень мало, на мой взгляд, чтобы отходить от технических тематик.
Странно видеть такой курс в двухгодичной программе обучения, учитывая что в первом семестре рассказывали про то, что такое реляционные субд и как сделать select, и прочие основы основ. То есть этапы технических навыков, выстраивания взаимосвязей и личныех навыков успешно пройдены?
Если вы хотите, чтобы у конструктора были те же методы, что и у порождаемых им объектах (т. е. их прототипа), нужно скопировать их из прототипа в конструктор.
С точки зрения «сахарности» можно иногда и усложнить, в угоду читаемости. Например:
var Note = new Model({
'text': {
'name' : {
type: 'string',
validators: []
}
}
});
Несмотря на то, что тип это просто валидатор, можно для него сделать отдельное поле (естественно, как опцию, а не жесткое правило). Для валидаторов можно сделать два поля — validator и validators. Вот это и есть сахар. Причем обратывать эти поля можно одним и тем же кодом, то есть использовать их как синонимы (ну точне брать валидаторы из всех и объединять в массив).
Для аргументов валидаторов вы нашли плохое решение, потому что элементы массива равноправны, а названия валидатора и аргументы — нет. Понятно, что они нужны, но в итоге совершенно нечитаемо.
Насчет конфигурационной функции — не понятно, почему то же самое нельзя делать снаружи:
var Note = new Model('Note', function () {
}).attr('id!', 'number').validates(...)
По поводу метода bind, то он стал стандартным только в JS 1.8.5 (в современных браузерах с марта 2011 года, начиная с ФФ4), в то время, как Model.js нацелена на JS 1.5
Если вас так волнует поддержка старых браузеров, то весьма странно видеть использование __proto__,__defineGetter__ и __defineSetter__, которые вообще не являются стандартными.
var Note = new Model('Note', function () {
this.attr('id!', 'number');
this.attr('title', 'string', 'nonempty');
this.attr('text', 'string');
});
Почему не так:
var Note = new Model({
'id!' : 'number',
'title': {
type: 'string' // или String
validator: 'non-empty'
},
'text': 'string'
});
note.bind(eventName, handler) «вешает» обработчик. Кстати говоря, повесить обработчик любого события можно не только на отдельную сущность, но и на все сущности класса (Note.bind).
основная «киллер-фича» — Gruntfile — это просто javascript. Соответственно, используйте любые пакеты, трюки для генерации конфигов, прямо на ходу пишете таски, заточенные под проект. То есть одновременно и декларативная конфигурация, и полный контроль над процессом.
Из отсутствующих фич — было бы неплохо иметь возможность описывать граф тасков через зависимости, как в анте. В гранте же нужно явно объявлять таск, включающий в себя последовательность тасков.
Мне кажется, rework замечательная штука, если использовать его именно для таких целей — добавлять префикс, хаки для различных браузеров и т.д. То есть, с одной стороны в имеете чистый и валидный css, который должен прекрасно работать в сферическом браузере в вакууме, а rework делает грязную работу. А вот если использовать все возможности rework на полную катушку, то получается странно — вроде бы css-файл, но на самом деле это не css, незнакомый с проектом человек открывает, встречает вроде бы знакомые конструкции но с новыми свойствами, или еще хуже — когда переопределены стандартные свойства.
В этом смысле SASS и другие макроязыки лучше — видишь sass файл, если знаешь sass — все в порядке, не знаешь — открываешь референс и разбираешься.
CoreData нельзя назвать ORM по нескольким причинам — во-первых, в качестве хранилища может быть использована не только SQLite, но и нереляционные хранилища (ссылка); во-вторых (на самом деле следствие первого) нельзя использовать базу SQLite и напрямую, и через CoreData (или привязать CoreData к готовой базе (ссылка)). То есть замапить что-то куда-то действительно нельзя.
Что-то не уверен…
Такое возможно?
Чем переводили то?
А тут получается вместо 10 лет 2. Не слишком ли круто?
Причем очевидно — архитекторами, которым требуются подобные компетенции, станут единицы, а технические предметы, на которые можно было выделить вместо этого время, были бы полезны многим.
Может, конечно, что-то изменилось, но когда я учился в технопарке (1ый семестр), там было всего два предмета в семестр. Это очень мало, на мой взгляд, чтобы отходить от технических тематик.
P. S. За литературу — спасибо
Если cls это не функция, то установка prototype ничего не делает. Если cls это функция, то устанавливая __proto__ вы отрубаете Function.prototype. Отличный пост habrahabr.ru/post/140810/, еще dailyjs.com/2012/11/26/js101-proto/.
Если вы хотите, чтобы у конструктора были те же методы, что и у порождаемых им объектах (т. е. их прототипа), нужно скопировать их из прототипа в конструктор.
Несмотря на то, что тип это просто валидатор, можно для него сделать отдельное поле (естественно, как опцию, а не жесткое правило). Для валидаторов можно сделать два поля — validator и validators. Вот это и есть сахар. Причем обратывать эти поля можно одним и тем же кодом, то есть использовать их как синонимы (ну точне брать валидаторы из всех и объединять в массив).
Для аргументов валидаторов вы нашли плохое решение, потому что элементы массива равноправны, а названия валидатора и аргументы — нет. Понятно, что они нужны, но в итоге совершенно нечитаемо.
Насчет конфигурационной функции — не понятно, почему то же самое нельзя делать снаружи:
Если вас так волнует поддержка старых браузеров, то весьма странно видеть использование __proto__,__defineGetter__ и __defineSetter__, которые вообще не являются стандартными.
Почему не так:
Вообще круто. developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Function/bind Переопределять стандартный метод вместо того чтобы использовать общепринятые on или addEventListener
Это разве синтаксический сахар?
Из отсутствующих фич — было бы неплохо иметь возможность описывать граф тасков через зависимости, как в анте. В гранте же нужно явно объявлять таск, включающий в себя последовательность тасков.
В этом смысле SASS и другие макроязыки лучше — видишь sass файл, если знаешь sass — все в порядке, не знаешь — открываешь референс и разбираешься.