The 
block does not contain the NAME of the object. Is name not a valid property? Why is that?
I know I can use 
type of approach, but the other reporter is so much clearer to use.
No particularly good reason. We inherited the OF properties from Scratch, and didn't want to make that list intimidating, and we really would have put all those things in MY in the first place because, you know, oop, and objects know their own properties, and if this sentence sounds incoherent it's because it reflects the underlying reality. :~)
You need to know the name of the object to use this block.
@bh, since when is the "name" of object intimidating compared to the rest of the properties already listed???
And it is getting tiresome to keep getting answers that claim Scratch lineage on one hand and "no we are different" on the other.
I think SNAP! is in an identity crises. I believe it should own its current state of maturity and cut ties with the Scratch nonsense. Leave the 8yr old's & their mentality behind and move on with the mature kids who are appreciating what Snap has to offer.
By the way, it is much more appreciated when the answer is:
- we know, we'll get to it
- it's on the list etc.
Sorry for my diatribe! Just hit a nerve I guess.
If you have some other handle on an object, like say ITEM 3 OF (MY CLONES), you can drop it onto the input slot of TELL.
No, no, it's not Name specifically. It's the huge long menu. I did say it's not a strong reason.
I have to say, sometimes nothing happens in some area because Jens and I haven't agreed about how to do it. For example, I think the use of the OF block to find sprites' methods has turned out to be confusing, and now that we have TELL, the latter should really handle message passing or RPC or whatever you prefer to call it. And then OF could be merged into MY. Jens, however, thinks that the way we use OF is beautiful and should be the main inter-sprite message handler. (Sorry, Jens, if I'm misrepresenting your view in detail, but I'm sure the essence of it was to give OF the sole license to report methods of another sprite.) This, I think, directs our immediate design efforts into things less likely to cause us to yell at each other, which neither of us enjoys.
As for the identity crisis etc., this comes back to what I just said on another thread: Why are we using a block language at all? Why don't we just teach Scheme, and maybe build a sprite package for it? Jens would probably give a somewhat different answer, but for me, it's the enormous explanatory power of a good visualization. I always like to explain that it took us three tries to get lambda exactly right, but then point to the list of blocks in the Vee demo and say that it's immediately obvious to any Scratcher what that picture is depicting, even if they've never thought about procedure as data before. Reason number 2, blocks are pretty unintimidating, which is super important if you're building a breadth course for people not into programming.
I think the strict either/or of eight-year-olds vs. mature kids misses out a large middle ground. The dozen or so kids who post on this forum all the time are not representative. We've (not me and Jens, but the BJC team) been working in New York City, with classes for 16-year-olds, plus or minus, in which many students can barely read. It's not that they're stupid; it's that they've been failed by their schools (in the sense that isn't about grades), plus in some cases they're recent immigrants from a Spanish-speaking region, so they can read Spanish but not English. Being Scratch-like in flavor is a huge advantage with that audience.
I don't mean to suggest, by the way, that we should do such-and-such because Scratch does. It's just that when you and others ask why something is the way it is, that's the answer; it's because of our history. Sometimes it frustrates me; Jens really wants to be Scratch-compatible with respect to pen colors, and I want to replace the current HSV-based system with a better one. I have the better one in a library, but I keep trying to talk Jens into making it the official color system rather than something you have to load. Jens, I guess, doesn't see a benefit to doing something other than what Scratch does in this instance. But my version isn't more "mature"; I think it'd be better for eight-year-olds too.
And, like it or not, apart from kids in high school classes, our audience consists largely of kids who come to us via Scratch. All else being equal, it's best to give them tools they're already familiar with.
I want to be able to put reporters in the set pen color to block
You can! In both slots.
I like of because you can put rings in the first input. You can do the same thing with tell, but I like of better. Something should be done about a partial menu though.
I mean in this block 
Why does it matter which block? Oh, because the other SET PEN block only controls one dimension at a time? Ah, I should solve that problem in the color library, then you can help me talk Jens into replacing the newish primitive SET PEN with mine. :~)
Edit: Wait, I already did!
ok, but how do I get the block
You run the dev version and import the colors library.
Can we have confidence that the colors library will survive 'dev' into 6.0 fairly intact? I much prefer it to 'set pen hsl'. HSL space has never seemed intuitively obvious to me.
Thank you! Yes, it'll be in the 6.0 release and onward forever.
Great! Any chance you'll update the block help, too? e.g. is 'RGB color' equivalent to 'pen '? I can read the JS, but am not sure what it's telling me.
The library blocks do have help, I think...
I am way behind on help screens. What I'd really like is to recruit a team of 12-year-olds, especially to update all the scalar function help screens with hyperblock examples.
Meanwhile, read this.