Weaber: Dash: that’s the actual problem. I’m writing a reusable widget.
Tutwiler: It’s literlally The Problem.
Jeffress: Profsimm: pretty sure that’s been done without getters/setters
Burkin: Profsimm: “I’m writing a programming language” can be also considered a problem. It’s not a very useful one, of course, because you can’t infer mostly anything from that, and thus can’t really make much relevant comments about that.
Capozzi: Not that i’m as big a fan of fp as the rest of the people here, it sounds like your problem is that you’re writing the library code before the usage code, which ime is usually a bad idea
Rearick: Dash: that’s not my question. My question is having getters setters, what’s their right place
Jeffress: Profsimm: ah. the answer is “It depends”
Poleyestewa: Dekok: I have a panel widget with a title, position, size. I need to offer an API for people to read and set those. It’s literally impossible to be more specific.
Lickey: Profsimm: getter/setters don’t have much of a place in JS. They don’t play well with the rest of the language’s semantics, as I explained. You *can* still use them, of course, but it’ll lead to very weird behaviour when you interact with other JS code.
Kager: Profsimm: why would people have to read and set those?
Mensinger: Dekok: how is something that’s part of a language’s semantics not playing well with language’s semantics.
Besaw: Profsimm: regardless of FPism, they violate ***umptions JSers make about object properties and you can always use methods anyway. this is idiomatic see Date. so i’d recommend avoiding them.
Grafton: Dekok: extend is not part of a language’s semantics.
Kirchhoff: Dekok: defineProperty is
Bibo: Ah Dekok just another thing related to the previous discussion, I also found this blog post nice on the argument http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm
Trucchi: Profsimm: let me put it this way – getters/setters are still best used sparingly, because they’ll get broken in situations with prototypical inheritance, or if an object is copied. Also, if you’re using a setter to trigger a DOM update when a value is changed, it can make it tough to batch the updates later, which you may end up wanting to do
Curnow: Dekok: people would need to do it, so they can use the damn panel?
Feagley: Profsimm: reflection is part of the language’s semantics, and extend uses reflection. Reflection, as commonly used in JS, does not account for the existence of getters/setters, since they have been tacked on top of the language much later.
Jeffress: Profsimm: js has plenty of pieces that don’t work well together
Lian: Which is why JS now has many different reflections API nobody uses
Jeffress: The cl***ic example is “with”
Antle: Arguments was definitely awful :
Rancifer: Profsimm: imagine if python added a monadic bind operator. there might be a way to make something that kinda works, but it really wouldn’t fit in with how the language is written. unfortunately, JS has acquired many features like that and get/set is one of them.
Kerne: Honestly, you folks are less than useless. You’re actively wasting people’s time and wasting your lives by being here.
Jeffress: It’s for wasting time
Jeffress: I guess nobody told him to never wrestle a pig.
Wortinger: Sounds like they already knew the answer they were looking for and we were giving them a different answer :/
Czartoryski: Profsimm: getters and setters when used intelligently are fine, but they will cause the vm at least v8 to deoptimize that code
Clendaniel: Hannibal_Smith: I have now so many things on my reading list that I don’t know when I’ll have time to read that :/
Engelkemier: Uhm here I had the opportunity to make what I study clearer thanks to the discussion with some people
Trucchi: I don’t know why they got so worked up. There were a lot of reasons given for why they should be used sparingly, not just “because mutations are bad”