I've heard a lot about the new/improved RTTI capabilities of Delphi 2010, but I must admit my ignorance...I don't understand it. I know every version of Delphi has supported RTTI...and I know that RTTI (Runtime Type Information) allows me to access type information while my application is running.
But what exactly does that mean? Is Delphi 2010's RTTI support the same thing as reflection in .NET?
Could someone please explain why RTTI is useful? Pretend I'm your pointy haired boss and help me understand why RTTI is cool. How might I use it in a real-world application?
RTTI in Delphi is still not quite as full-featured as Reflection in .NET or other managed languages, because it is operating on compiled code, not an Intermediate Language (bytecode). However, it is a very similar concept, and the new RTTI system in Delphi 2010 brings it a lot closer to reflection, exposing an entire object-oriented API.
Pre-D2010, the RTTI was pretty limited. About the only thing I ever remember doing with it was converting an enumerated type to a string (or vice versa) for use in drop-down lists. I may have used it at one point for control persistence.
With the new RTTI in D2010 you can do a lot more things:
XML Serialization
Attribute-based metadata (TCustomAttribute). Typical use cases would be automatic validation of properties and automated permission checks, two things that you normally have to write a lot of code for.
Adding Active Scripting support (i.e. using the Windows script control)
Building a plug-in system; you could do this before, but there were a lot of headaches. I wasn't able to find a really good example of someone doing this from top to bottom, but all of the necessary functions are available now.
It looks like someone's even trying to implement Spring (DI framework) for Delphi 2010.
So it's definitely very useful, although I'm not sure how well you'd be able to explain it to a PHB; most of its usefulness is probably going to be realized through 3rd-party libraries and frameworks, much the same way it works in the .NET community today - it's rare to see reflection code sitting in the business logic, but a typical app will make use of several reflection-based components like an Object-Relational Mapper or IoC Container.
Have I answered the question?
D2010's extended RTTI is a lot like C#'s reflection. It gives you the ability to get at any field of an object, or inspect its methods. This has all sorts of potential uses. For example, if you can read any field of an object, you can write serialization code that can work with any object. And the ability to inspect methods and obtain their name and signature makes a class much easier to register with a scripting engine.
To me, that's the primary advantage of extended RTTI: The ability to write code that works with any class by examining its members, instead of writing different versions of the same code over and over, tailored to each individual class.
Most people probably won't use it in a real world application.
The people who will use it are the framework builders. Frameworks such as DUnit make extensive use of RTTI.
With the new RTTI capabilities we should expect to start seeing more advanced frameworks and tools appearing, similar to what is available for .NET. These frameworks will revolutionise your development moreso than RTTI will on it's own.
RTTI in Delphi has always been important since version 1.0. Classic RTTI features include the "published" properties section of Classes, which allowed the Object Inspector and the component designtime features to work. For my purposes, I would often use Published class properties to allow for enumeration of those properties at runtime. To store things from my objects to disk, for persistence.
The Delphi 2010 RTTI extends this classic RTTI massively, so much so that you could be forgiven for thinking Delphi did not even have RTTI until delphi 2010.
I would say the #1 most useful applications of "The New RTTI" are (as several other answers already state) going to be in Frameworks written by the gurus, that:
Handle persistence to files or databases. Database and configuration or document saving/loading frameworks and components would use this under the hood.
Handle pickling/marshalling/encoding/decoding to and from various
over-the-wire formats, like JSON, XML, EDI, and other things.
Unit testing was mentioned by someone else (JUnit), but I think perhaps the same frameworks could be really handy for debug and error reporting tools. Given an object passed as a parameter, on the stack, why not have bug reports that can dump all the data that was passed along to a function that failed, and not just a list of functions?
As you can see, some creative people are likely to think of even more uses for this. You could say, that though it does not bring parity to .NET reflection (which another answer speaks more about), it does bring a lot of "dynamic language" features (Think of Perl, Python, JavaScript) to an otherwise strongly typed static-type systems world of Delphi.
For me, personally, extended RTTI gave a possibility to retrieve calling convention from the method pointer. However, currently, that code is under conditional directive, because i am not satisfied with it.
(Critics and suggestions on workarond with basic RTTI are welcome, tho)
Look for TMS Aurelius and you will see that RTTI Attributes are very useful in terms of creating an ORM DataBase Framework and XML Serialization into pure objects and the opposite too.
You are supposed to care because they put it on the box. Clearly they think that some people will care.
Whether you actually have a use for it is entirely dependent on the nature of your projects. Since you didn't have it before and don't understand why having it now is a benefit, this would suggest to me that you don't have a use for it. It's then up to you whether to spend the time researching the subject further in order to discover whether you might be able to find a use for it.
Whether that is the most productive use of your time in relation to your projects, again is something only you can know.
Related
I don't understand LiveBinding's purpose. I would like to know which are the cases in which LiveBinding is most valuable. Embarcadero's manual describes it: "LiveBindings is a data-binding feature supported by both the VCL and FireMonkey frameworks in RAD Studio. LiveBindings is an expression-based framework, which means it uses binding expressions to bind objects to other objects or to dataset fields".
Thanks but I still don't know more than before.
I have seen some video in which a guy spends 12 minutes and hundredths of clicks to connect the caption of a TLabel to a TListBox control. When the user clicks an item in ListBox the name of the item is shown in Label. I could have done that with a single line of code (few keystrokes and no mouse clicks).
I am not criticizing LiveBinding. I am saying that I don't understand where it is helpful. I am missing something. Since it is not doing something that cannot be done from code, it means it's doing something that can be done from code, but visually and much much faster. I admit I haven't invested a lot of time in this topic but everywhere I look I see a terribly convoluted way (come on, you really need 5 extra controls to make LiveBinding works?) to do a simple task.
Also, it seems that LiveBinding was mostly designed for DB. All examples will include some kind of DB connectivity. But I am expressly interested only about the cases where I can use LiveBindings and there is no data set/DB involved. I am not using DB that much.
I doubt v. much that anyone would use live bindings if they could use traditional db-aware VCL components. However, that's not an option for non-VCL projects (Android, Apple, etc) and live bindings is the only Emba-supplied option for delivering data to those from TDataSet descendants.
An advantage of live bindings is that in addition to the Android and Apple targets, you can use them in Windows apps, so conceivably you could write the same (FMX-based) application for all three.
Libe-binding can also be used in VCL applications, but tbh, I can't imagine why anyone would use live bindings if they were only targeting a Windows DB application, as they are much slower than the traditional db-aware controls, especially multi-row ones such as grids.
I have not tried myself, but because the implementation of live bindings is interface-based, its potential use extends far beyond DB applications, but you would have to implement the interfaces yourself. It seems to be based around a fairly abstract expression-evaluation engine.
Setting up a l.b. project in the IDE does seem to require quite a bit more clicking around than you'd be used to from a traditional VCL app, but that's mostly because there is an additional step involved where you tell the IDE how to bind the gui objects to the data source(s). However, it is quite straightforward to "wire up" live bindings entirely in code if you want to.
I've been browsing the DeHL repository on GoogleCode, and it looks really good to me.
Many interesting features that make basic programming tasks easier; Some neat things that are in the DotNet FCL, but are missing from the Delphi RTL can be found in this library;
Coded in a modern way, making good use of new language features;
Each class, record type, member function and parameter is documented in such a way that it'll show in the code completion of the Delphi IDE;
Well-organized and clean code;
Plenty of unit tests;
Open source and Free;
Basically, it looks like this library should've been included with Delphi, as part of the RTL.
One major drawback: The project has been discontinued. :-(
Now my question is:
Would it be safe to rely on this library for future projects, and use it as a base framework to build upon?
Basically I'd like to hear from somebody who's actually used this library whether or not it's worth it to invest time in getting to know this library, and why.
IIRC the project was discontinued because it was an over-engineered first attempt and a lot of its features turned out really messy and bloated. You should look at Alex Ciobanu's second attempt, which is simply called Collections. It contains most of the interesting features from DeHL, but leaner.
Be careful, though. It still makes heavy use of generics, which will make your binary size really big if you use it a lot, because the compiler team hasn't implemented a way to collapse duplicate code yet.
I wonder whether there's a way to program a resource DLL for Windows Clusters in Delphi. I want to write a program that observes cluster state changes.
Judging from the MSDN API reference, all relevant functions are located in the ClusAPI.h and ResAPI.h headers, but unfortunately it seems as if they haven't been ported yet and HeaderConv seems to fail on them.
Does anyone has experience in doing such a thing?
It's a very C-oriented API, with mandatory Dll entry points, tables of callback function pointers, and binary data blocks. I've been able to wrap a C#/.NET library with a C++/CLI interop layer, but it's definitely non-trivial.
This would require a manual C header translation to Pascal code. If the API deals in pointers, you wouldn't have to translate any structures... this would make it comparatively simple to perform the translation as you'd only need to translate the function declarations themselves. If it passes structures (as opposed to pointers there-to) you would have to translate all of those structures as Delphi Records (or Packed Records as appropriate). Structure translations are far more time-consuming.
Sorry I can't offer an "instant solution", but at the info I've provided should help (if you didn't already know it).
I need to return objects from a DLL made in Delphi, to an app made in Delphi, too. The objective is to do a subsystem that can be modify in the future without to modify the main app. So, I imagine developing the subsystem in a DLL is a (good??) idea... i am programming in Windows XP, Delphi 7. I did read DLLs only return basic data type, but there must to be a way to do that...
Best regards.
I prefer to apply COM to such a model, which allows you to create external "objects" which you then can direct from within your application. Creating COM objects in Delphi is extremely simple, use your ActiveX creation methods to create an ActiveX library and then create COM objects. You then use the interface unit in your main application, and when you CoCreate an instance of the object it loads the appropriate DLL. The only tricky part of this is that your com objects must be registered on the system to function properly... which in the Win7/Vista world requires elevated access... although once this is done, it is seamless.
The BEST way is to use a COM wrapper as suggested by skamradt.
It is possible, but not a good idea to pass object references as pointers to DLL's. Refer particularly to Peter Haas's comments.
If you do pass an object from a Delphi DLL to a Delphi app you will have the following problems:
You must use the same version of Delphi for the app and DLL.
Both app and DLL MUST have the same implementation of the object - or at least identical layout of all fields in the class - OK if you are using standard objects such as TStringList.
You should use shared memory or runtime packages, otherwise you will get weird access violations.
I have had to maintain code where this was done - it was nightmarish as you couldn't change classes without a lot of re-compiling.
You can use interfaces and most of your problems, wrt compiler/rtl versions or even other languages just go away.
Delphi's interfaces are always IUnknown-compatible, which makes them compatible with most OO-enabled languages on Windows.
One thing to keep in mind, though: Don't use AnyString, stick to WideString, which is the Stringtype used by COM.
A platform- and language independent way could be to exchange serialized objects.
It has a performance impact, but it has advantages too: the DLL works without modifications with other languages and platforms like .Net or Java (via JNA Java Native Access). It does not depend on any special features of the operating system so it can as well be used on Linux or MacOS if you compile the library with Free Pascal.
For the serialization, you could use JSON or XML. There are open source libraries for Delphi, for example SuperObject and OmniXML.
Is it possible to do Aspect Oriented Programming in Delphi? I would be interested in native support as well as third party solutions.
I don't have a specific problem I want to solve with AOP, but am simply interested in studying AOP.
AOP depends on two things:
The ability to inject additional code into an existing unit of code
A mechanism to place conditions on where code should be injected.
This is commonly referred to as code weaving. It is a specialization within the larger study of program transformation.
JIT compiled languages have more options for implementing code weaving than statically compiled programs because more information is retained in the bytecode/IL. They also support reflection, which offers the ability to manipulate code at runtime.
Delphi.NET and Prism have the same access to these capabilities as any other .NET language.
There are two AOP frameworks for Delphi Win32 that I'm aware of. The first is MeAOP, which has already been mentioned. The second is Infra. Both projects take a similar approach to AOP. They use a combination of RTTI and clever pointer manipulation to intercept method calls so you can run additional code before or after the method call. You define your cross-cutting feature as a subclass of the framework's AOP class. You register the methods you want intercepted by passing the method name as a string argument to the AOP framework.
Both frameworks are still actively developed and are actually larger in scope than just AOP. Unfortunately documentation is somewhat sparse (and in Infra's case mostly in Portuguese)
Another project attempted AOP through source code weaving back in 2004 with some success. Basically they built an aspect weaver on top of a general purpose program transformation tool called DMS and used it to inject code into delphi source files prior to compilation. Their aspect oriented language was primarily influenced by AspectJ.
http://www.gray-area.org/Research/GenAWeave/ has links to the original paper and presentation as well as some videos of the transformation process.
It may also be possible to use runtime code instrumentation to accomplish this as well. Its a technique used by some profilers to inject counters and stack traces into running code without modifying the original source. A similar technique could be used to inject crosscutting concerns into a statically compiled executable. The PinTool project is a good example of this.
ClassHelpers in the later versions of Delphi allow some very limited level of AOP type behavior. You can use ClassHelpers to inject behavior into other classes without descending from them. It allows overriding existing methods and then optionally calling that existing method.
The limitation is you must declare a ClassHelper for a specific class and it descendants. Additionally a class can only have one ClassHelper.
These are similar to Extension methods in C#.
The DSharp library features AOP:
https://bitbucket.org/sglienke/dsharp
More info can be found at: https://bitbucket.org/sglienke/dsharp
Also have a look at TVirtualMethodInterceptor.
It's in the RTL since Delphi 2010 and allows you to do OnBefore, OnAfter, etc. calls on all virtual methods on a class.
This call alone should cover must of what you need using Rtti, not weaving which is much faster than run-time weaving.