Да нафик не нужны эти приватные члены в javascript. Используйте просто нотацию имён, с _ — private, без — всё остальное.
А вот динамически вычисляемые поля в json это круто. Интересно если результат вычисления null или undefined, то поле будет добавлено в объект?
В какой компании вы работаете? Просто интересно на будущее, куда заявку точно не стоит подавать.
Ну серьёзно, нафига программисту нужен системный анализ? На мех-мате это один из самых укуренных и бесполезных после философии предметов.
•Отсутствие типизации;
•Прототипное наследование;
•Возможность разделения на файлы как тебе удобно;
•Взаимодействие с DOM деревом;
•Гибкая событийная модель; А также возможность создавать свои модели.
•Наличие удобных редакторов кода (VS, WebStorm)
Хороший вопрос: ответ простой — на java есть одна хорошая open-source библиотека для работы с кубами и mdx — mondrian.
На C# ничего подобного не было, да и вообще где-либо.
В вашем способе число создаваемых объектов будет вдвое больше, что скажется на объёме потребляемой памяти.
И вообще, зачем прятать приватные поля и методы? Они придуманы просто ради удобства и понимания кода. Просто используйте какую-нибудь нотацию приватных полей и всё.
Только хотел попробовать сделать, а тут такая хрень:
В общем случае необходимо строить архитектуру приложения таким образом, чтобы она позволяла менять реализацию на лету, например не использовать конструкторы, а получать классы по имени и создавать объекты с помощью рефлексии
А вот динамически вычисляемые поля в json это круто. Интересно если результат вычисления null или undefined, то поле будет добавлено в объект?
Дата рождения:26 августа 1981
Программирует 28 лет.
Андрей Плахов
Дата рождения:13 августа 1980
Программирует 25 лет
Что за монстры такие в яндексе?
> Высокая нагрузка на компьютер пользователя;
С современными браузерами нагрузка не такая высокая.
> Возможна избыточность — часть знаний клиентской части об отображении может так и остаться невостребованной, если какие-то события не наступят;
Не надо просто грузить все скрипты сразу. Загружать нужно только то, что необходимо для отрисовки.
Самый настоящий минус в 3-ем подходе — это необходимость доработки сайта для индексации в поисковиках.
Ну серьёзно, нафига программисту нужен системный анализ? На мех-мате это один из самых укуренных и бесполезных после философии предметов.
•Отсутствие типизации;
•Прототипное наследование;
•Возможность разделения на файлы как тебе удобно;
•Взаимодействие с DOM деревом;
•Гибкая событийная модель; А также возможность создавать свои модели.
•Наличие удобных редакторов кода (VS, WebStorm)
На C# ничего подобного не было, да и вообще где-либо.
В c# есть переопределение операторов, и это более удобно — не надо делать проверки на null, как с equals.
А так получается, что оператор == в java ну нафик не нужен.
К примеру сервер должен возвращать матрицу чисел, в некоторых ячейках могут быть null, тогда и появляется Double, Integer.
И вообще, зачем прятать приватные поля и методы? Они придуманы просто ради удобства и понимания кода. Просто используйте какую-нибудь нотацию приватных полей и всё.
2. Классы грузятся автоматически. Я просто пишу код с их использованием.
3. Не использую.
печалька. Вообще возможно обойти те ограничения, которые вы описали?
В общем случае необходимо строить архитектуру приложения таким образом, чтобы она позволяла менять реализацию на лету, например не использовать конструкторы, а получать классы по имени и создавать объекты с помощью рефлексии
всё желание сразу пропало.
А на переднем baby freeze