Везде забывают написать довольно важную вещь, что кастомную прошивку без повышения модема после восстановления тоже надо джейлить иначе не будет активации (или вообще не будет джейла?), для владельцев залоченных телефонов без оригинальной сим это принципиально важно :)
Привык я к snowbreeze, прошился и потом больше часа голову ломал, почему айфон не активирован. А всегото нужно было в redsnow нажать Jailbreak и выбрать «install Cydia».
В том то и дело, я сам автор одного GUI-фреймворка, но за полтора года работы над ним, так и не смог понять зачем кому-то переносить ООП в JS «как есть». Единственная причина, это пожалуй, возможность использовать одну и ту же (или опять таки «похожую») архитектуру на клиенте и сервере.
Очень странно, уже довольно давно пишу на клиентском JS и ни разу мне не приходила в голову идея написать свою (или даже взять чужую) реализацию ООП. Не то чтобы необходимость в этом полностью отсутствует, но интерфейсы относительно легко пишутся и нативными средствами (хотя обычно я использую фреймворк).
Получается, что ООП в JS для меня как инструмент с узким кругом задач под него.
Пожалуйста, не используйте слово «очевидно», говоря про вещи «серьезным специалистом» в которых вы не являетесь. Я например не смог найти подтверждения вашим словам в интернете, зато гугл первой строчкой выдал следующее: www.gmmcc.com.ua/gmmcc/index.php?option=com_content&task=view&id=114&Itemid=76
читаем текст перед и после первой большой картинки.
Вы действительно верите, что развитие моторики при письмо более существенное чем при наборе текста (хотя бы восьми-пальцевом методом) на клавиатуре?
У меня с детства проблемы с пальцами… я ими более менее адекватно шевелить научился только после того, как мне компьютер подарили.
Внезапно три вопроса от окружающих:
1) Можно ли приходить с маленькой кармой? :)
2) Можно ли захватить девушку?
3) Как вас там узнать если раньше не был?
Возможно слегка не по теме…
Моей мечтой было бы увидеть реализацию двух пространств имен для объекта. Хотя это довольно экзотическая вещь. Например можно было бы всякие toString() toInt() toRainbow() писать в отдельный namespace и реализовать две ветки наследования. Это действительно может быть очень полезно при определенных архитектурах, ну и вспомните хотя бы про необходимость использовать сейчас hasOwnProperty (а если проверку нужно делать везде и для прямого родителя? с ума сойти). Еще можно вспомнить про заблокированное свойство name у функций.
Выглядеть это могло бы например так:
object.method() и object.$method()
И надеюсь будет хоть какая-то возможность прототипировать функции.
Понял вашу позицию, и кажется мы говорим слегка о разных вещах. Я немного неправильно изложил свою позицию. Постараюсь переформулировать.
Рынок безусловно будет расти и количество сервисов тоже. Но с точки зрения пользователя (и как ни странно разработчика) все интерфейсы будут унифицироваться. То есть совершенно не важно сколько фейсбуков и вконтактов будет в интернетах, как разработчика меня не будет заботить то, какой именно сервис будет использовать пользователь для заливки картинок, ведь какой бы он не выбрал, я смогу получить доступ к этим картинкам через унифицированный интерфейс.
Мечтать конечно не вредно, но причин сомневаться в таком «будущем» у меня нет.
Вы правы, однако стоит учитывать, что статья относится скорее к «будущему», тогда как ваш комментарий описывает только «настоящее». Вы же не думаете, что через 5-10 лет появится еще двадцать «фэйсбуков» и десять «вконтактов», которые по-братски поделят аудиторию интернета? Развитие такого сценария мы наблюдаем уже не один год, но всему есть предел.
Хорошая идея и реализация. Не совсем понимаю, откуда столько критиков набежало. Способ действительно значительно упрощает код, хотя и имеет определенные рамки применения. Самым вкусным мне показалась возможность обвязать этот функционал, чтобы обеспечить декларативное задание для той части логики, где это возможно. При этом не сложно представить как большая часть Sync() и .sync() исчезнет из кода, что сделает его еще более читабельным и простым.
Понравилось, однако «влезание в прототипы» — практика мягко говоря опасная и уж тем более не добавляет библиотеке легкости во взаимодействии с другими библиотеками. Так что четвертый пункт надо бы вычеркнуть. Но даже без него библиотека смотрится довольно интересно. В своих проектах, пожалуй, буду использовать.
И всё-таки лучше поздно чем никогда. Замечательный костылёк.
У меня всё заработало, только вот непонятно, почему разработчики не сделали поддержку выборочного закругления:
border-bottom-right-radius: 9px;
Почему бы вам, вместо того, чтобы ругать велосипеды, взять и почитать внимательно статью. Вы поймете, что очень ошибаетесь в своих утверждениях.
Sanitize (оно же по-русски «приведение»), которого тут якобы нету, написано аж в заголовке!
Для всех регекспов нужен лишь один фильтр и использовать его можно следующим образом.
Да, отличный способ реализовать анонимки в для моего класса. Но его функционал по сбору ошибок и удобство декларирования сложных структур данных (со сложной логикой проверки) это не отменяет.
Согласен, однако внятный сбор ошибок валидации тут присутствует. И при грамотном использовании его внятность куда выше чем у описанных вами библиотек, хотя фантазии нужно много, не спорю :). Другое дело, что набора фильтров тут действительно пока нету. То есть я их уже написал немало, но с использованием других моих классов, причем так, что тупо выдирать их смысла нету. Возможно в ближайшее время у меня дойдут руки и я перепишу фильтры, а пока, кому интересно, могут просто побаловаться с самим классом.
Тем более, тут интересна сама идея. Хороший программист поняв идею сам за день-два напишет все необходимые фильтры. Хотя ввести какой-нибудь стандарт было бы действительно полезно. Тем более, что он мною уже почти доработан. Постараюсь всё доделать)
Привык я к snowbreeze, прошился и потом больше часа голову ломал, почему айфон не активирован. А всегото нужно было в redsnow нажать Jailbreak и выбрать «install Cydia».
Получается, что ООП в JS для меня как инструмент с узким кругом задач под него.
www.gmmcc.com.ua/gmmcc/index.php?option=com_content&task=view&id=114&Itemid=76
читаем текст перед и после первой большой картинки.
У меня с детства проблемы с пальцами… я ими более менее адекватно шевелить научился только после того, как мне компьютер подарили.
вас там сегодня много?
1) Можно ли приходить с маленькой кармой? :)
2) Можно ли захватить девушку?
3) Как вас там узнать если раньше не был?
Успехов вам… буду слушать)
Моей мечтой было бы увидеть реализацию двух пространств имен для объекта. Хотя это довольно экзотическая вещь. Например можно было бы всякие toString() toInt() toRainbow() писать в отдельный namespace и реализовать две ветки наследования. Это действительно может быть очень полезно при определенных архитектурах, ну и вспомните хотя бы про необходимость использовать сейчас hasOwnProperty (а если проверку нужно делать везде и для прямого родителя? с ума сойти). Еще можно вспомнить про заблокированное свойство name у функций.
Выглядеть это могло бы например так:
object.method() и object.$method()
И надеюсь будет хоть какая-то возможность прототипировать функции.
Рынок безусловно будет расти и количество сервисов тоже. Но с точки зрения пользователя (и как ни странно разработчика) все интерфейсы будут унифицироваться. То есть совершенно не важно сколько фейсбуков и вконтактов будет в интернетах, как разработчика меня не будет заботить то, какой именно сервис будет использовать пользователь для заливки картинок, ведь какой бы он не выбрал, я смогу получить доступ к этим картинкам через унифицированный интерфейс.
Мечтать конечно не вредно, но причин сомневаться в таком «будущем» у меня нет.
У меня всё заработало, только вот непонятно, почему разработчики не сделали поддержку выборочного закругления:
border-bottom-right-radius: 9px;
Sanitize (оно же по-русски «приведение»), которого тут якобы нету, написано аж в заголовке!
Для всех регекспов нужен лишь один фильтр и использовать его можно следующим образом.
$str = 'Some Text';
Strain::it($str, array('regexp' => '/^[A-Za-z0-9 ]+$/'));
а вот так будет выглядеть ваш sanitize:
Strain::it($str, array('regexp_replace', => array('/ /', '_')));
// содержимое функций не привожу, там обычные preg_match и preg_replace.
Функционал класса не ограничивается проверкой одной переменной какой-либо функцией.
Тем более, тут интересна сама идея. Хороший программист поняв идею сам за день-два напишет все необходимые фильтры. Хотя ввести какой-нибудь стандарт было бы действительно полезно. Тем более, что он мною уже почти доработан. Постараюсь всё доделать)