I tried creating a function inside a class, turns out the syntax for creating a function inside a class doesn’t require to use the keyword ~function~.
How is a noob supposed to compare getter-setter with a function inside a class?
I had to look up from this site:
Challenge: Use getters and setters to Control Access to an Object
Link to the challenge:
Hello!
You did exactly what was expected 
. Remember:
@skaparate
I am just concerned that I, coming from python and java background, am requiring too much time on this simple challenge and its frustrating.
What a noob who is coming from no programming background supposed to research anything if they don’t even know that something is wrong here!
I just want this to be more comprehensive to make fcc a better track.
I see your point, but maybe look at it this way:
The first thing should be the error on the editor/output (depending on what you wrote, of course). But assuming the student writes:
class Thermostat {
constructor(temp) {
this._temp = temp;
}
get function temperature() {
return temp;
}
}
The student would have to research what the error SyntaxError: unknown: Unexpected token, expected "(" (7:15) means.
This gives the student some knowledge about how the interpreter works (displays errors), knowledge about the language and improved her/his research skills (which is something we use a lot).
I may be wrong, of course, but I think the student would learn more like this.
Let’s wait for someone else’s opinion too .
@skaparate
There is a whole other section for Debugging, I think a beginner would think “I should not get ahead of myself and stick to the course so far”.
So you see its like a loop they would get into. What to do, research on your own or stick to the course? And they wouldn’t even get past this section without researching on there own, this would also make them think that ~this course is not reliable enough i should study from somewhere else ~
Also check this new post :
https://forum.freecodecamp.org/t/this-challenge-makes-no-sense/481679
Anyhow, thanks for replying though. 
Don’t create duplicate posts. Thanks.
Tell us what’s happening:
I think this is what my code is doing here
-While creating an instance of the class, setting the temperature to whatever doesn’t matter Celsius or Fahrenheit.
-With get function, convert the value to Celsius, even if it is already in Celsius, and return this value.
-With the set function, convert the value that we are getting from arguments to Fahrenheit and set it. Doesn’t matter if its already in Fahrenheit.
This makes no sense! The problem is not described correctly!
**Your code so far**
// Only change code below this line
class Thermostat {
constructor(temp){
this._temp = temp;
}
get temperature(){
return 5/9 * (this._temp - 32);
}
set temperature(celc){
this._temp = (celc * 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
// console.log(temp);
**Your browser information:**
User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36 OPR/79.0.4143.73
Challenge: Use getters and setters to Control Access to an Object
Link to the challenge:
Thermostat class should be instantiated with temperature in Fahrenheit. It should have temperature property. When temperature is accessed (getter), it should return temperature in Celsius. When temperature is set (setter), the value set will be in Celsius.
The point is - using getter and setter it doesn’t matter what unit is used internally. It could be even different one. As long as getter and setter will conform to these requirements internals can vary in many ways.
@sanity I don’t know what you understood from what I have written. My code works and it should not work. I am saying the language of the problem is not correct.
Same challenge. You only get one topic per challenge. Please don’t make duplicates… Thanks.
It doesn’t matter as long as you pick one. Valid solutions can be written with the temp stored in either F or C. There are two different solution approaches that are both valid.
The entire point is that getters and setters do not depend upon internal data representation choices.
From my understanding your code is doing what it should, so I tried to rewrite the requirements using different words…
Yeah, sometimes these challenges don’t make a lot of practical sense. They can seem odd and have a lot of “wait! why?” moments.
But:
-While creating an instance of the class, setting the temperature to whatever doesn’t matter Celsius or Fahrenheit.
No, the instructions are “The constructor accepts a Fahrenheit temperature.”
So, the constructor will receive in F. Where it doesn’t matter is that you can store it however you want, F or C (or K or R for that matter). You chose to store it as the constructor received it, in F. That is fine, I could make an argument that it would be better to store it as C since you will need to access it more that way, but it works either way.
With get function, convert the value to Celsius, even if it is already in Celsius, and return this value.
You stored it in F so it needs to be converted. If you had converted and stored in C in the constructor, then you wouldn’t need to convert.
With the set function, convert the value that we are getting from arguments to Fahrenheit and set it. Doesn’t matter if its already in Fahrenheit.
No, it does matter. The instructions are: “In the class, create a getter to obtain the temperature in Celsius and a setter to set the temperature in Celsius.”
You could have written it differently, where everything is C (or whatever). You could have written it to allow either F or C (which would have been more complicated, but doable.
But as the problem is given to you, the constructor accepts F and the getter and setter deal in C. Does that make sense in the “real world”? Maybe not. It’s a little odd. Is it the type of “strange requirements” you may encounter on the job? Yup.
If I were designing this module from scratch, it certainly wouldn’t work this way. But I didn’t design it. Sometimes we have to understand and build to other people’s specifications.
As to the description, I think it’s decent. Trust me, on the job, I’ve gotten much, much worse specs, with contradictions and gaping holes.
Im just trying to help report problems with the challenges what others may find difficult to understand. I can just move past this as I understood the lesson but I am making effort to report problems.
I think its not a bad thing to acknowledge someone’s effort.
Also combining posts for different thing and saying ~one post per challange~ is really rude. Is there a storage limitation for a simple text post?
Anyway ill not be making any new posts for reporting any issuse. Thanks.
I didn’t write the rule, I just enforce it.
You made two posts about the clarity of the instructions on this one challenge. I combined them. It wasn’t an admonishment or anything. I’m just being consistent with the rules. You’re still welcome to create topics about other challenges in the future.
I think it’s a reasonable rule. Some people end up creating a lot of simultaneous threads on the same challenge, creating confusion and clogging up the board. In theory, these lessons should be incremental and there should only be one or two new concepts so in the vast majority of cases, there shouldn’t be a lot of different questions, certainly few enough to be handled in one post.
I agree with what Jeremy did. And no one is getting down on you here, this is a friendly bunch. You just did something that we don’t like here so it got corrected. It’s no big deal.
The previous post was that the theory of the lesson has topics that have not been mentioned and taught yet.
And the other post was that the challenge’s language is not clear.
I don’t know how I can discuss both these things in one post.
OK, so we disagree on the semantics here. But now you know what the policy is. Maybe we can just not worry about debating moot points and move on?
And if you have a suggestion about how to improve a challenge, you can bring it up in the Contributors subforum.