я в js 5+ лет раньше юзал эти геттеры/сеттеры но ровно до момента, пока не потратил больше 4 недель на устранение баги а бага крылась в том, что в доке бибилиотеки не было написано, что сеттер меняет значение ещё одной проперти в true да и вообще не было написано что есть сеттер

проблема либы, а не языка

в название свойства...

Я БЛЯДЬ ДАЖЕ НЕ ПРЕДПОЛАГАЮ ЧТО ТАМ МОЖЕТ БЫТЬ ЧТО_ТО КРОМЕ ПРИСВАИВАНИЯ?

а вот в том то и дело, что нужно писать так, чтобы эти эффекты были бы незаметны, либо в крайнем случае хорошо задокументированны

такой себе подход

нет, понимать надо какие ленивые вычисления используются в той или иной либе

для разных либ это очень удобный функционал, для практического применения в проекте вне либы как по мне сомнительный. Можешь привести пример, чем это так удобно?

инкапсуляция реализуется в рамках класса через аксессоры. Аксессоры - это методы get set. Иногда первый называют аксессором, второй - мутатором. Там можно провести дополнительную проверку (кроме типа) - проверку значения на принадлежность диапазона (x > 0 && x < 3 ), а в случае, если нужно будет повемять условия, интерфейс метода не изменится и код менять везде будет не нужно

явное лучше неявного

проблема либы, а не языка

Поэтому в еслинты встраивают правила для не использования плохих частей языка

прокси-объекты вот много где есть

Я БЛЯДЬ ДАЖЕ НЕ ПРЕДПОЛАГАЮ ЧТО ТАМ МОЖЕТ БЫТЬ ЧТО_ТО КРОМЕ ПРИСВАИВАНИЯ?

значит надо предполагать :)

а вот в том то и дело, что нужно писать так, чтобы эти эффекты были бы незаметны, либо в крайнем случае хорошо задокументированны

А можно просто не использовать

если не использовать, то привет джаве - getProp and setProp

значит надо предполагать :)

ВОТ ИМЕННО! У меня там 10 присваиваний которые ничего не делают кроме присваивания В каком блядь из них что-то происходит?

инкапсуляция реализуется в рамках класса через аксессоры. Аксессоры - это методы get set. Иногда первый называют аксессором, второй - мутатором. Там можно провести дополнительную проверку (кроме типа) - проверку значения на принадлежность диапазона (x > 0 && x < 3 ), а в случае, если нужно будет повемять условия, интерфейс метода не изменится и код менять везде будет не нужно

это все понятно, но это реализуется и с помощью обычных getValue setValue. Мне нужен пример, когда это реально полезно делать через get set а не через обычные методы

А можно просто не использовать

а ещё можно всё на ассемблере писать, вот там уж всё настолько явно, насколько это вообще вохможно

а ещё можно всё на ассемблере писать, вот там уж всё настолько явно, насколько это вообще вохможно

Есть нормальные средства языка Нахера усложнять код для его пользователей?!

это все понятно, но это реализуется и с помощью обычных getValue setValue. Мне нужен пример, когда это реально полезно делать через get set а не через обычные методы

просто представь, что ты будешь использовать аксессоры как обычные свойства, разве не круто?

просто представь, что ты будешь использовать аксессоры как обычные свойства, разве не круто?

нет

"реально полезно" бывает разным. Если нужно писать энтерпрайз-код то это вон в к джавистам

и то там есть конвеншны на всякие xml-ники и dependency injection который мозги свернет

getter/setter между прочим одна из основ Kotlin

ты можешь вернуть не массив значений, инкапсулированных в классе, например, а Object.frezee(arr)

Есть нормальные средства языка Нахера усложнять код для его пользователей?!

ничего себе усложнение, вам синтаксис упростили, дали новые возможности, вохможности которые позволяют делать то, что без них было просто невозможным

jetbrains предпочли добавить их, а построже сделать в других местах.

а вы ещё возмущаетесь, что JS - это не Java

а computed properties типизировать нельзя?

например mobx, вроде крутая либа которую я люблю, но сколько гемора там из-за того что все observable и computed построенны на get/set, для передачи куда-то переменной нельзя просто ее передать, а надо всегда как-то боксить ее, иначе передашь только текущее значение а не observable, плюс в самом mobx из-за этого костыли, типа observable.map из-за того что для пропертей незадефайненных сначала getter не работает и отследить его не получается

можешь сделать свойство readonly, объявив только геттер

ничего себе усложнение, вам синтаксис упростили, дали новые возможности, вохможности которые позволяют делать то, что без них было просто невозможным

ЭТО НЕЯВНЫЕ ВОЗМОЖНОСТИ Это переопределение оператора присваивания!

ЭТО НЕЯВНЫЕ ВОЗМОЖНОСТИ Это переопределение оператора присваивания!

УЖОС ТО КАКОЙ

УЖОС ТО КАКОЙ

Блядь ты спецом весь тред проигнорил?

Сова, завязывай, тебя уже троллить начали

геттер и сеттер - это не что-то, что нужно обсуждать, это одна из основ ооп вообще. Их нельзя не использовать. Для публичных полей всего пара кейсов есть в ооп

геттер и сеттер - это не что-то, что нужно обсуждать, это одна из основ ооп вообще. Их нельзя не использовать. Для публичных полей всего пара кейсов есть в ооп

Блядь

геттер и сеттер - это не что-то, что нужно обсуждать, это одна из основ ооп вообще. Их нельзя не использовать. Для публичных полей всего пара кейсов есть в ооп

основа то она может и основа, только не в таком виде

ЭТО НЕЯВНЫЕ ВОЗМОЖНОСТИ Это переопределение оператора присваивания!

нет, оператор присвавания - это оператор присваивания и ничего более, const a = b; никаких неявные штуки не делает

нет, оператор присвавания - это оператор присваивания и ничего более, const a = b; никаких неявные штуки не делает

foo.bar = baz ТОЖЕ ПРИСВАИВАНИЕ! прикинь

никакой перегрузки оператора присваивания нет, а a.b = 1; - это уже другая конструкция

с помощью пропертей самый толстый use-case это вынос каких-то полей на верх

*на верхнюю сущность

например mobx, вроде крутая либа которую я люблю, но сколько гемора там из-за того что все observable и computed построенны на get/set, для передачи куда-то переменной нельзя просто ее передать, а надо всегда как-то боксить ее, иначе передашь только текущее значение а не observable, плюс в самом mobx из-за этого костыли, типа observable.map из-за того что для пропертей незадефайненных сначала getter не работает и отследить его не получается

Чего там надо боксить, чтобы обзервабл передался?

геттер и сеттер - это не что-то, что нужно обсуждать, это одна из основ ооп вообще. Их нельзя не использовать. Для публичных полей всего пара кейсов есть в ооп

ты путаешь подход в общем и конкретные реализации в языке. В js можно сделать и так и так, ООП от этого никак не постродает

никакой перегрузки оператора присваивания нет, а a.b = 1; - это уже другая конструкция

это AssignmentExpression

обзёрваблы это совсем уже крутое использование get/set

ты путаешь подход в общем и конкретные реализации в языке. В js можно сделать и так и так, ООП от этого никак не постродает

все изветные мне реализации примерно об одном и том же

для тех кто не боиться :) базовое это шорткаты и dirty-флаги

и computed , да

ты путаешь подход в общем и конкретные реализации в языке. В js можно сделать и так и так, ООП от этого никак не постродает

+

геттеры/сеттеры это как и ООП идея а реализация может быть любой не надо сюда тащить нативные из жс в жс так-то и классов нет и инкапсуляции тоже нет

Можно статический геттер замутить: Vector.Zero - возвращает new Vector(0, 0)

ты путаешь подход в общем и конкретные реализации в языке. В js можно сделать и так и так, ООП от этого никак не постродает

Точнее от геттеров и сеттеров ооп обычно и страдает)

геттеры/сеттеры это как и ООП идея а реализация может быть любой не надо сюда тащить нативные из жс в жс так-то и классов нет и инкапсуляции тоже нет

есть классы в ES6, а то, что они на прототипах - это детали реализации

есть классы в ES6, а то, что они на прототипах - это детали реализации

Класс который function ага

сахар над функцией != класс

Класс который function ага

детали реализации, оставленные для обратной совместимости

детали реализации, оставленные для обратной совместимости

очень важные "детали реализации"

сахар над функцией != класс

хорошо, а что по-твоему класс?

Чего там надо боксить, чтобы обзервабл передался?

Например class A { @observable name = 'A' render () { return <B name={this.name} /> // Передаст по значению и будет ререндерить A при каждом изменении name } } class A { @observable person = { name : 'A' } render () { return <B person={this.person} /> // Тут A уже не будет зависить от name, и при изменении будет только B перерендериться. } }

хорошо, а что по-твоему класс?

открой руби и сравни, что есть класс, а что функция или плюсы

сахар над функцией != класс

Что такое класс вообще сложный вопрос, изначально это была просто картинка объекта работающая в компайлтайме, а теперь это все, что угодно

сахар над функцией != класс

он выглядит как класс, плавает как класс, крякает как класс, значит это класс

он выглядит как класс, плавает как класс, крякает как класс, значит это класс

только вот он и как функция тоже

Например class A { @observable name = 'A' render () { return <B name={this.name} /> // Передаст по значению и будет ререндерить A при каждом изменении name } } class A { @observable person = { name : 'A' } render () { return <B person={this.person} /> // Тут A уже не будет зависить от name, и при изменении будет только B перерендериться. } }

Это было же вроде описано в best practices

может быть утка курицей или нет?

только вот он и как функция тоже

и то что это функция не исключает того, что это класс

только метод класса не должен терять this, а вот метод es6 класса очень даже может

и то что это функция не исключает того, что это класс

только вот ООП очень даже различает эти понятния

ERROR: S client not available

только метод класса не должен терять this, а вот метод es6 класса очень даже может

Хз, откуда инфа, что "не должен"?

иначе можно сказать, что в каком-нибудь питоне или C++ любой класс и объект, который перегружает () перестаёт быть классом/объектом

Это было же вроде описано в best practices

только это следствие того что все построенно на геттерах сеттерах, если бы это были функции как в том же кнокауте, то зависимость появлялось бы только при явном вызове name() а не при передаче name

только вот ООП очень даже различает эти понятния

Да?

Да?

лол

только вот он и как функция тоже

и объект, так как функция в JS - это тоже объект

Хз, откуда инфа, что "не должен"?

ну тогда нахуй вообще существуют нестатические методы?

иначе можно сказать, что в каком-нибудь питоне или C++ любой класс и объект, который перегружает () перестаёт быть классом/объектом

в плюсах, функция не становится классом класс с перегруженным () не становится функцией, хотя может мимикрировать

и объект, так как функция в JS - это тоже объект

да ну?) сарказм

ну тогда нахуй вообще существуют нестатические методы?

Кстати, знатный косячина, вытекающий именно из прототипов

да ну?) сарказм

ну да

лол

Класс вообще не очень удачная в нынешнее время идея

Можно лишь только принять

Класс вообще не очень удачная в нынешнее время идея

тренды ФП не меняют принципов ООП

Класс вообще не очень удачная в нынешнее время идея

опять начинается...

Класс вообще не очень удачная в нынешнее время идея

Чойта вдруг?

в плюсах, функция не становится классом класс с перегруженным () не становится функцией, хотя может мимикрировать

Плюсы к ооп имеют отношения даже меньше жавы

Плюсы к ооп имеют отношения даже меньше жавы

новый холивар-тред?

тренды ФП не меняют принципов ООП

Ну, фп вообще перпендикулярное ооп нечто

вспомни Objective-C

может быть утка курицей или нет?

Конечно, если утка реализует интерфейс курицы, то это утка И вообще почему одна и та же сущность не может быть разными вещами в различных обстоятельствах?

Конечно, если утка реализует интерфейс курицы, то это утка И вообще почему одна и та же сущность не может быть разными вещами в различных обстоятельствах?

понятно.

Чойта вдруг?

Слишком сильно ограничивают наши возможности, вон сколько всего хорошего без них в расте

вот да

раст

гуд

понятно.

Буква L в S. O. L. I. D.

нет сеттеров/геттеров

нет классов

типажи рулят

Буква L в S. O. L. I. D.

Ну вообще ты так как раз ломаешь принцип подстановки