Вы нашли в баре прототип нового мобильного устройства. Ваши действия?
— сфотографировать и оставить в баре
— взять и сфотографировать дома, выложить на хабр.
— взять, никому не сказать, выставить на ибей через анонимайзер. дождаться приезда полиции.
— взять, попользоваться, клеить тёлочек.
— вызвать в бар журналистов, полицию и пожарных
— убежать из бара с криком «я видел! я видел новый айфон!!!»
— бросить пить, потому что это явно глюки.
— раздробить в миксере, выложив на ютуб.
Если код, который организует вывод, не проверяет валидность данных, то вместо телефона у вас может оказаться что-нибудь другое. Поэтому вам всё равно необходимо делать проверку.
А если ваша процедура удаления оставила в коллекции ключ-значение с пустым значением, то это проблема процедуры. О чем я и говорил — всё сводится к ошибкам проектирования.
у вас всегда будет либо ситуация, когда вы полностью контролируете свои данные, и тогда вам не нужно ничего удалять.
либо вы не контролируете свои данные, и тогда вам нужна проверка.
а если вы любите реализовывать абстрактные модели из чувства прекрасного, то вам и сборщик мусора не поможет.
но delete тут не обязателен. напишите хороший парсинг, который не будет вам загромождать структуры ключами без значений. вы ведь всё равно сделаете эту проверку? так почему бы не сразу при парсинге?
зачем в реальности понадобилось бы делать так, как вы сейчас продемонстрировали — сначала создать свойство объекта, потом удалить/обнулить его, а потом пробегать, не осуществляя никакой проверки свойств? вы в реальном коде тоже так поступаете? я уверен, что нет. либо вы заранее уверены, что все поля валидны, либо обязаны делать проверку свойств.
вот скажите мне, является ли в вашем примере вывод //preved, null
ошибкой? как по мне, так не является.
Зачем эти танцы с delete в реальном проекте?
Особенно в браузере.
Если в коде сначала пихают что-то в глобальные переменные (или свойства объекта), а потом судорожно начинают это уничтожать с помощью delete, то по-моему налицо ошибка проектирования.
Есть нормально работающий механизм области видимости функции. Когда переменная больше не нужна, она сама уйдет со стека. Игры с замыканиями оставим на совести энтузиастов программирования.
10 евро за 4Гб? они могли бы вообще не париться с Bluetooth, а забить эти 4 гига книжками и продавать так. Это все равно выгоднее, чем покупать эти же издания на бумаге.
Представляете, тогда на полку можно поставить
— синенькую книгу «Лучшая английская литература 18-20 веков»
— красненькую книгу «Эротика. Лучшее»
— розовенькую книгу «Дамский роман. Новинки 2012 года»
— и т.д.
а супербестселлеры выпускать как синглы. Прочитал — хранишь или можешь отправить изготовителю на переработку (перезапись).
думаю, что проблему «копирайт vs. файлообмен» можно сформулировать, например, так:
что важнее — частное или общественное? деньги или искусство? своя свобода или чужая?
и ответ очевиден. в условиях капиталистического общества важнее всегда оказывается — частное, деньги и своя свобода.
поэтому копирайт будет побеждён только тогда, когда изменится само общество.
надо давать примеры работающих приложений, иллюстрирующие те или иные концепции.
с DOM удачно получилось, а остальное без примерно малопонятно для тех, кто на практике не сталкивался с чем-то подобным. то есть получается, что статья написана для тех, кто уже это знает, и бесполезна для тех, кто не знает.
— сфотографировать и оставить в баре
— взять и сфотографировать дома, выложить на хабр.
— взять, никому не сказать, выставить на ибей через анонимайзер.
дождаться приезда полиции.— взять, попользоваться,
клеить тёлочек.— вызвать в бар журналистов, полицию и пожарных
— убежать из бара с криком «я видел! я видел
новый айфон!!!»— бросить пить, потому что это явно глюки.
— раздробить в миксере, выложив на ютуб.
вообще это стремление из javascript'а сделать C++ меня удивляет.
А если ваша процедура удаления оставила в коллекции ключ-значение с пустым значением, то это проблема процедуры. О чем я и говорил — всё сводится к ошибкам проектирования.
либо вы не контролируете свои данные, и тогда вам нужна проверка.
а если вы любите реализовывать абстрактные модели из чувства прекрасного, то вам и сборщик мусора не поможет.
но
deleteтут не обязателен. напишите хороший парсинг, который не будет вам загромождать структуры ключами без значений. вы ведь всё равно сделаете эту проверку? так почему бы не сразу при парсинге?зачем в реальности понадобилось бы делать так, как вы сейчас продемонстрировали — сначала создать свойство объекта, потом удалить/обнулить его, а потом пробегать, не осуществляя никакой проверки свойств? вы в реальном коде тоже так поступаете? я уверен, что нет. либо вы заранее уверены, что все поля валидны, либо обязаны делать проверку свойств.
вот скажите мне, является ли в вашем примере вывод
//preved, nullошибкой? как по мне, так не является.
deleteв реальном проекте?Особенно в браузере.
Если в коде сначала пихают что-то в глобальные переменные (или свойства объекта), а потом судорожно начинают это уничтожать с помощью
delete, то по-моему налицо ошибка проектирования.Есть нормально работающий механизм области видимости функции. Когда переменная больше не нужна, она сама уйдет со стека. Игры с замыканиями оставим на совести энтузиастов программирования.
Так зачем нужен
delete?вернусь в декабре.
Представляете, тогда на полку можно поставить
— синенькую книгу «Лучшая английская литература 18-20 веков»
— красненькую книгу «Эротика. Лучшее»
— розовенькую книгу «Дамский роман. Новинки 2012 года»
— и т.д.
а супербестселлеры выпускать как синглы. Прочитал — хранишь или можешь отправить изготовителю на переработку (перезапись).
Не знаю, почему так еще не делают?
некоторые люди «не дружат» с компьютерами. у них всё ломается.
а приходит «программист» — и все магическим образом налаживается.
ждём скайнет.
что важнее — частное или общественное? деньги или искусство? своя свобода или чужая?
и ответ очевиден. в условиях капиталистического общества важнее всегда оказывается — частное, деньги и своя свобода.
поэтому копирайт будет побеждён только тогда, когда изменится само общество.
девочкам это должно быть знакомо.
без примерно*без примеров*с DOM удачно получилось, а остальное без примерно малопонятно для тех, кто на практике не сталкивался с чем-то подобным. то есть получается, что статья написана для тех, кто уже это знает, и бесполезна для тех, кто не знает.