What the difference in implementation of these two programs ? I'm not getting the difference in the calling of the setter function in these two codes

Tell us what’s happening:
Describe your issue in detail here.

  **Your code so far**

// Only change code below this line
class Thermostat{
get temperature(){
  var C=5/9 * (this._T-32);
  return C;
set temperature(Celsius){
  this._T = Celsius * 9.0 /5 +32;
// Only change code above this line

const thermos = new Thermostat(76); // Setting in Fahrenheit scale
let temp = thermos.temperature; // 24.44 in Celsius
thermos.temperature = 26;
temp = thermos.temperature; // 26 in Celsius

Why does the code in the image below not work the same as the above ? What’s the issue with the line
temp = thermos.temperature(26); in the code in the screenshot below ?

  **Your browser information:**

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36

Challenge: Use getters and setters to Control Access to an Object

Link to the challenge:

In one you have

in the other you do

temp = thermos.temperature(26);
1 Like

I mean that the setter function accepts a parameter. So why calling it like a normal function does not give the correct result ?
Can you explain the mechanism of calling the setter function ?
Sorry for the incomplete explanation of my problem, I’m a newbie.

Notice the syntax used to invoke the getter and setter. They do not even look like functions. Getters and setters are important because they hide internal implementation details.

get and set are special keywords that provide an alternative to writing your own functions with something like

function getTemperature(){
function setTemperature(celsuius){
const temp = thermos.getTemperature();
1 Like

Yes, that can be confusing. A setter is a function, so why don’t we call it like a function?

The answer is rather unsatisfying - because that’s what they decided. In some languages you call getters and setters like functions and in some you treat them like regular properties but the language handles it behind the scenes for you, converting it into a function call invisibly in the background. JS chose the latter.

Why? Perhaps because (I think) Java does it that way.

There is a certain logic to that. They want you to think of it as just getting and setting a property. You don’t need to know that behind the scenes you are really assigning and retrieving an invisible, private property. This gives the person that built the class complete control on how you set and retrieve that property. You don’t need to know the details.

One advantage of this is that if I build a class with a “normal” member and a lot of code is built around it, then what happens if I suddenly realize that I need to control access to that? Do I change it to functions and then go back through all the code and change everywhere it is accessed? Or maybe I could make that member private, change the name slightly (like prepend with an underscore) and then add a getter and setter with the original name - the code would use that member the exact same way but the class would handle it the way it needs to. No one needs to know (unless they want to look at my class code) that I’ve changed it.

It also fits a little better how we think about this, I think. I just want to set the value on the property. All I need to know is the name of that property/member. I don’t want to have to look at the inner workings of the class to find out what is going on. In fact, in some cases, that may not even be an easy option. All I know is that there is a “temperature” prop and I want to access or change it. How do you change class props? Just like any other prop. Is it an actual prop I’m accessing or is it a setter/getter that is using an invisible private member? I don’t know and in a lot of cases, I don’t really care - I just want it to work.

But yeah, it is a little confusing. If you study some OOP, the logic may be a little more clear. JS isn’t true OOP, but it does borrow some of the patterns.


That means that I know that it’s a function call , JS knows it but I have to treat it like a prop bcoz JS is designed to work like that.

Got it! They’re functions but it’s to be treated like a prop as JS works like that.


Yeah, that’s basically it. You’re right that it looks a little odd, but there is a logic to it.

1 Like

The point is if the user of the API tries to set a property it calls a setter function instead of just modifying the property. Which lets you have internal logic for what should happen if a property is set.

class doorMan {
  constructor(age) {
    this._age = age;

  set changeAge(age) {
    if (this._age < 18) {
      console.log('You are not allowed to change your age');
    this._age = age;
    console.log('Happy Birthday');

  get age() {
    return this._age;

const discoPerson1 = new doorMan(16);
console.log(discoPerson1.age); // 16

discoPerson1.changeAge = 21;
console.log(discoPerson1.age); // 16

const discoPerson2 = new doorMan(20);
console.log(discoPerson2.age); // 20

discoPerson2.changeAge = 21;
console.log(discoPerson2.age); // 21

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.