Я как-то над этим задумывался делая мелкий ремонт у себя дома.
Если считать своё время, то получается куда дороже если нанять дядьку со стороны,
но с другой стороны, надо уметь делать кое-что кроме написания программ, например, прибить гвоздь в доме
а по поводу обеда, есть жена дома, которая сидит с ребёнком и готовит в 100 раз вкуснее и сытнее ресторанов
ещё были мысли по поводу отдыха, например уехал на выходные на пикник или заболел на неделю, вроде думаешь, пля, потерял столько бабла, а потом понимаешь, что жизнь это не бабло и пошло оно в ж… пу.
Обычно у меня это проявляется при большой количестве табов. Я бажный таб вытаскиваю в отдельное окно и часто чекбоксы появляются. Ставлю обратно — пропадают.
Тогда смысл оставлять место справа под контрол, чтобы он потом туда расширился?
Если бы у меня было место, я бы сразу сделал пошире селект и не парился с вашими скриптами.
А вы пробовали?
Давно как-то крутил такие трюки, там потом проблемы this.
Хотя бы то, что такие конструкторы вызываются при определении наследования, побуждают меня так не писать.
В общем, при реализации каких-то паттернов так может и имеет смысл писать. В реальности же я так никогда не делал.
И лично считаю такое bad coding style.
По той же ссылке что вы дали, читайте пункт Наследование
«Видите, мы фактически делаем класс, производный от объекта, а не от другого класса — используется оператор new. По этой причине в Javascript лучше не нагружать конструктор ничем лишним, а оставить на его долю лишь заполнение свойств начальными значениями, а методов — кодом.»
А методы определенные внутри конструктора только в крайних случаях, когда без них никак или с ними изящнее. У меня вроде нет ни одного такого реального применения.
А так, это лишняя память на каждый вновь создаваемый объект. Оно вам это надо?
Где вы такое применение видели? Я имею ввиду создание переменных и методов внутри конструктора? Они же вообще нигде доступны не будут.
А по поводу объективности применения приватных методов — я их использую, когда не хочу их видеть в дебаггере. Больше необходимости в них нет, т.к. защитить код вы всё равно не можете.
И экономии в таких случаях нет, так приходится писать method.call( this )
Зарегался.
Только я не понял. Что с Аляской.
Было как побеждали, -10000. И оставалось полчаса до конца.
А потом бац, и уже +15000 и время боя увеличилось на 20 минут, и бойцы перестали активничать?
То вы про наблюдение за детьми, животными, строителями, т.е. довольно серьёзные примеры для использования дома.
То ради забавы.
НЕ обижайтесь, но пост-чушь, так как ваш способ очевиден к тому же очень ограничен.
Отбросим кредит.
Я покупаю этих бумажек номиналом в баксах, потом таких же (если есть) в рублях.
Там и там я пользуюсь плечом. Т.е. как я понял, теряю я деньги что внёс наличными, а прибыль получаю уже умноженную на плечо?..
и все их пользователи будут ваши
потому как это проект уже не поддерживается, но самый лучший что я видел
Если считать своё время, то получается куда дороже если нанять дядьку со стороны,
но с другой стороны, надо уметь делать кое-что кроме написания программ, например, прибить гвоздь в доме
а по поводу обеда, есть жена дома, которая сидит с ребёнком и готовит в 100 раз вкуснее и сытнее ресторанов
ещё были мысли по поводу отдыха, например уехал на выходные на пикник или заболел на неделю, вроде думаешь, пля, потерял столько бабла, а потом понимаешь, что жизнь это не бабло и пошло оно в ж… пу.
Обычно у меня это проявляется при большой количестве табов. Я бажный таб вытаскиваю в отдельное окно и часто чекбоксы появляются. Ставлю обратно — пропадают.
a.getAttribute(«href»,2)
тогда там всегда будет то, что положили
Если бы у меня было место, я бы сразу сделал пошире селект и не парился с вашими скриптами.
Но почему в блоге гугл?
Про такую конструкцию я не спорю.
this.constructor.prototype.constructor.call(this,a,b);
Вот эта точно работать не будет при двойном наследовании.
Давно как-то крутил такие трюки, там потом проблемы this.
Хотя бы то, что такие конструкторы вызываются при определении наследования, побуждают меня так не писать.
В общем, при реализации каких-то паттернов так может и имеет смысл писать. В реальности же я так никогда не делал.
И лично считаю такое bad coding style.
«Видите, мы фактически делаем класс, производный от объекта, а не от другого класса — используется оператор new. По этой причине в Javascript лучше не нагружать конструктор ничем лишним, а оставить на его долю лишь заполнение свойств начальными значениями, а методов — кодом.»
А методы определенные внутри конструктора только в крайних случаях, когда без них никак или с ними изящнее. У меня вроде нет ни одного такого реального применения.
А так, это лишняя память на каждый вновь создаваемый объект. Оно вам это надо?
И всё-таки, откуда откопали такие примеры, где в конструкторе описывается весь класс?
Как сказано выше, оправдано только для singleton и lazy initilization.
По мне всё что вы привели, это уровень чайника. И обсуждать оправдано или нет в реальных проектах… всё-таки не стоит.
А по поводу объективности применения приватных методов — я их использую, когда не хочу их видеть в дебаггере. Больше необходимости в них нет, т.к. защитить код вы всё равно не можете.
И экономии в таких случаях нет, так приходится писать method.call( this )
если бы не пост и ваш коммент я даже не знал про этот сайт )
(пошёл копить на танк...)
Только я не понял. Что с Аляской.
Было как побеждали, -10000. И оставалось полчаса до конца.
А потом бац, и уже +15000 и время боя увеличилось на 20 минут, и бойцы перестали активничать?
То ради забавы.
НЕ обижайтесь, но пост-чушь, так как ваш способ очевиден к тому же очень ограничен.
Но Valar в шоколаде пока доллар растёт (точнее рос).
Но ведь при относительно небольшом падении, он теряет весь залог.
А кредиту колебания не страшны, сегодня меньше завтра, завтра больше.
Отбросим кредит.
Я покупаю этих бумажек номиналом в баксах, потом таких же (если есть) в рублях.
Там и там я пользуюсь плечом. Т.е. как я понял, теряю я деньги что внёс наличными, а прибыль получаю уже умноженную на плечо?..
Если тяжко объяснять, то отправляйте сразу RTFM.