On Wed, Aug 11, 2010 at 7:42 PM, Ben Kloosterman <bkloo...@gmail.com> wrote:
> The issue with an attribute is everyone immediately preferred this at the > call site which looks pretty awkward for attributes eg > > 1) Why does the writer of the caller need to know , shouldn’t the > compiler be able to work that out . > > 2) Some of these attributes get pretty big ( eg serialization , IOC > ). > That's one issue. Another issue is that attributes can't be inferred, because the compiler does not (in general) know anything about their semantics. But worse than this: when attributes are used to encode type, we need a way to attach them to types and print them accordingly. In C#, an attribute cannot be introduced at a type, only at a type definition. The way you work around this is by introducing and using a typedef. The associated information is lost for pretty-printing purposes, exactly because it *isn't*a type. > Im not qualified to give an answer.. but I can observe that its very > annoying in C# ( the black magic we discussed ) of having stack created > value types , then passing them by ref and out and the system occasionally > boxing them eg to do a vcall on an interface or because there is a reference > from the heap. > Concur, but that issue is entirely orthogonal to the issues and limitations of attributes in CLR. Good topic, but not the same topic. shap
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
