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”