5 ms·
This article seems to be making up its own terminology and patterns. In JS, a getter is a function bound to a property that is called when that property is acce
by snek 8y ago
This article seems to be making up its own terminology and patterns. In JS, a getter is a function bound to a property that is called when that property is accessed. (mdn.io/getter) and a setter is a function bound to a property that is called when the property is set (mdn.io/setter). In JS there isn't any real differentiation you need to make between a function with 0 arguments, a function with 1 argument, and a function with N arguments. They're all functions with some arity that you can call.
- inglor 8y agoHey Gus, this actually does make some mathematical sense. See https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote-Duality https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Ke...
- snek 8y agoI'm not saying it doesn't make sense, just that it ignores existing terminology of the language, which just leads to confusion down the road.
- azangru 8y agoYeah, this is the OOP perspective on getters and setters. Andre talks from the FP perspective.
- masswerk 8y agoHowever, in JS they have a specific [read, established] meaning, in the OOP sense. [It's a term established in the language specification.]
- ponyfleisch 8y ago> [It's a term established in the language specification.] I'd say JS getters/setters are syntactic sugar for the OOP concept the author is talking about.
- masswerk 8y agoIt's the main mechanism in JS to define functional accessors, at least since ECMA-Script 3. Before this, the terms have been used loosely, as well, for explicit accessor methods (like in Java). [Edit] Correction: should have been, at least since ECMA-262 5th Ed.
- amelius 8y agoSetters have no equivalent in (pure) FP.
- com2kid 8y agoSaying console.log is a setter seems horrifically wrong, console.log abstracts out IO and doesn't necessarily mutate any state that is within the program. It leaves the happy confines of the program's abstraction/memory model and puts data out into The Real World. That all said, within the model being established by the author, everything does make sense, eventually, and the difference between IO output functions and setters, for the sake of the abstractions that the author builds, is non-existent.
- AzzieElbab 8y agoState monad?
- alangpierce 8y agoThe structure of the article is a bunch of definitions that build off of prior definitions, and I think it's best to just view the definitions as applying within the article and overriding any external existing definitions. It's a little unfortunate and unsettling the two of the early definitions (getter and setter) already mean something else in JS, but the terminology choice is trivial in a certain sense and doesn't affect the concepts laid out in the article. I did find it confusing at first, though. Maybe it could have used a disclaimer, or maybe the author should have chosen different terms (maybe "producer" instead of "getter" and "consumer" instead of "setter"?). I also find it unintuitive to call console.log a "setter", and "consumer" feels better to me.
- JeremyBanks 8y agoThis was something that tripped me up when I first started university math courses. In more elementary courses, concepts are few and simple enough that you have a fairly consistent set of terminology that applies everywhere. Then I cracked open Spivak's and other higher-level textbooks, and each one is defining its own mutually-incoherent terminology. It took a bit of adjusting, but local terminology is a lot more readable than if everybody tried to use universally-unambiguous language.
- aaaaaaaaaab 8y agoYeah. source/sink would have been a more appropriate terminology IMO.
- karmakaze 8y agoThere are also existing terms which are much more fitting, e.g. provider and consumer.
- staltz 8y agoAuthor here: the inspiration for this article came primarily from Erik Meijer and this talk https://www.youtube.com/watch?v=sTSQlYX5DU0 https://www.youtube.com/watch?v=sTSQlYX5DU0 where he talks a lot about Getters and Setters in Scala, although he's not focused on Scala (Erik has worked on C#, Haskell, and is now working on a new PHP-like language at Facebook).