Calling an Object with a Function

this code should be putting out the following -

at the co-ordinates specified. But of course it doesn’t. I have to admit that this is quite a complex thought process but I thought I had it right with the code. What am I missing?

Yikes!! I forgot to include the code - here it is -

var teenAge = {
	nickname:"Frisky Cat",
	age:14,
	x:50,
	y;50
	};
var octoGen = {
	nickname:"Pickleball Champ",
	age:76,
	x:50,
	y:200
	};
var purplePie = function(spryfactor)	{
	fill(140,120,30);
	textSize(25);
	text("She was called " + spryfactor.nickname + " when she was " + spryfactor.age, 20 + spryfactor.x, 	spryfactor.y)
	image(getImage("avatars/purple-pi",spryfactor.x,spryfactor.y	) 
	};

purplePie(teenAge);
purplePie(octoGen);

Looks like the main road blocks are syntactical. Have you tried running it through the linter? I’m seeing a misplaced ; and a missing ).

So OK I must admit that I did not run it through Linter but when I did, it picked up an error in Line 5 -
I had y;50 when it should have been y:50

  • but that is the only error displayed in Linter. Going through my code again this AM, when I’m a bit fresher than I was last night when I wrote the code, and looking for your comments, I found the following errors -
    text line missing ; at end
    image line missing ) after “avatars/purple-pi” and missing ; at end

for a total of 4 errors of which Linter only picked up one - but good news - with the 4 corrections I got the desired result with just 2 modifications -
I had to remove the 20 from (20 + spryfactor.x) to get the text to fit on the page
I had to reduce (textSize(25)) to 15 - again to make the text fit to the very limited horizontal space

but all is well since your suggestions and the modifications gave me what I wanted in the end - thanks for your help with this!

final graphic output -

Nice!

I forgot to ask in my last post, regarding the section below in quotes, whether Linter should have picked up all 4 errors rather than just the one

<< So OK I must admit that I did not run it through Linter but when I did, it picked up an error in Line 5 -
I had y;50 when it should have been y:50

  • but that is the only error displayed in Linter. Going through my code again this AM, when I’m a bit fresher than I was last night when I wrote the code, and looking for your comments, I found the following errors -
    text line missing ; at end
    image line missing ) after “avatars/purple-pi” and missing ; at end

for a total of 4 errors of which Linter only picked up one >>

Many syntax errors prevent other errors after the error to be seen because if the syntax is wrong, there’s no telling what after is right. For example, the linter doesn’t know a ; should be a :. It just knows that its wrong. You could have meant to end the statement there at which point something else was needed to be done instead of changing the ;. So once the linter hits an error like that, it just stops until you fix it.

So it’s entirely possible then that Linter could have identified all 4 errors had I used it properly - it identifies the first error - I fix that and run it through Linter again - it then identifies the second error - I fix that and run it through Linter again and so on … and in this fashion it could have picked up all 4 mistakes?

It could have picked up all 4 mistakes if it knew the right way to fix them. For example consider this code:

var x =
{
  x = 2
}

How many mistakes are there? You don’t really know without asking me, the person who wrote the code. The correct version of the code could be:

var x = 1
{
  x = 2
}

or it could be

var x =
{
  x: 2
}

or it could even be something as wild as

var x = 
{
  x = 2
} = x

It ultimately comes down to the parser - the internal code that reads the JavaScript code as text and translates it into recognizable instructions. When it hits a problem in that parsing process, it makes an assumption about what that problem might be based on the code its reading at the time but then has to stop because it doesn’t know how to continue. The behavior of all the remaining code could change depending on how the error is fixed.

Bear in mind that this is really only a problem with syntax errors. Those are the ones that block the parser from being able to move on through the rest of the code. Once you fix all the syntax errors and the code can be fully parsed, that’s when the linter can get a full understanding of the code and produce multiple errors/warnings at once.

Whew!! Thanks - I get it now. My current project is to get to know the arc function with its 6 parameters (x, y, W, H, starting angle, stopping angle) and I am playing with 3 arcs trying to get them nested within each other to resemble a rainbow. I thought this would be fairly easy but once again, nothing prints out. So Linter to the rescue! Linter tells me that my problem (or perhaps just the initial problem in light of our discussion) is in line 5 - parsing error: unexpected token arc - I don’t need help with the project itself. Rather, my question regards the Linter - line 5 looks fine to me - I don’t understand what Linter is trying to tell me.
Here’s the code -

strokeWeight(10);
stroke(255, 0, 0); //red
arc(200,200,360,360,180,360);
stroke(0, 132, 255 //blue
arc(200,210,340,360,180,360);
stroke(20, 140, 48); //green
arc(200,241,322,360,180,360);

This is actually a good example to continue with the parser discussion!

When a parser is parsing code it starts reading it from the beginning. As it goes through the code character by character, line by line, it looks to see what looks right and what looks wrong. If it finds something wrong, its usually because what it just found doesn’t match up with what it had just read up to that point.

If we look back to your semicolon error:

var teenAge = {
	nickname:"Frisky Cat",
	age:14,
	x:50,
	y;50
	};

the parser reads that a variable is being created, and then an object starts, and then name value pairs are being formed. As it reaches y;50 it knows this is an error because it knows that its inside an object definition. If y;50 was just out in the open, it would be valid code (valid code that doesn’t do anything, yet nevertheless valid), but since the parser knows its in the context of an object, it knows this is an error.

Something similar is happening with your new code. The parser is going through the code, reading individual function calls, getting to this point:

...
stroke(0, 132, 255 //blue
arc(200,210,340,360,180,360);
...

where it sees a stroke function call start. It reads the arguments of the stroke call: 0, 132, 255 … and then it sees a comment which it ignores, then continues with… arc. This doesn’t make sense because we’re still in the argument list of the stroke function call. There was no closing ) so could arc be another argument? No, because there was no , after 255. What is arc here then? The parser doesn’t know so it throws an error complaining about arc.

Now, the tricky part for you, the programmer, and the person who has to look at this error, is realizing that while arc is a problem, it may actually be something before that’s causing the problem. This is, again, a case where the parser doesn’t know the intention of the programmer. Is arc supposed to be an argument or is it a separate call and the programmer forgot the )? (Note that newlines and whitespace are largely ignored in much of JavaScript.) I can tell that you’re missing a ), but the parser doesn’t know that so it just throws an error at the point it had a problem - with arc - and leaves you to deal with it.

So the lesson here is, if the location of the error doesn’t look like an error, the error is very likely the result of something before it. :slight_smile:

1 Like

What a great explanation! Thanks for taking the time to lay it out so clearly. We’re so conditioned in this day and age to have everything handed to us that I simply
assumed that Linter was right about line 5 being the problem even though I saw nothing wrong with it. Now with the explanation of how the parser function works in Linter - no more assumptions! - I’ll be able to use Linter much more effectively.

1 Like