Accept reporters in property field of sensing_of block

[DanFessler]

I had a PR for this in scratch-flash (scratchfoundation/scratch-flash#1250) that was closed due to it being put on maintenance mode. I'd like to restart that discussion here for Scratch 3.0

Proposal

Accept reporters to be dropped on the PROPERTY field of the "sensing_of" block

Argument

For the same reasons a user might want to programmatically define the sprite you'd like to access in the OBJECT field, it is similarly useful to programmatically define the PROPERTY you'd like to access. From the perspective of the VM, this behavior should be 100% backwards-compatible with scratch 2.0 projects (it's already possible with manual editing of your project file)

[Clark-E]

I think that’s a great idea!

[mrjacobbloom]

cross-linking with #1199 (comment)

[towerofnix]

Going to pull in some comments from my closed pull request, just so they're here for convenient reference:

Note that the property dropdown now accepts blocks. That's not intentional - it's just that I reused most of the code for the object dropdown. I'm not sure how to make it a "square" dropdown (i.e. one which does not accept blocks). In my opinion, letting it accept blocks is a good thing anyways, since it allows and encourages dynamically accessing variables (or even ordinary attributes, like "x position" and "direction"). The argument against it is that an unfamiliar user might try placing a block such as "volume" into that dropdown, and then be confused as to why it always returns 0. But I think that any such user would quickly figure out the error they made; I think the functional benefit greatly outweighs the minor potential difficulty.

---

Any thoughts on the code which would be needed to implement this, then? The only other dropdown which is not-droppable and dynamically-filled is the variable/list/message dropdowns, but these are all implemented in ways which rely on accessing variables either specific the currently selected sprite or shared across all sprites. (The code for doing so is in scratch-blocks, which indeed does not have access to other sprites the same way the GUI and VM do.)

And I know the Scratch Team is not obligated to, but I request that you consider the paragraph I've quoted [above]. And, by necessity, I request that it be considered soon (i.e. not be backlogged): making the block droppable after the release of 3.0 will break many 3.0 projects, but making it before will break virtually none, due to so few existing.[*]

---

PS, several existing projects would be broken by not making the input droppable. The fact is that unless LLK/scratch-vm#1030 - a rather colossal task nobody has gotten anywhere seriously far with since its creation in April - is resolved, any blocks which use hacked arguments will break. Several projects do place arguments inside the "of" block; while I don't have any statistic, it's one of the more common uses of hacked arguments that I've seen. Not making the input droppable means these projects will break.

[*] Potential exception being if/when scratchfoundation/scratch-parser#47 is implemented - changing the type of the slot to an input rather than a field would be possible and harmless then.

The PR was closed for technical reasons and because the existing solution's side effect of making the input droppable was not acceptable.