випадково натрапив на книгу на рсс хабра, і був приємно здивований, що автором цієї роботи є не лише україновомний розробник, а й навіть працівник однієї із шанованих контор рідного львова — справді, я не очікував. і, навіть не зважаючи на купу пунктуаційних недоліків, можу сказати, що читати буквальні і дещо наївні приклади набагато приємніше і зрозуміліше, аніж читати фактично абстрактні і призначені для своїх же авторів приклади на основі ClassA, ClassB, ClassC (власне, останні якраз і відштовхують від вивчення шаблонів). це хоча би якесь починання до недосвідчених розробників, яке, я певен, спрововує їх до поглибленого вивчення проблеми ооп-дизайну загалом, що не може радувати, знаючи досвід початківців. а читати українською — вдвічі приємніше. справді, щиро дякую

читаємо уважно, з передмови:

Якщо ви розробник із великим досвідом, користі із цієї книги, швиде за все, ви не отримаєте, тому можете припинити читати, не турбуючи свої нерви та зайвий раз не критикуючи мене.

натомість:

>> Переша ознака того, що людина не розуміє те що вона говорить чи пише, це використання іноземних слів без перекладу

лол ))) дуже чудово, що ви тут відписалися. нє, серйозно. я все життя думаю: казати мені «cd-rom», чи казати «кд-пзп». тепер я, звісно, розумію, що IoC — це ІК, гг. я за книжку українською, і я щиро радий, що є якісь спроби перевести технічну літературу в україномовний сегмент

хах ))) 20-річний vb і його похідні, в різних його постасях, були і досі є свого роду флагманом для автоматизації роботи в вінді — wsh, office, msvs і, можливо, шось там в iis (це лише те, шо я можу пригадати). і іе щонайменше тоді підтримував vbs, можливо, виключно через те, шо не було потреби створювати нову мову після свого роду відкатки її в старих-старих версіях офісу ше до того, як хтось там почав шось казати, шо потрібно якийсь там w t f j s від нетскейпа. це не виправдовує пороки vb, само собою, але і не виправдовує js. а тут — смішний-смішний гугл з бухти-барахти, мовляв «от ми вам тут дарт придумали» ))

до чого тут DOM?

дійсно, нема

поправлю себе трохи: треба визнати, в джейквері гарно і зручно оверлоади віддизайнили, але ж якою ціною… ))

по-перше, бездумне та все ж дивне перевантаження — явна ознака поганого дизайну. по-друге, нормальна практика перевантаження методів (яке до ооп як такого відношення не має) спостерігається хіба у статично-типізованих мов, де правило найменшого здивування можна звести до мінімуму за грамотного проектування. а так, джс-ний сурогатний оверлоад методів у тому ж динамічному джс — то дуже і дуже зло, за яке все ж відривають руки, і роблять то лише з благородних міркувань. до речі, лише конструктор, який би теоретично міг бути замінений ArrayByLength, можна було би лишити як єдиний правильний. а все решта мало би бути лише через синтаксично красиве [a, b, ...]

еммм, як би це сказати: по лінку нема ніде жодних «хитрощів» ні по jQuery, ні чогось нового/неочевидного по JS. сенсу написання такого роду статей, очевидно, немає

Локально, в межах метода:

// Java, ослаблення до інтерфейсу
final Map<String, String> map = new HashMap<String, String>();

// C#, скорочений еквівалент Dictionary<string, string> map = new Dictionary<string, string>();
var map = new Dictionary<string, string>(); 

Глобальніше, в межах опису класу, а також чому var/auto підходять суто для методів:

// Java, ослаблення до інтерфейсу, тип поля описується самим полем, а не типом ініціалізатора
// до речі, так в Java можна (я шось не в курсах)? :D
private final Map<String, String> map = new HashMap<>();

// C#, syntax wtf? readonly var? а якщо ініціалізація в конструкторі, etc?
private readonly var map = new Dictionary<String, String>();

<> тут, по-моєму, у виграші. Якось так. )))

Scala не має відношення до віртуальної машини в такому контексті. І змінна не може бути нетипізована. Вона типізована, неявно. )

+ це дозволяє ослаблювати типи змінних, наприклад, до інтерфейсів (зокрема як це пропонує IntelliJ IDEA). var в C# використовується лише для локальних змінних (і не може використовуватися для опису мемберів класу, на що є очевидні причини: конкретизація типу поля; повна залежність від ініціалізатора), а `diamond operator`, якщо я правильно розумію, може використовуватися як і в методах, так і поза ними.

ггг ) ну дик, /d/(«e») --> null )))

знову ж таки, окрім RegExp, тип якого щонайменше у Chrome 7 (stable) чогось — function

і шо цікаво, що

typeof(/.*/) --> "function"
typeof(new Date()) --> "object"

:)

щодо першого, то я просто подумав, шо комусь тре було якось парсити тіло самої функції для crc/ше-чогось ну мож в якомусь мініфікаторі-обфускаторі :D

дякую, мені було приємно вас читати :)

1) ггг жесть, тікі шо перевірив )) тікі маю питання ше маленьке: чим саме така поведінка заважає? ) просто не віриться якось )
2) не читав тих спєк, але сама мова != фреймворк/сдк/ліба/етц завжди %))
3) саме таке рішення є доволі спірним, але, дійсно, досконаліша модульність в джс дійсно була би доречніша. н.б.: ніколи не розумів нашо закривати тег script парним йому якшо в ньому прописано атрибут src >_<

1) сімейство ієшок, якшо і має розбіжності в джс, то явно не у цьому, бо то й же таймер — то з window, а не з мови ;)
2) нє, ну фреймворк то інструмент, не мова
3) хєх, так «скріпт» у назві ж не випадковий, хоча це є платою за динамічність і можливість відривати кусні коду прямо в рантаймі хД
5) тут — та ))) кривувато виходить, на жаль )))
6) ну йомайо, то, шо нема стандартного об'єкта Thread, не робить джс іграшковим :)
8) в принципі, погоджусь

мені ше в записі об'єктів в джс інколи бракує посилання одного значення на інше значення при його декларації, але то вже таке, хатєлка така :red:

п.п.c. function(a, b) { return a > b; } надто довгий… хочу коротші лямбди

1) то, певно, через стандарт екми, чи де воно там лежить. наразі, єдине шо можу з подібного пригадати — порядок обходу по властивостях об'єкта в трейсманкі та в в8, якшо властивості починаються з цифри (точно не пригадаю, але трейсманкі робить це, здається, в порядку додаванні властивості до об'єкта — імхо, інтуїтивно...)

2) нє, це чи у не всіх мейнстрімових мовах так по суті, де часто навіть масиви — частина фреймворка )))

3) не бачу з цим суттєвих проблем, єдине шо згадується — непослідовна підгрузка скріптів динамічно в хромі

4) о, тут би приклад, будь-ласка (просто заради цікавості)

5) мотлоху там могло би бути досить, навіть якби нічого не наслідувались від Object — динаміка же, та ше й ооп

6) джс не має вбудованих примітивів для роботи з тредами (подібно до п.2.), тому тут нема на шо нарікати + є веб-воркери

8) ггг, воно там не потрібно навіть близько. мені цікаво, як би тоді інтерпретатор виконував різолв потрібного метода з переліку перегружених, якшо в той метод передаєцця різна (наприклад, замала для всіх варіантів) кількість аргументів — це ше більша чєпуха вийде, ніж реально непотрібний в джс with. по-друге, типи аргументів будуть ше більше ускладнювати пошук. по-третє, перевантаження призводить до більшої путанини зі своїми кортежами, і в ідеалі найліпше в складний метод передавати просто {} заповнений потрібними вхідними даними, після чого рефакторити це щастя стане набагато простіше (мало того, воно фактично є перегрузкою по суті). і 4: цікаво, яким би чином перегружений метод (функція) мав би бути записаний в звичайнісінький var o = {f: ???} де o.f є референсом на функцію (шось мені підказує, шо можна в джс написати якусь імітацію таких методів, опис яких був би суто декларативним)

9) які саме проблеми? тут можна розуміти «визначення» як створення, або як визначення типу об'єкта в рантаймі. угу, з 2-им є проблеми

п.с. на жаль, маю досвід тікі з клієнтським джс-ом

>> хоча й має ряд своїх недоліків

яких?