Is storing info in unrelated attached properties a code smell?

I was just watching a "how-to" type WPF video called How Do I: Use Attached Properties to Store Extra Data in WPF, and it was describing what to do when you want to associate two pieces of information with a single control. If you want to put one piece of i开发者_如何学运维nformation in, they say to use the Tag property.

<Grid>
    <TextBox Tag="innerData">
</Grid>

Fair enough.

But then they say, "what happens if you want to store a second piece of data, say, an integer?" The solution, they say is to use an unused attached property.

<Grid>
    <TextBox Tag="innerData" Canvas.Top="55">
</Grid>

They say because it's in a Grid, no problem! I say "Bleh!" This strikes me as extremely nasty...and quite misleading to read. Is this common practice?

Yes, it is a smell.

I'm not sure if it is common -- I've never seen it before.

Frankly, I find Tag to be a framework-endorsed smell itself.

It's quick and easy but it's definitely preferable to define your own Attached Properties or custom control to handle these situations. This is the type of thing that's okay for prototypes or quick one-off apps but shouldn't be done if the code is going to have a real lifespan that will require maintenance down the road.

Not a best practice.

I am always of the opinion, code (including Xaml) is written to be human readable.

It would take quite a bit of research to figure out who is using that property, and for what.

This technique can be a real time-saver. Use of it tells you, "I shouldn't waste any more time studying these training materials."