I’ve just read about attributes and RTTI in Delphi 2010. As someone who has used RTTI extensively and looked at reflection in .NET enviously, I can say I’m really looking forward to playing with the new RTTI model.
As for attributes, I’m sure a whole new array of interesting ways of doing certain things is going to be possible. There are currently lots of tools and frameworks which use RTTI to do certain things. Up until now, one of the main drawbacks to this was you could only work on published properties and methods.
One example that comes to mind is a small tool supplied with a third party component that prepares Delphi components and classes for use in a scripting solution. This tool works great, and parses classes to produce the boiler plate code needed for setting up the runtime environment for scripting. Unfortunately, it can only work on published properties and methods. If you want to expose any public properties, you have to do it manually.
These kind of things excite me more than IDE enhancements or ribbon controls. Having said that, I hope the IDE keeps up with these new compiler innovations. Does code completion still work with custom attributes for example?
Posts
6 comments:
Here is another post on attributes in Delphi 2010 with more examples.
http://wings-of-wind.com/2009/08/17/rad-studio-2010-review-9-%E2%80%93-attributes-the-new-rtti-and-db-access/
Yeah, it keeps getting better the more info comes in :-)
Glad they finally got your heart racing - I was happy by the time I saw IDE insight and IOUtils but I guess we all have our threshold :-)
Btw, the touch stuff looks awesome too - now I just need to find a place to use it!
Attributes. Very good feature, I agree. It took a minute for me to get my head around it. But, as soon as I figured it out, I could see real benefits to it. And, the possibilities of its usage are endless. It also meets the criteria of what I see as a "really" good feature (something that is useful to everyone).
And now you got what you wanted with the "new technology" feature, and I got what I wanted in IDE/Productivity enhancements. So I guess a good release is one that balances the two. Thus, giving the release a more broad appeal to more purchasers of a Delphi upgrade.
If EMB could solve the breaking code issue (maybe it's just not possible), and supply better tools to help the migration from one release to another, then upgrading might happen more regularly. And the company can realize greater revenues, thus have more resources available to improve the product. It's a Win-Win.
As someone who knows people who initially were very excited about attributes in .NET, I can only hope that the implementation in native code avoids the biggest pitfall encountered in .NET - performance degradation.
The previously fixed implementation of "published" visibility in the VCL was limited, but afaik was also still very efficient.
As for the dilemma of publishing properties and methods that are only public, I don't wuite understand why you didn't simply publish those public methods... as far as the code visibility was concerned it is exactly the same, you just make those public members available to the code that expects/needs them to be published.
It would actually be less work than having to "tag" them with an attribute.
On that note, I also hope that the Win32 implementation allows us to tag BLOCKS of members with an attribute, in the same way that we can already mark a whole swathe of members as "published" by the addition of that one simple, clear keyword at the appropriate place.
The proliferation of attribute declarations in .NET code is one of the great contributors to the unreadably messy nature of that code imho.
It would actually be less work than having to "tag" them with an attribute.
Becuase in this way, you can apply ,more than just one attribute to the method, class or property, and how would you mar a method to have the "Persistent" attribute with only published?, you can't.
But you can't (with the current syntax) apply an attribute to more than one member.
If "persistent" is the only attribute you want to apply to 10 members, that requires 10 attribute declarations, where previously it required only 1.
Hence = more work.
And I'd be curious if anyone could ever sensibly make a case for marking a METHOD as persistent.
Pre-empting the answer: "for the same reason you would mark them as published".
Wrong.
"published" implies nothing about intent, it just means increase the visibility - literally, publish the RTTI. THat CAN be used for persistence - as in the case of properties - but can be useful for other things, but in the case of methods I don't think it ever means "persistent".
Post a Comment