Live data from Hacker News

Why Custom Attributes in .NET Give Me Nightmares

blog.washi.dev

21–30 of 30 posts

Re: Why Custom Attributes in .NET Give Me Nightmares

#21
FWIW: When I come across reflection code it's often a smell, especially when written by a novice developer. Quite often there's a much simpler (and less fragile) way to do something. Reflection is a powerful technique with many gotchas; and the gotchas can quickly outweigh the benefits.

Re: Why Custom Attributes in .NET Give Me Nightmares

#22
post #9

FWIW, Custom Attributes in .Net are kind of a pain in geneal, powerful but painfull... Probably why JS still doesnt really have them in practice.

  FWIW, Custom Attributes in .Net are kind of a pain in geneal, powerful but painful
Why? What's kind of painful in general about them? They are just pieces of static data. You can abuse them, e.g. have some obscure logic somewhere, but you can abuse many things just the same (ahem, Reflection, excuse me), so this factor doesn't make a distinction.

  Probably why JS still doesnt really have them in practice.
Did you mean JS doesn't have TS decorators? Those are an entirely different beast.

Re: Why Custom Attributes in .NET Give Me Nightmares

#23
post #21

FWIW: When I come across reflection code it's often a smell, especially when written by a novice developer. Quite often there's a much simpler (and less fragile) way to do something. Reflection is a powerful technique with many gotchas; and the gotchas can quickly outweigh the benefits.

I used attributes for a serialization framework (long ago before any good ones existed for C#) and found they were exactly what I needed. The solution was easy to understand and reason about, consistent, even somewhat elegant (and I use that adjective cautiously as I've seen lots of code that was "elegant" but fragile). I agree with your forewarnings, but there are absolutely instances where it's the right tool for the job.

Re: Why Custom Attributes in .NET Give Me Nightmares

#24
Nightmares? Compared to other things we can encounter, .NET custom attributes are like a mild ocean breeze on a sunny day. Yes, their binary serialization depends on a functioning type system, and yes, type reference storage is not terribly efficient. But it rarely if ever poses problems in real projects.

Re: Why Custom Attributes in .NET Give Me Nightmares

#25
This isn't an article about creating or even using attributes; it's a fairly low-level deep dive into how they're implemented.

It's definitely nothing I've ever had to think about when using attributes but I can appreciate someone looking into this and making the case that they could be implemented better.

As for attributes themselves, what I've found is that languages without this facility tend to implement them anyway using whatever hacks they can. In C, this is typically done with macros defining constant values. In scripting languages, it's often done with comments.

Re: Why Custom Attributes in .NET Give Me Nightmares

#26
post #21

FWIW: When I come across reflection code it's often a smell, especially when written by a novice developer. Quite often there's a much simpler (and less fragile) way to do something. Reflection is a powerful technique with many gotchas; and the gotchas can quickly outweigh the benefits.

I used attributes for a serialization framework (long ago before any good ones existed for C#) and found they were exactly what I needed. The solution was easy to understand and reason about, consistent, even somewhat elegant (and I use that adjective cautiously as I've seen lots of code that was "elegant" but fragile). I agree with your forewarnings, but there are absolutely instances where it's the right tool for t…

Yes, and the attributes that TFA whines about are what make NUnit very powerful. [Values] on an enum argument creates useful tests.

That being said, when I started my current job I replaced some complicated reflection-based code with a dictionary of delegates. I also turbocharged a an ASP (.net 4.x) app's startup time by explicitly referencing each controller in startup code.

Re: Why Custom Attributes in .NET Give Me Nightmares

#27
post #18
post #4

Earlier quoted context omitted.

I would expect DLL parsing to be a one-off cost at assembly load time. Certainly that handles all the stuff detailed under "Assembly resolution". Assembly resolution is also recursive, so I would expect that to simplify "type tree traversal" by pre-stuffing all the types into a Dictionary. That also necessarily has the parser for all the "System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c…

Wait, I thought one project = one assembly, so you would never have "types in assemblies in the same project which the current assembly depends on". Should that be same solution instead of same project ?

Yes, sorry.

Re: Why Custom Attributes in .NET Give Me Nightmares

#28
post #26

Earlier quoted context omitted.

I used attributes for a serialization framework (long ago before any good ones existed for C#) and found they were exactly what I needed. The solution was easy to understand and reason about, consistent, even somewhat elegant (and I use that adjective cautiously as I've seen lots of code that was "elegant" but fragile). I agree with your forewarnings, but there are absolutely instances where it's the right tool for t…

Yes, and the attributes that TFA whines about are what make NUnit very powerful. [Values] on an enum argument creates useful tests. That being said, when I started my current job I replaced some complicated reflection-based code with a dictionary of delegates. I also turbocharged a an ASP (.net 4.x) app's startup time by explicitly referencing each controller in startup code.

It seems you didn't read the article. It's not whining about how people use or write custom attributes. It's whining about how they're implemented in the language.

And I wouldn't really describe it as whining, I thought it was an interesting article that rases valid points and suggests a solution.

Re: Why Custom Attributes in .NET Give Me Nightmares

#29
post #28
post #26

Earlier quoted context omitted.

Yes, and the attributes that TFA whines about are what make NUnit very powerful. [Values] on an enum argument creates useful tests. That being said, when I started my current job I replaced some complicated reflection-based code with a dictionary of delegates. I also turbocharged a an ASP (.net 4.x) app's startup time by explicitly referencing each controller in startup code.

It seems you didn't read the article. It's not whining about how people use or write custom attributes. It's whining about how they're implemented in the language. And I wouldn't really describe it as whining, I thought it was an interesting article that rases valid points and suggests a solution.

The 2nd half of the article is an explanation of the problem of reading enums referenced in attributes, specifically about how it impedes performance, which I am directly discussing, both in this thread and https://news.ycombinator.com/item?id=48373294

Seems you didn't read the article!

Re: Why Custom Attributes in .NET Give Me Nightmares

#30
post #29
post #28

Earlier quoted context omitted.

It seems you didn't read the article. It's not whining about how people use or write custom attributes. It's whining about how they're implemented in the language. And I wouldn't really describe it as whining, I thought it was an interesting article that rases valid points and suggests a solution.

The 2nd half of the article is an explanation of the problem of reading enums referenced in attributes, specifically about how it impedes performance, which I am directly discussing, both in this thread and https://news.ycombinator.com/item?id=48373294 Seems you didn't read the article!

The author is saying the .NET devs did a bad job implementing that, they are not saying you shouldn't use it. So you talking about using attributes is irrelevant to the article, it has nothing to do with developers using attributes nor how they do so.
Post reply on HN