General Meal Maker question

My question is pretty simple and pretty complicated at the same time. What are we supposed to learn from this project? I created a bunch of empty getters and setters (so, after reviewing the lessons 400 times I still don’t understand the actual point of them) and then I just literally did what each step said and that is it. I tried thoughtfully processing each step and have even done this project 4 times and still just don’t feel like I learned anything.
What are setters/getters?
Do I need them even if they are just going to be empty?
What is the point of the get Courses method if we are never going to call it?
Why did I add the _ before courses if everything the steps tells me to do uses ._courses and never a getter or setter?
What is the point?!

They’re definable functions that set (“setters”) or retrieve (“getters”) attributes of objects you’ve created in JS.

If they’re empty, probably not - you can retrieve the object attributes directly regardless of whether there’s a getter. (Kind of an “implicit” getter by default.)

The getter / setter is useful for controlling how code outside of your custom object can interact with class attributes, or if you want to modify how the attribute(s) gets returned when called.

One presumes the point is to introduce you to the convention of using _ to denote private code. JavaScript doesn’t enforce any notion of private, though, hence why you can still directly access _courses.

Presumably to reinforce / introduce the basics of object definition? :slight_smile:

Er, setters and getters are not methods. That’s why we can assign a value that will be pushed to an array. The setter invokes an internal method. It is not the method.

Getters behave like methods, so one can see where this is confusing given we’ve just stipulated that it is not a method.

How many methods do you know of that refuse to accept arguments?

How many methods do you know of that can accept only one argument?

Getters cannot accept any arguments; setters can only accept a single argument. Clearly, there is some internal mechanism in play.

A dominant term in hardware programming is, “interrupt”.

Consider a get request as such a one. It ties up that channel and gives enough time to set it before it can be requested again.

Sure, if you want to argue over the semantics I believe they’re more akin to bindings - you define the get / set to bind a function to an object property.

Ultimately, though, they are still blocks of code you implement as required, and look very much like a function. Hence my decision to refer to them as such, to avoid complicating things or making an already confused OP even more so. :slight_smile:

1 Like

Which is how I am coming to understand it. Out of confusion comes order, and deeper understanding.

Semantics aside, it’s still our mission to demystify this concept, and if we trip a couple times along the way, well that will be par for the course.

Is the binding between set and get meaningful, or purely an asynchronous, made you look!, to tie it up?

A setter doesn’t query a property value before changing it, so that means (hypothetically) a getter can format the return value any way preferred by the author and have no bearing on the setter. Well, when we thread all this together, that is.

Any more insights, since we have this ball rolling?

Test the effect of template literals on setter

 > obj = {
       _prop: 'value',
       get prop() {
           return `This is, ${this._prop}`;
       },
       set prop(newProp) {
           this._prop = newProp;
       }
   }
<- {_prop: "value"}
 > obj.prop
<- "This is, value"
 > obj.prop = 'new value'
<- "new value"
 > obj.prop
<- "This is, new value"

This still points to the setter tying up the getter so it cannot be accessed. Speculation moving toward valid hypothesis.


Another problem I see with using a template literal (or string representation) in a getter is when the value is needed for other computations or composition. How do we strip away the superfluous appendages (and restore the original data type)?

This goes to my past ramblings about returning only data from a getter. We can write methods to represent the data and access the getters from them.

obj = {
  _prop: 'value',
  get prop() {
    return this._prop;
  },
  set prop(newProp) {
    this._prop = newProp;
  },
  repr () {
    return `This is, ${this.prop}`;
  }
}