Предпочту общаться на ВЫ.
Мне понадобится как минимум около 30 методов, реализация которых уже имеется в jQuery.
Не вижу смысла изобретать велосипед заново и писать кроссплатформенный код, если подобное уже сделано профессионалами.
Вы так и не ответили на мой вопрос: Есть ли реальные альтернативы jQuery? Есть ли реальные альтернативы Bootstrap?
Я немного не понял — вы троллите? Предлагаете написать 240 килобайт jQuery кода на велосипеды в виде чистого javascript?
Есть ли реальные альтернативы jQuery? Есть ли реальные альтернативы Bootstrap?
Не подумайте, что я придираюсь, мне правда интересно (я понемногу изучаю верстку и программирование для веб):
Какие сегодня есть альтернативы jQuery? Почему он считается устаревшим?
Если не использовать jQuery, то не выйдет использовать и тот же Bootstrap, а какие ему сегодня есть популярные альтернативы?
Про выдержку на английском я тоже согласен, о чем и написал в конце предыдущего сообщения. «тупо массив» использовать не выйдет при неизвестном количестве элементов, и придется писать заново велосипед для расширения массива, который уже внутри ArrayList. Хотя в случае с забиванием null пожалуй соглашусь с вами, потери тут будут минимальны.
А вот по сложности алгоритмов — вы путаете произвольный доступ к случайному элементу и итерирование. Было бы странным при практически равных показателях на операции с чтением всех элементов иметь в одном случае o(n) а в другом o(1).
Также хотел бы ОБЯЗАТЕЛЬНО обратить внимание на пункт с последовательностью в памяти к элементам, что должно было бы упростить доступ к ним — в java в памяти последовательно лежит только массив указателей на указатели, сами же указатели на объекты и объекты будут непоследовательно лежать в памяти, в разных местах.
Вся проблема в оверхеде при аллокации памяти при изменении очередности элементов. В LinkedList этой проблемы нету.
Вы рассматриваете абстрактных коней в вакууме, а вам приводят объективные доводы в пользу той или иной структуры хранения данных.
Потому пройдемся по списку:
1) Пример надуман, да и не представляю что создать миллионный массив + 1000 быстрее, чем просто добавить 1000
2) Приведите пример? В чем сложность итерирования вообще чего либо?
3) Это заставит приложение разрастить просто нереально, о эффективном использовании памяти речь не будет идти вовсе. (Не забываем про аллокацию при достижении лимита выделенной памяти под массив)
4) Вода, нужен пруф и тесты
5) Снова вода и снова нужны пруф и тесты
6) Каждый элемент массива — указатель. Конечно памяти ест меньше, но ваше сравнение некорректное, ведь для каждой структуры свои цели — советую почитать что и где лучше использовать.
7) При добавлении неизвестного количества элементов LinkedList даст фору именно по этой причине.
Вы написал «пруфы смысла не имеют» — не надо так. Я сам использую почти всегда ArrayList, но лишь по той причине, что скорость работы и количество аллокаций мне не важны. В BigData разговор был бы совсем другой.
Как раз говорить, как говорите вы, некорректно. Какие же это UI паттерны? Что значит граница приложения? Где можно почитать про то, что это всё вместе UI-паттерн?
Мне всегда казалось, что это архитектурные паттерны.
В MVC (к примеру) модель, UI и схема их взаимодействия разделены.
Основная цель применения этой концепции состоит в разделении бизнес-логики (модели) от её визуализации (представления, вида).
Т.е. они используются для грамотного разделения модели и UI, это очевидно.
Разделять приложение на слои (я даже не говорю про разделение на уровни в рамках одного слоя) и нужно, если следовать данным архитектурным паттернам.
qw1 дело говорит, UB тут не будет, хотя такой код я бы не писал. Инкременты, затем присваивание, так в Си (как минимум).
Вообще, эквивалентом будет такой код:
*a++ = *b++;
/////////////////////
int i = 0;
a[i] = b[i];
i++;
Анализаторы кода нужны практически везде (как и грамотное тестирование приложений).
Так как вы привели пример с картинками, я тоже приведу похожий.
В системе Android картинки (кроме формата png, bmp, jpg и т.д.) могут быть описаны файлом в формате xml.
Обычно иконку приложения описывают как именно картинку, и это не вызывало проблем. Но появился разработчик, который вместо png файла вставил xml файл. Очевидно, что все должно было работать, ведь система поддерживает данный формат. Оно и работало — на большинстве телефонов, кроме модели от Sony. У данной модели была своя реализация UI для телефона, которая не предусмотрела xml как входной формат. Телефон пытался отобразить картинку, у него не получалось, он перезагружался и цикл повторялся.
Статический анализатор вполне мог бы указать, что switch-case блоки для всех типов в enum, кроме xml.
Теперь я вас понял.
Поддержу вас в том, что для расширяемости приложения удобнее логику работы с ActionBar хранить в Activity (ну если только архитектура это позволяет, ведь какой-нибудь ToolBar может быть прямо внутри фрагмента, и стучать колбэками из Activity в него плохой стиль, имхо).
И все же не вижу существенной разницы в приведении типа между Object и IObject. Можете обосновать этот момент — почему это вам не нравится?
Сами фрагменты в onAttach регистрируют Activity как слушатель
Не понимаю, как будет реализована связка через слушателей без того же преобразования типов — приведите пример, пожалуйста.
Соглашусь в том, что Activity должен руководить изменениями в ActionBar, а не фрагмент, так как в таком случае проще будет добавлять поддержку планшетов и прочих модернизаций, касающихся функционала.
Мне статья понравилась, но есть замечание по терминологии в 1 пункте
Объекты содержат в себе статические поля и все методы. Экземпляры содержат только не статические поля. Это значит, что методы не дублируются в каждом экземпляре, и здесь применяется паттерн Flyweight.
Есть понятие («класс») и есть понятие («экземпляр класса», что по сути == «объект»). Используя такие термины, никогда не возникнет путаницы при изучении нового языка.
Также мне интересно, есть ли у разработчиков понимание, почему один и тот же метод у разных экземпляров класса в разных потоках не пересекается с другими и не меняет их значения, ведь по сути инструкции метода не дублируются?
Все встало на свои места — компилятор не будет резервировать место под ссылку, если она в теле метода создается и больше не используется нигде. TEST
Если же ссылка будет полем объекта или пробрасываться в параметр методу — 4(8) байта.
Теперь зададим Toolbar, как ActioanBar, это обеспечит нам обратную совместимость с предыдущими версиями Android (API Level < 21).
Это не так, Toolbar будет работать с любой версией андроида. Запихивать его в Actionbar нужно тогда, когда разработчик ленится переносить логику по работе с Actionbar в новый API, или когда проект имеет много скринов и переход будет трудозатратен.
По новым гайдам NavigationDrawer закрывает Header, потому нету смысла более иметь ActionBarDrawerToggle — обходитесь без него.
Если мы создадим ссылку в теле метода, то эта ссылка будет лишь алиасом. К сожалению, на практике, как я написал ответом чуть выше — это не так, потому я был очень удивлен.
Я понимаю, что вполне себе логично не хранить ссылку вообще в ассемблерном коде, а просто ссылаться на адрес переменной по этой ссылке (в теле метода, не в объекте — по поводу объекта и при передаче как параметра я с вами согласен).
A C++ reference is not a pointer. It is an alias of an object. Sometimes, the compiler chooses to implement this by using a pointer. But often, it implements it by doing nothing at all. By simply generate code which refers directly to the original object.
Не могу понять, почему спецификация говорит о том, что ссылки могут не занимать памяти.
Простой пример покажет вот такой результат:
long long int a = 5;
long long int &ref = a;
printf("%d = a\n", sizeof(a));
printf("%d = ref\n", sizeof(ref));
printf("%d = &ref\n", sizeof(&ref));
//... output
8 = a
8 = ref
4 = &ref
Мне понадобится как минимум около 30 методов, реализация которых уже имеется в jQuery.
Не вижу смысла изобретать велосипед заново и писать кроссплатформенный код, если подобное уже сделано профессионалами.
Вы так и не ответили на мой вопрос: Есть ли реальные альтернативы jQuery? Есть ли реальные альтернативы Bootstrap?
Есть ли реальные альтернативы jQuery? Есть ли реальные альтернативы Bootstrap?
Какие сегодня есть альтернативы jQuery? Почему он считается устаревшим?
Если не использовать jQuery, то не выйдет использовать и тот же Bootstrap, а какие ему сегодня есть популярные альтернативы?
А вот по сложности алгоритмов — вы путаете произвольный доступ к случайному элементу и итерирование. Было бы странным при практически равных показателях на операции с чтением всех элементов иметь в одном случае o(n) а в другом o(1).
Также хотел бы ОБЯЗАТЕЛЬНО обратить внимание на пункт с последовательностью в памяти к элементам, что должно было бы упростить доступ к ним — в java в памяти последовательно лежит только массив указателей на указатели, сами же указатели на объекты и объекты будут непоследовательно лежать в памяти, в разных местах.
Вы рассматриваете абстрактных коней в вакууме, а вам приводят объективные доводы в пользу той или иной структуры хранения данных.
Потому пройдемся по списку:
1) Пример надуман, да и не представляю что создать миллионный массив + 1000 быстрее, чем просто добавить 1000
2) Приведите пример? В чем сложность итерирования вообще чего либо?
3) Это заставит приложение разрастить просто нереально, о эффективном использовании памяти речь не будет идти вовсе. (Не забываем про аллокацию при достижении лимита выделенной памяти под массив)
4) Вода, нужен пруф и тесты
5) Снова вода и снова нужны пруф и тесты
6) Каждый элемент массива — указатель. Конечно памяти ест меньше, но ваше сравнение некорректное, ведь для каждой структуры свои цели — советую почитать что и где лучше использовать.
7) При добавлении неизвестного количества элементов LinkedList даст фору именно по этой причине.
Вы написал «пруфы смысла не имеют» — не надо так. Я сам использую почти всегда ArrayList, но лишь по той причине, что скорость работы и количество аллокаций мне не важны. В BigData разговор был бы совсем другой.
пруф
Мне всегда казалось, что это архитектурные паттерны.
В MVC (к примеру) модель, UI и схема их взаимодействия разделены.
Основная цель применения этой концепции состоит в разделении бизнес-логики (модели) от её визуализации (представления, вида).
Т.е. они используются для грамотного разделения модели и UI, это очевидно.
Разделять приложение на слои (я даже не говорю про разделение на уровни в рамках одного слоя) и нужно, если следовать данным архитектурным паттернам.
Вообще, эквивалентом будет такой код:
Так как вы привели пример с картинками, я тоже приведу похожий.
В системе Android картинки (кроме формата png, bmp, jpg и т.д.) могут быть описаны файлом в формате xml.
Обычно иконку приложения описывают как именно картинку, и это не вызывало проблем. Но появился разработчик, который вместо png файла вставил xml файл. Очевидно, что все должно было работать, ведь система поддерживает данный формат. Оно и работало — на большинстве телефонов, кроме модели от Sony. У данной модели была своя реализация UI для телефона, которая не предусмотрела xml как входной формат. Телефон пытался отобразить картинку, у него не получалось, он перезагружался и цикл повторялся.
Статический анализатор вполне мог бы указать, что switch-case блоки для всех типов в enum, кроме xml.
Поддержу вас в том, что для расширяемости приложения удобнее логику работы с ActionBar хранить в Activity (ну если только архитектура это позволяет, ведь какой-нибудь ToolBar может быть прямо внутри фрагмента, и стучать колбэками из Activity в него плохой стиль, имхо).
И все же не вижу существенной разницы в приведении типа между Object и IObject. Можете обосновать этот момент — почему это вам не нравится?
Ваши слова себе же противоречат:Не понимаю, как будет реализована связка через слушателей без того же преобразования типов — приведите пример, пожалуйста.
Соглашусь в том, что Activity должен руководить изменениями в ActionBar, а не фрагмент, так как в таком случае проще будет добавлять поддержку планшетов и прочих модернизаций, касающихся функционала.
Также мне интересно, есть ли у разработчиков понимание, почему один и тот же метод у разных экземпляров класса в разных потоках не пересекается с другими и не меняет их значения, ведь по сути инструкции метода не дублируются?
Если же ссылка будет полем объекта или пробрасываться в параметр методу — 4(8) байта.
По новым гайдам NavigationDrawer закрывает Header, потому нету смысла более иметь ActionBarDrawerToggle — обходитесь без него.
По сути, в ios пошли таким же путем, хотя это и С.
Я понимаю, что вполне себе логично не хранить ссылку вообще в ассемблерном коде, а просто ссылаться на адрес переменной по этой ссылке (в теле метода, не в объекте — по поводу объекта и при передаче как параметра я с вами согласен).
Простой пример покажет вот такой результат: