(NOTE: this topic was closed for no reason at all, so I'm made a new topic. There was no Scratch Team member who mentioned about the close, so do not complain that it has been rejected.)

(Also note that this is a topic that suggest to forbid users from saying this when expressing opinions in suggestions. Do not close this just because “it isn't a suggestion”. It is. Just please report to close this in case of another reason.)

Oh my gosh. I am tired of users saying this:

No Support. There's a workaround. You shouldn't be handing over on a plate to everyone. They shouldn't always get what they want. If the alternative is very easy, then it's never important in the first place. They should learn how to be experts, not kids for years.

Don't you realized that all of this is wrong? I got nightmares because of all these replies. I know there is a workaround, but that doesn't mean the block can't be added. For instance, this block:

go to x: () y: ()

can be easily worked around with this:

set x to ()
set y to ()

OR:

glide (0) secs to x: () y: ()

A workaround is an alternative for a block, not to get rid of it because it's simply pointless because the alternative is easy. What if the alternative is hard? You're expecting them to understand that quickly? How come you think it's wrong that you should be handing everything over on a plate to New Scratchers? Well, guess what, you are. You are handing them hard difficult work.

I mean, stamps could be easily replicate with clones. “Next costume” can be replicated with this:

switch costume to ((costume #) + (1)) // workaround is so simple, yet the original block still exists.

Why isn't go to and next costume and stamp removed then?

Because it doesn't matter if they are easily workarounded.

Why haven't you even requested the blocks to be removed anyway?

Maybe because the “next costume” block is popular, but what about the blocks that were rejected because of the workarounds? What would happen if the “previous costume” gets added? What if it gets popular? See, you never know what would happen. When the next costume was added, it got popular, right? What if it didn't exist and only costume switching? I'm sure someone must have suggested and users rejected it because of three blocks that can be connected together, right? But when it was added, it got popular. That demonstrates “change variable by ()”.

set [variable v] to ((variable) + ())

This is the workaround for the change variable by. You see that it's very easy, right?

Yet you say, “But it prevents you from having to drag two extra blocks!”

Then why did you just rejected the previous costume block just because of a workaround that required two extra blocks? You need to drag them, you know? That doesn't make sense. Besides, even if you say Scratch is just going to get slower, remember that you can't expect everything to go quick, they take time, you know?

I got a large headache of many users telling me “No Support. There is a workaround. No Support. There is a workaround. It's easy that this block shouldn't exist.”

This is causing me nightmares. So what if there is a workaround? You are expecting these users to be like Griffpatch in seconds. You are forcing 10 people to shovel an acre of dirt when you can use a bulldozer instead.

Remember that Griffpatch didn't learn everything in one minute. Before when he was a bit younger, he was new. He decided to learn about coding, and suddenly became successful.

I didn't know what “() mod ()” and “floor of ()” and “ceiling of ()” did when I first joined the site. Did that mean they had to be removed?

So why are they still here?

Take a look at this topic. It mentions that Scratch is like a house. High ceiling represent new programming. If you are going to burden users by saying “No Support, there is a workaround”, you are making the high ceiling go lower. Think of the low floor too. Some users who suggest stuff are New Scratchers, and they are doing it for New Scratchers. If you are simply going to burden this to make it difficult for New Scratchers, many people can't be started with Scratch ten, causing the low floor to go higher. Wide walls allow users to do whatever they want. Burdening can also cause wide walls to be shorter, thus shrinking and house and destroying the community.

If Scratch was a room, it would have a low floor, wide walls, and a high ceiling.

* Low floor: It should be easy to climb in and get started with Scratch - even for Scratchers who have no experience programming.

* Wide walls: Scratchers should be able to make all kinds of things with Scratch - not just animations and games, but news programs, science experiments - things we can't even imagine.

* High Ceiling: Even though it's easy for someone who is new to programming to get started with Scratch, it should still be possible to make complex stuff.

Because we have limited time and resources, new developments that make the program easier and more inviting for newcomers are a higher priority than adding advanced programming features. (Thankfully there are other graphical programming languages that are continuing to add powerful advanced features.)

We don't want to destroy the community. We want to improve it. Otherwise, Scratch 3.0 won't exist. In fact, Scratch won't even exist!

This is a introduction to programming, not a place to use stuff of things that never get added.

It's even a constructive recommendation on not to make posts like this:

Sixth Suggestion:
(Thanks to Tymewalk)

Stop saying this:

No support, there's a workaround.

The point of Scratch is to be a challenge, not just hand every block over to the user on a sliver platter. Users should work to get these scripts, not just have it done for them.

It's that last sentence especially that gets me angry. People just discard an idea because it “makes things too easy”.

The common response is “why do we have move () steps then”, but it goes much farther than that - why do we have “go to” if we can use “set x” and “set y”? Why use any of the pen stuff, you can replicate it with “stamp”? Why have clones, just make other sprites?

The answer is because not everything has to be challenging. So what if “real programming languages don't do that”? Scratch is supposed to be an introduction to programming, meaning that it's easier. And yes, there are cases where you have to say “no support”. But don't just say it because “it's not challenging enough”.

A block that calculates the sunset based on the user's given location? That's a little too far. A block that converts a “days since 2000” to real-time? That would be OK.

So please, take the time to read through suggestions before dissing them as “not challenging enough”.

(SOURCE)


See? You are making this website like a very complicated programming language.

If the block is easily workaroundable, but also necessary and helpful, it can still be added. Think about it. It can be helpful to New Scratchers. If it doesn't cause harm, go ahead.

Look at @Paddle2See's opinion about this:

I disagree. Just because somebody wants an easier way to do something does not mean that they don't see the point of Scratch. I have used old versions of Scratch that had no Trig functions and had no Lists, I was very happy to see those new blocks since it made it much easier to make the computer do what I wanted it to do - and the scripts became much cleaner. There were workarounds to both of those features, which I used until the blocks were available - but I was happy to adopt the new blocks when they were made available.

But it also must be realized that adding new blocks does make Scratch more “bloated” and harder to learn. One of the things that makes Scratch so easy for beginners to start working with right away is it's simplicity - and part of that simplicity is the relatively small number of blocks. The pros and cons of adding a new block must be - and are - weighed very carefully.

(SOURCE)

What @Paddle2See does it use the workarounds for the actual block arrives. I mean, cloud lists will be added, even though there is a way to replicate this thanks to cloud variables. Pen text blocks can be replicated. This block can be replicated:

<[] contains []? :: operators >

Guess what? It's part of Scratch 3.0.

Relax. You don't know who is behind the account who is suggesting something. Even @Paddle2See was a new user.

(NOTE: do not make any negative compliments about me suggesting this or call this a threat to the community. Scratch is for all ages. We want to help those all ages. Not stick on certain people to divide a community.)

I think the reason the other topic was closed was because it wasn't a suggestion…

FancyFoxy wrote:

I think the reason the other topic was closed was because it wasn't a suggestion…

Well, I'm sure it could have been more specific about it. I was 100% thinking they were suggesting not to allow users to post this.

But I disagree. Sure, if it's an extremely complicated workaround, AND the block shown just so happens to be a staple in other programming languages, then maybe it should be added (with a few exceptions). But if it's something completely made up because someone just “doesn't understand the workaround”, then it's not something that I feel needs to be implemented.

For example,

<() is divisible by ()? :: operators>

This would be a block that does not need to be implemented. Sure, you may not understand how to workaround this. However, using the mod workaround will allow you to both learn how to actually check to see if something's divisible by another thing, AS WELL AS learning what the mod block actually does (divides the numbers and outputs the remainder).

The “next costume” block doesn't need to exist, sure; but that being there makes people want a “previous costume” block to exist. However, it's not there; and they could figure out a way to workaround it themselves using other methods. If they figure it out, they just learned how to program, by thinking logically.

The lack of many blocks that people actually want may force people to attempt to workaround it using their own creative methods, which causes them to both learn to think logically and program at the same time. If simple blocks that could easily be worked around were added, then it would remove from that aspect a little bit, as nobody really needs to think to put that block into their code; they just can. If “previous costume” existed, nobody would need to use that workaround; but at the same time, they wouldn't know how to use that aspect of code inside of their projects anymore, and moving onto other programming languages, they may become more “dependant” on these simple workarounds until they realize they're just non-existent. What do you do then?

In short, I believe that saying “No Support” because there is a workaround is a perfectly viable reason to not want a suggestion implemented. If there is no way to recreate something, then sure, it might need a new block. If there's something in many other programming languages that can be worked around (albeit very complicated) and is not in Scratch, then sure, we might need a new block. But the majority of blocks do not need to see a new slot in Scratch.

WolfCat67 wrote:

But I disagree. Sure, if it's an extremely complicated workaround, AND the block shown just so happens to be a staple in other programming languages, then maybe it should be added (with a few exceptions). But if it's something completely made up because someone just “doesn't understand the workaround”, then it's not something that I feel needs to be implemented.

For example,

<() is divisible by ()? :: operators>

This would be a block that does not need to be implemented. Sure, you may not understand how to workaround this. However, using the mod workaround will allow you to both learn how to actually check to see if something's divisible by another thing, AS WELL AS learning what the mod block actually does (divides the numbers and outputs the remainder).

The “next costume” block doesn't need to exist, sure; but that being there makes people want a “previous costume” block to exist. However, it's not there; and they could figure out a way to workaround it themselves using other methods. If they figure it out, they just learned how to program, by thinking logically.

The lack of many blocks that people actually want may force people to attempt to workaround it using their own creative methods, which causes them to both learn to think logically and program at the same time. If simple blocks that could easily be worked around were added, then it would remove from that aspect a little bit, as nobody really needs to think to put that block into their code; they just can. If “previous costume” existed, nobody would need to use that workaround; but at the same time, they wouldn't know how to use that aspect of code inside of their projects anymore, and moving onto other programming languages, they may become more “dependant” on these simple workarounds until they realize they're just non-existent. What do you do then?

In short, I believe that saying “No Support” because there is a workaround is a perfectly viable reason to not want a suggestion implemented. If there is no way to recreate something, then sure, it might need a new block. If there's something in many other programming languages that can be worked around (albeit very complicated) and is not in Scratch, then sure, we might need a new block. But the majority of blocks do not need to see a new slot in Scratch.

Said what I wanted to say, but couldn't word.

FancyFoxy wrote:

WolfCat67 wrote:

- Snip -

Said what I wanted to say, but couldn't word.

I don't think I worded it all that well, I didn't proofread anything so I wasn't sure people would really understand what I was trying to get at. But I guess that I did do an alright job at doing so, so that's nice

Charles12310 wrote:

Don't you realized that all of this is wrong? I got nightmares because of all these replies. I know there is a workaround, but that doesn't mean the block can't be added. For instance, this block:

go to x: () y: ()

can be easily worked around with this:

set x to ()
set y to ()

This is untrue - simply try it with the pen, and you'll see why.

Charles12310 wrote:

A workaround is an alternative for a block, not to get rid of it because it's simply pointless because the alternative is easy.

I don't really understand this sentence. Scratch generally does not get rid of blocks because they were all added after careful consideration, and also because it's difficult to remain backwards-compatible when blocks are removed.

Charles12310 wrote:

What if the alternative is hard? You're expecting them to understand that quickly?

No, nobody is expecting people to learn quickly. However, people are expected to learn, because they came here to learn programming.

Charles12310 wrote:

How come you think it's wrong that you should be handing everything over on a plate to New Scratchers?

Well, because that's not a very good way to educate people.

Charles12310 wrote:

Well, guess what, you are. You are handing them hard difficult work.

I would hope so, because that's what programming is, and what learning programming is.

Charles12310 wrote:

I mean, stamps could be easily replicate with clones.

This is untrue, as clones are limited in number. And even if they weren't, it still would not be “easy” to replicate stamping, because it would be very difficult to get all the layering etc. right. It would also be significantly slower, because trying to manage clone despawning so as not to waste memory by keeping clones alive that were completely hidden would be very difficult.

There is a huge difference between drawing to a bitmap image and maintaining a set of sprites.

Charles12310 wrote:

“Next costume” can be replicated with this:

switch costume to ((costume #) + (1)) // workaround is so simple, yet the original block still exists.

Next costume is an incredibly commonly used block. It is used in every animation and every game that has animations. It is used to create slideshows. It is used to create help menus. Having a block that is used almost ubiquitously in graphical operations makes sense for a graphical programming language, even if it has an easy workaround. In fact, it's possible that e.g. a game engine would include a similar function, simply due to how useful it could be.

Charles12310 wrote:

Why isn't go to and next costume and stamp removed then?

• go to isn't removed because a) it's the simplest movement operation, and b) it has a huuuuuuge amount of use.
  
• next costume isn't removed because it is likely one of the most used costume blocks (sadly, I can't see the chart on scratch.mit.edu/statistics right now, but I wouldn't be surprised).
  
• stamp isn't removed because more general graphics operations are super useful for making more advanced projects, which most Scratchers that really get into programming will want to do.
  

Because it doesn't matter if they are easily workarounded.

Charles12310 wrote:

Why haven't you even requested the blocks to be removed anyway?

Why would anybody want to remove blocks? Most blocks in Scratch have a purpose, even if it's a pretty simple purpose. The only block I personally would support removing was already removed - forever if, which I never could get to work properly.

Charles12310 wrote:

I got a large headache of many users telling me “No Support. There is a workaround. No Support. There is a workaround. It's easy that this block shouldn't exist.”

If a block has a workaround that's super easy, then the only real reason to implement it would be if it was vastly useful. So if you find a suggestion of yours being criticized for being too easy to workaround, you might try defending it by demonstrating how useful it might be.

Charles12310 wrote:

This is causing me nightmares. So what if there is a workaround? You are expecting these users to be like Griffpatch in seconds. You are forcing 10 people to shovel an acre of dirt when you can use a bulldozer instead.

This is untrue. Education is almost necessarily a gradual process. Nobody learns to program without putting in the time to, well, learn. People who are new to programming should not be creating side-scrolling sandbox platformers, because there is no way that they have enough knowledge to do so.

Charles12310 wrote:

Remember that Griffpatch didn't learn everything in one minute. Before when he was a bit younger, he was new. He decided to learn about coding, and suddenly became successful.

Although I don't know Griffpatch, I can say that it is very likely he did not “suddenly” become successful. I would actually guess he went through a fair bit of pain to get to his level, given that he probably learned programming on less sophisticated tools.

Charles12310 wrote:

I didn't know what “() mod ()” and “floor of ()” and “ceiling of ()” did when I first joined the site. Did that mean they had to be removed?

…no, and I don't see why that's relevant. Those blocks don't have an easy workaround. They either require doing some mess with loops and variables, or by relying on some sketchy properties of inverse trig functions. (“sketchy” as in they will almost certainly generate floating-point error)

Charles12310 wrote:

Take a look at this topic. It mentions that Scratch is like a house. High ceiling represent new programming. If you are going to burden users by saying “No Support, there is a workaround”, you are making the high ceiling go lower. Think of the low floor too. Some users who suggest stuff are New Scratchers, and they are doing it for New Scratchers. If you are simply going to burden this to make it difficult for New Scratchers, many people can't be started with Scratch ten, causing the low floor to go higher. Wide walls allow users to do whatever they want. Burdening can also cause wide walls to be shorter, thus shrinking and house and destroying the community.

The low floor is meant to mean that you can start learning programming easily. It doesn't mean that you can instantly start making whatever you want - it means you can get started making things without much difficulty. So maybe you learn a little about keyboard controls, moving a sprite, and the touching color block, and suddenly you find that you have the knowledge to make a maze game.

Charles12310 wrote:

We don't want to destroy the community. We want to improve it. Otherwise, Scratch 3.0 won't exist. In fact, Scratch won't even exist!

I fail to see how the non-addition of any particular block will “destroy the community.” Scratch has grown a pretty big community with the blocks it currently has, so not including a new block should actually have no effect on the growth of the community.

Charles12310 wrote:

This is a introduction to programming, not a place to use stuff of things that never get added.

…what exactly does this mean? What do you mean it's not a place to “use stuff of things that never get added?” What do you even mean by “use stuff of things that never get added”?

Charles12310 wrote:

It's even a constructive recommendation on not to make posts like this:

Well yes, of course, generally a block is not necessarily bad just because it has a workaround. But if it has a particularly easy workaround, there needs to be a really good reason to add it (such as having a huge set of use cases, especially for beginner programmers, such as “next costume”)

Charles12310 wrote:

See? You are making this website like Whitespace. Whitespace is one of the most complicated programming languages in the world.

….

No. If we're thinking of the same “whitespace”.. - well, whitespace is a joke language, made just for fun. It's not particularly complicated - and it's far from the most complicated language in the world. I don't even see how it's relevant to this conversation. A more relevant example would be e.g. C, except Scratch is already so far from C that not adding a new block still doesn't bring it any closer.

Charles12310 wrote:

I mean, who cares if this block:

<() is divisible by ()? :: operators >

can be replicated by this:

<(() mod ()) = (0)>

That doesn't mean it can't be added.

Err… yes, it does mean it probably shouldn't be added. There's no reason to add a “divisible by” block, as modulo is much more general than a divisible by block - so it actually lets you do more, and adding an extra “divisible by” block would just bloat the language, as there are so few use cases for a “divisible by” block - especially for new programmers - that the few times it comes up modulo will suffice very well.

Also note that modulo is all you get in almost every other language, so knowing how it's used is a really good thing to know.

Charles12310 wrote:

If the block is easily workaroundable, but also necessary and helpful, it can still be added. Think about it. It can be helpful to New Scratchers.

..This is exactly correct. If a block is useful enough - useful enough to perhaps be considered “necessary,” than it should most certainly be included, even if it has an easy workaround.

Charles12310 wrote:

Look at @Paddle2See's opinion about this:

I don't really see how it's relevant… First of all, the first two sentences in his post were in response to somebody that made a quite bold assertion about specifically the people that want more blocks. The two examples he gives in his first paragraph are blocks that are seriously difficult to workaround. And his second paragraph is almost entirely contrary to your thread.

Charles12310 wrote:

This block can be replicated:

<[] contains []? :: operators >

Guess what? It's part of Scratch 3.0.

This block is also pretty difficult to workaround, especially to workaround efficiently. So it's not really a surprise that it's being added to Scratch 3

Charles12310 wrote:

Relax. You don't know who is behind the account who is suggesting something. Even @Paddle2See was a new user.

…and? What's your point here?

Charles12310 wrote:

Timers could also be replicated, the workarounds are easy, but not 100% accurate, yet the blocks are in the editor.

You just explained why those blocks are in the editor:

but not 100% accurate

I only really consider something workaroundable if it gives the exact same result as the actual block would. So timers are not workarounable.

Charles12310 wrote:

Set variable to can be replicated by:

change [variable v] by (() - (variable))

I'm pretty sure that this is false, due to the limitations of how numbers are stored. Besides, you always want to have the most generic operation available - and set is more generic than change.

Charles12310 wrote:

And change variable by can be replicated with:

set [variable v] to ((variable) + ())

This is true, but the fact is that every remotely sophisticated programming language (even as low-level as C) supports an “increment by” command. It would not help people learn to program to not include one of the most common commands in a programming language.

—

Overall, my position is basically this: “it's workaroundable” is, of course, not a good enough point to reject a block outright. But under the following conditions:

• The block is easily workaroundable
  
• The block is not overwhelmingly useful
  

I have to say that “it's workaroundable” is a pretty good point, and should be considered very seriously.

This is why all my block suggestions were replied to with “No support. There's a workabout. There will be no use for this block”, “what is the point of this block? It has a workabout. No support.” And “This is so easily workaboutable. I bet you didn't even think about looking for workabouts. No support.”
It ticks me off because they always say thinks like that. In fact, they don't even look at these sort of topics. Just saying:
“No support, there's a workabout.

The point of Scratch is to be a challenge, not just hand every block over to the user on a silver platter.
Users should work to get these scripts, not just have it done for them.”
Is just plain wrong.

First of all, Scratch is meant to be an introduction to programming, and so is other language such as Logo, NOT a Challenge. Users might have to workabout a block(almost all my projects use the first workabout of the forever if <> block), but also might need blocks added. Using the workabout can be tiring.

Overall, I like this topic. You should spread the word.

78ch3 wrote:

This is why all my block suggestions were replied to with “No support. There's a workabout. There will be no use for this block”, “what is the point of this block? It has a workabout. No support.” And “This is so easily workaboutable. I bet you didn't even think about looking for workabouts. No support.”
It ticks me off because they always say thinks like that. In fact, they don't even look at these sort of topics. Just saying:
“No support, there's a workabout.

The point of Scratch is to be a challenge, not just hand every block over to the user on a silver platter.
Users should work to get these scripts, not just have it done for them.”
Is just plain wrong.

First of all, Scratch is meant to be an introduction to programming, and so is other language such as Logo, NOT a Challenge. Users might have to workabout a block(almost all my projects use the first workabout of the forever if <> block), but also might need blocks added. Using the workabout can be tiring.

Overall, I like this topic. You should spread the word.

Yes. We should.

I have more headaches now. -_-

New Scratchers won't become experts anymore is this doesn't happen.

I'm going to not go in the forums for the rest of the day, so don't think I'm going to reply right away if you want to reply. I feel like nobody understood and that everything I say when I look at it the second time is pointless.

My opinion:
If someone says this:

badforumuser wrote:

No support, there's a workaround.

without saying what it is, that's bad. And unhelpful.
If someone, however, says this:

goodforumuser wrote:

No support: do this instead.

<not<(x) < (y)>>

That's fine, since they say what the workaround is.
However, sometimes if the workaround is really complicated and the block is really useful *COUGH COUGH* dictionaries *COUGH COUGH*, that shouldn't be a valid reason for no support.

Overall, this topic is fine, but it's not really trying to explain why someone might no support: it gives off a vibe of “I want absolutely every suggestion added ever forever!!”

Why is that contains block even there.

set [a v] to [2nd variable]
set [ b v] to [1st variable]
delete (all v) of [list v]
insert (b)at (1 v) of [list v]
<[list v] contains  (a)?>

PintOfMilk wrote:

Why is that contains block even there.

set [a v] to [2nd variable]
set [ b v] to [1st variable]
delete (all v) of [list v]
insert (b)at (1 v) of [list v]
<[list v] contains  (a)?>

It's being considered for inclusion in Scratch 3.0 But it is not final.

I was thinking they may add it, but change how lists work so it would also work with lists. Then they could get rid of the separate lists version of the block.

well, if there is a workaround, there is a workaround, are you saying we can't say there is an easy workaround?

I-Iz-A-Litten wrote:

well, if there is a workaround, there is a workaround, are you saying we can't say there is an easy workaround?

No, they're stating that you should not be allowed to not support a suggestion because of a workaround, apparently because it's annoying and gives them a headache?

WolfCat67 wrote:

I-Iz-A-Litten wrote:

well, if there is a workaround, there is a workaround, are you saying we can't say there is an easy workaround?

No, they're stating that you should not be allowed to not support a suggestion because of a workaround, apparently because it's annoying and gives them a headache?

Whaaaaaaaaat?
How is it annoying? If there is an easy workaround, just use that! And you should probably see a doctor if people saying “There is a workaround” gives you a headache.

Everyone here is missing the point by a mile. It's giving me a headahce reading all of these non-sequitur retorts. Sure, you've debunked the small issue in the one example they provided, but you haven't even begun chipping at their main point. Charles12310's point is that it's aggravating to see people deny Scratch expand at all because there are workarounds for a lot of things. My head hurts too much to remember any of my other points, so yeah. Stop being rude.

I already stated previously that you can't spoil a Scratcher by giving them every block and feature they would ever want. What happens when they want to go onto another language? They won't know a thing, because they got away with the workaround-able blocks in Scratch. Scratch is supposed to be easy, but not so easy it's not really educational anymore.
It's important to teach complicated stuff to Scratchers too, you know.

Ferociousfeind wrote:

Everyone here is missing the point by a mile. It's giving me a headahce reading all of these non-sequitur retorts. Sure, you've debunked the small issue in the one example they provided, but you haven't even begun chipping at their main point. Charles12310's point is that it's aggravating to see people deny Scratch expand at all because there are workarounds for a lot of things. My head hurts too much to remember any of my other points, so yeah. Stop being rude.

Rude? It's only constructive argument, really.

Also, we are not denying expansion of anything on Scratch. We are only denying CERTAIN expansions.

Ferociousfeind wrote:

Everyone here is missing the point by a mile. It's giving me a headahce reading all of these non-sequitur retorts. Sure, you've debunked the small issue in the one example they provided, but you haven't even begun chipping at their main point. Charles12310's point is that it's aggravating to see people deny Scratch expand at all because there are workarounds for a lot of things. My head hurts too much to remember any of my other points, so yeah. Stop being rude.

I fail to see how I “haven't even begun chipping” at the main point. If, for a given suggestion, any workarounds posted are either not good enough or otherwise irrelevant (i.e. the suggestion is good enough to be implemented despite having a workaround) then you should post to that suggestion's thread with that argument.