5 ms·

I don’t think I’ve ever seen a useful “Getter” abstraction...

kbp 8y ago
You're always using a getter. It's just a question of what syntax your language provides for different ways of getting values, and how much they say about your implementation. Most people don't have a problem with getters and setters, they have a problem with writing pure boilerplate by hand. Languages like Python and Lisp save you from the boilerplate and don't provide a nicer syntax for the implementation-exposing way, so people don't generally complain about getters and setters in those languages, only in Java and C++ and things.
- weberc2 8y ago
  You misunderstood my post. I said I haven’t seen a useful getter abstraction. Not all data access is via a method nor is it always abstract. I specifically object to the useless abstraction, not the boilerplate (boilerplate is cheap).
  - kbp 8y ago
    I think we're coming at it from different angles. My point is that there shouldn't be any abstraction to write, and it should just be the way the language works. Primitive slot access in Java is not just a get/set interface, it's a get/set interface that also specifies implementation characteristics and what the code will be capable of in the future. It should be in the language so that you can have primitive slots, but it shouldn't be part of the interface you expose for your own modules, because adding pointless coupling to your code does nothing but restrict future changes. Languages should not provide an easy shortcut for writing interfaces like that. I don't view it as a useless abstraction, because I view it as the natural way of things. I view specifying that your get/set implementation is and always will be implemented as slot access to be uselessly sharing implementation details that does nothing but freeze your current implementation strategy. I think a better question is when that abstraction gets in your way. When does it bother you that nullary functions aren't reading memory locations? Why do you feel that's an essential thing to specify in your public interface, as a default? There's nothing stopping you from writing code in Python and mentally modelling o.x as slot access, because it follows the interface you want from it. If you only care because it's something extra you have to do, then that's what I meant by boilerplate. I think it's a misfeature of Java's that it presents a model where that's something extra you have to do.
    - weberc2 8y ago
      > My point is that there shouldn't be any abstraction to write, and it should just be the way the language works. I understand your point, but I think you misunderstand what "abstraction" means. "abstraction" doesn't mean "function" (although functions are frequently used to build abstractions), and if you have "dynamic properties" (or whatever you'd like to call them) a la Python, then you're still abstracting. My point is that abstracting over property access (regardless of property-vs-function syntax) is not useful, or rather, I'm skeptical that it's useful. > I think a better question is when that abstraction gets in your way. When does it bother you that nullary functions aren't reading memory locations? Why do you feel that's an essential thing to specify in your public interface, as a default? There's nothing stopping you from writing code in Python and mentally modelling o.x as slot access, because it follows the interface you want from it. I think this is a good question, because it illustrates a philosophical difference--if I understand your position correctly, you'd prefer to be as abstract as possible until it's problematic; I prefer to be as concrete as possible until abstraction is necessary. There's a lot of mathematical elegance in your position, and when I'm programming for fun I sometimes try to be maximally abstract; however, when I'm building something and _working with people_, experience and conventional wisdom tells me that I should be as concrete and flat-footed as possible (needless abstraction only makes it harder to understand). To answer your question, that abstraction gets in your way all the time. The performance difference between a memory access (especially a cache-hit) and an HTTP request is several orders of magnitude. If you're doing that property access in a tight loop, you're wasting time on human-perceivable timescales. While you can "just be aware that any given property access could incur a network call", that really sucks for developers, and I see them miss this all the time (I work in a Python shop). We moved away from this kind of "smart object" pattern in our latest product, and I think everyone would agree that our code is much cleaner as a result (obviously this is subjective). TL;DR: It's useful to have semantics for "this is a memory access", but that's unrelated to my original point :)
      - deleted 8y ago
        [deleted]
      - deleted 8y ago
        [deleted]
westoncb 8y ago
getArea() { return this.width * this.height; } getIcon() { // if icon hasn't been loaded, load it return this.icon; }
- weberc2 8y ago
  Those aren’t abstractions... Also, I’m not arguing that you can’t contrive an abstraction around a getter, I’m arguing that it’s useful to do so (so please spare me contrived examples!).
Misdicorl 8y ago
It's frustrating to read this thread and your comment kind of crystallized this for me so I'll respond to you. Using an array without having to (manually) calculate the size of the objects contained within is like the major triumph of OO. This is a getter that you almost certainly use constantly. Please try to consider your statements and potential counter factuals before spraying nonsense into the void
- patrec 8y ago
  > Using an array without having to (manually) calculate the size of the objects contained within is like the major triumph of OO. I've used arrays in countless OO and non-OO programming languages, and I do not recall ever having to manually calculate the size of objects contained therein – what are you talking about? Only C requires crap like that, but precisely because it doesn't have first class arrays.
  - patrec 8y ago
    Downvoters, care to elaborate what you think is wrong with the above? Literally even fortran can do better than size_t len_a = sizeof(a)/sizeof(a[0]); or my_pseudo_foo_array = (foo*) malloc(len * sizeof(foo));
    - Gibbon1 8y ago
      You're not wrong. Even BASIC was better than this.
- Ma8ee 8y ago
  Watch your tone!
- weberc2 8y ago
  > Please try to consider your statements and potential counter factuals before spraying nonsense into the void My claim was that getter abstractions as described by the GP (abstracting over the “accessed from memory” implementation detail) are not useful. Why do you imagine that your array length example is a reasonable rebuttal?
mpweiher 8y ago
HTTP GET :-)

kbp 8y ago

You're always using a getter. It's just a question of what syntax your language provides for different ways of getting values, and how much they say about your implementation. Most people don't have a problem with getters and setters, they have a problem with writing pure boilerplate by hand. Languages like Python and Lisp save you from the boilerplate and don't provide a nicer syntax for the implementation-exposing way, so people don't generally complain about getters and setters in those languages, only in Java and C++ and things.

weberc2 8y ago
You misunderstood my post. I said I haven’t seen a useful getter abstraction. Not all data access is via a method nor is it always abstract. I specifically object to the useless abstraction, not the boilerplate (boilerplate is cheap).
- kbp 8y ago
  I think we're coming at it from different angles. My point is that there shouldn't be any abstraction to write, and it should just be the way the language works. Primitive slot access in Java is not just a get/set interface, it's a get/set interface that also specifies implementation characteristics and what the code will be capable of in the future. It should be in the language so that you can have primitive slots, but it shouldn't be part of the interface you expose for your own modules, because adding pointless coupling to your code does nothing but restrict future changes. Languages should not provide an easy shortcut for writing interfaces like that. I don't view it as a useless abstraction, because I view it as the natural way of things. I view specifying that your get/set implementation is and always will be implemented as slot access to be uselessly sharing implementation details that does nothing but freeze your current implementation strategy. I think a better question is when that abstraction gets in your way. When does it bother you that nullary functions aren't reading memory locations? Why do you feel that's an essential thing to specify in your public interface, as a default? There's nothing stopping you from writing code in Python and mentally modelling o.x as slot access, because it follows the interface you want from it. If you only care because it's something extra you have to do, then that's what I meant by boilerplate. I think it's a misfeature of Java's that it presents a model where that's something extra you have to do.
  - weberc2 8y ago
    > My point is that there shouldn't be any abstraction to write, and it should just be the way the language works. I understand your point, but I think you misunderstand what "abstraction" means. "abstraction" doesn't mean "function" (although functions are frequently used to build abstractions), and if you have "dynamic properties" (or whatever you'd like to call them) a la Python, then you're still abstracting. My point is that abstracting over property access (regardless of property-vs-function syntax) is not useful, or rather, I'm skeptical that it's useful. > I think a better question is when that abstraction gets in your way. When does it bother you that nullary functions aren't reading memory locations? Why do you feel that's an essential thing to specify in your public interface, as a default? There's nothing stopping you from writing code in Python and mentally modelling o.x as slot access, because it follows the interface you want from it. I think this is a good question, because it illustrates a philosophical difference--if I understand your position correctly, you'd prefer to be as abstract as possible until it's problematic; I prefer to be as concrete as possible until abstraction is necessary. There's a lot of mathematical elegance in your position, and when I'm programming for fun I sometimes try to be maximally abstract; however, when I'm building something and _working with people_, experience and conventional wisdom tells me that I should be as concrete and flat-footed as possible (needless abstraction only makes it harder to understand). To answer your question, that abstraction gets in your way all the time. The performance difference between a memory access (especially a cache-hit) and an HTTP request is several orders of magnitude. If you're doing that property access in a tight loop, you're wasting time on human-perceivable timescales. While you can "just be aware that any given property access could incur a network call", that really sucks for developers, and I see them miss this all the time (I work in a Python shop). We moved away from this kind of "smart object" pattern in our latest product, and I think everyone would agree that our code is much cleaner as a result (obviously this is subjective). TL;DR: It's useful to have semantics for "this is a memory access", but that's unrelated to my original point :)
    - deleted 8y ago
      [deleted]
    - deleted 8y ago
      [deleted]

westoncb 8y ago

getArea() { return this.width * this.height; } getIcon() { // if icon hasn't been loaded, load it return this.icon; }

weberc2 8y ago
Those aren’t abstractions... Also, I’m not arguing that you can’t contrive an abstraction around a getter, I’m arguing that it’s useful to do so (so please spare me contrived examples!).

Misdicorl 8y ago

It's frustrating to read this thread and your comment kind of crystallized this for me so I'll respond to you. Using an array without having to (manually) calculate the size of the objects contained within is like the major triumph of OO. This is a getter that you almost certainly use constantly. Please try to consider your statements and potential counter factuals before spraying nonsense into the void

patrec 8y ago
> Using an array without having to (manually) calculate the size of the objects contained within is like the major triumph of OO. I've used arrays in countless OO and non-OO programming languages, and I do not recall ever having to manually calculate the size of objects contained therein – what are you talking about? Only C requires crap like that, but precisely because it doesn't have first class arrays.
- patrec 8y ago
  Downvoters, care to elaborate what you think is wrong with the above? Literally even fortran can do better than size_t len_a = sizeof(a)/sizeof(a[0]); or my_pseudo_foo_array = (foo*) malloc(len * sizeof(foo));
  - Gibbon1 8y ago
    You're not wrong. Even BASIC was better than this.
Ma8ee 8y ago
Watch your tone!
weberc2 8y ago
> Please try to consider your statements and potential counter factuals before spraying nonsense into the void My claim was that getter abstractions as described by the GP (abstracting over the “accessed from memory” implementation detail) are not useful. Why do you imagine that your array length example is a reasonable rebuttal?

mpweiher 8y ago

HTTP GET :-)