There's a language enhancement I'd like to see in Delphi, but I'm not sure what exactly it is.
There's a language enhancement I'd like to see in Delphi, but I'm not sure what exactly it is. I can only point to where it shows up as a missing for me. Feel free to comment on what it is that I seem unable to point to directly. Perhaps it even has some kind of name; I really don't know.
I was writing a bit of code where I needed to create a couple of methods that everybody runs into now and then: LoadXxxxFromYyyy and SaveXxxxToYyyy.
Xxxx is usually an object of some kind and Yyyy is some kind of container object like a File, Stream, Ini, Form, Cache, Buffer, ... whatever. We've all written plenty of these, right?
Now, since Xxxx is usually an object, the things that are being copied out and in are typically PROPERTIES -- and usually Public or Published properties at that.
What I'd LIKE to see is the ability to write a single bi-directional copy method like this:
CopyEx( aVal1 : T1; aCollection : T2; dirFlg : Boolean );
Unfortunately, this is impossible today because of "limitations" in how properties can be used. If you're not quite clear what I'm talking about here's a little more detail.
Say you have a property like this:
property Abc : string read FAbc write FAbc;
To create the Load and Save methods, one needs to say this in one of the methods (eg, LoadAbcFromIni):
Abc := ini.ReadString( 'secnm', 'Abc', '' );
while the other one (eg, SaveAbcToIni) needs to say:
ini.WriteString( 'secnm', 'Abc', Abc );
So the CopyEx might look something like this:
CopyEx( Abc, ini, dirflg);
If dirflg were True, then the copy goes left-to-right (==>), and if dirflg were False then the copy goes right-to-left (<==). This would effectively replace the two totally asymmetric assignment statements that I showed just above.
But it won't work in the latter case, because property names can only be assigned a value if they appear on the left-hand side of an assignment statement.
These Load/Save methods are a PITA to write, especially if there are a bunch and the data types vary. But there are lots of other situations where you have to write code that does the same kind of thing - copying several values from A to B in one part of the code, and then copying the same values from B to A somewhere else. (eg., what Assign methods do)
This can work for variables if you're careful, but not properties.
Actually, you'd need several overloaded methods to handle different types, like ordinals vs. strings (arrays?) vs. Arrays vs. records vs. classes vs. references, and so forth.
Maybe we just need a special "magic function" added to the language that slashes the Gordian knot in this case and lets one single expression (or pattern) be used for an entire class of types that exist to support the exact same semantics: copy a value 'V' from/to a collection object of some kind that probably needs to refer to 'V' by name, in a way that works for whatever type 'V' might be.
Why would this be useful?
Imagine tagging some properties with Attributes that say they're available to be streamed in and out (or serialized, or whatever you want to call it). Then you can write a generic method with a two-line loop that looks like the CopyEx(...) method and it's able to perform the copy between aligned variables or properties in any two objects based on whatever metadata you want to provide in the Attributes. Even if there's, say, 250 properties in a class to be copied back and forth, you'd only need one simple bidirectional CopyEx(...) method to handle both Load and Save functions.
Now, as I said, I know why this can NOT be done today (at least, not easily) -- it's because of syntactic limitations in the use of property names. I actually don't have a suggestion for fixing this other than rto emove these "limitations". But I can understand why that may not be practical.
The question is: what changes can be made in the language to support this kind of mechanism?
The limitation seems to be an asymmetry in the language syntax that exists for no particularly justifiable reason (to me, anyway). Interestingly, this specific problem in Delphi does not arise in any other languages I can think of, although most languages do have their own unique asymmetries.
For example, I know that over the years, the C++ standards folks have bent over backwards to eliminate asymmetries between "lhs" and "rhs" expressions. Some are simply unavoidable; others are there "just because". It's the latter ones they've done their best to eliminate.
What can be done to remedy this situation in Delphi? I think this is something that would make a lot of code simpler in a lot of places, because this "pattern" of copying data (consisting of blocks of properties) back and forth is fairly ubiquitous in our work.
What would it take to enable this?
((Now I can't help but think ... somebody is going to say, "But you CAN do that already! This library already supports it!" Ok, well, why is it in a 3rd-party lib and not in the base product?))
I was writing a bit of code where I needed to create a couple of methods that everybody runs into now and then: LoadXxxxFromYyyy and SaveXxxxToYyyy.
Xxxx is usually an object of some kind and Yyyy is some kind of container object like a File, Stream, Ini, Form, Cache, Buffer, ... whatever. We've all written plenty of these, right?
Now, since Xxxx is usually an object, the things that are being copied out and in are typically PROPERTIES -- and usually Public or Published properties at that.
What I'd LIKE to see is the ability to write a single bi-directional copy method like this:
CopyEx( aVal1 : T1; aCollection : T2; dirFlg : Boolean );
Unfortunately, this is impossible today because of "limitations" in how properties can be used. If you're not quite clear what I'm talking about here's a little more detail.
Say you have a property like this:
property Abc : string read FAbc write FAbc;
To create the Load and Save methods, one needs to say this in one of the methods (eg, LoadAbcFromIni):
Abc := ini.ReadString( 'secnm', 'Abc', '' );
while the other one (eg, SaveAbcToIni) needs to say:
ini.WriteString( 'secnm', 'Abc', Abc );
So the CopyEx might look something like this:
CopyEx( Abc, ini, dirflg);
If dirflg were True, then the copy goes left-to-right (==>), and if dirflg were False then the copy goes right-to-left (<==). This would effectively replace the two totally asymmetric assignment statements that I showed just above.
But it won't work in the latter case, because property names can only be assigned a value if they appear on the left-hand side of an assignment statement.
These Load/Save methods are a PITA to write, especially if there are a bunch and the data types vary. But there are lots of other situations where you have to write code that does the same kind of thing - copying several values from A to B in one part of the code, and then copying the same values from B to A somewhere else. (eg., what Assign methods do)
This can work for variables if you're careful, but not properties.
Actually, you'd need several overloaded methods to handle different types, like ordinals vs. strings (arrays?) vs. Arrays vs. records vs. classes vs. references, and so forth.
Maybe we just need a special "magic function" added to the language that slashes the Gordian knot in this case and lets one single expression (or pattern) be used for an entire class of types that exist to support the exact same semantics: copy a value 'V' from/to a collection object of some kind that probably needs to refer to 'V' by name, in a way that works for whatever type 'V' might be.
Why would this be useful?
Imagine tagging some properties with Attributes that say they're available to be streamed in and out (or serialized, or whatever you want to call it). Then you can write a generic method with a two-line loop that looks like the CopyEx(...) method and it's able to perform the copy between aligned variables or properties in any two objects based on whatever metadata you want to provide in the Attributes. Even if there's, say, 250 properties in a class to be copied back and forth, you'd only need one simple bidirectional CopyEx(...) method to handle both Load and Save functions.
Now, as I said, I know why this can NOT be done today (at least, not easily) -- it's because of syntactic limitations in the use of property names. I actually don't have a suggestion for fixing this other than rto emove these "limitations". But I can understand why that may not be practical.
The question is: what changes can be made in the language to support this kind of mechanism?
The limitation seems to be an asymmetry in the language syntax that exists for no particularly justifiable reason (to me, anyway). Interestingly, this specific problem in Delphi does not arise in any other languages I can think of, although most languages do have their own unique asymmetries.
For example, I know that over the years, the C++ standards folks have bent over backwards to eliminate asymmetries between "lhs" and "rhs" expressions. Some are simply unavoidable; others are there "just because". It's the latter ones they've done their best to eliminate.
What can be done to remedy this situation in Delphi? I think this is something that would make a lot of code simpler in a lot of places, because this "pattern" of copying data (consisting of blocks of properties) back and forth is fairly ubiquitous in our work.
What would it take to enable this?
((Now I can't help but think ... somebody is going to say, "But you CAN do that already! This library already supports it!" Ok, well, why is it in a 3rd-party lib and not in the base product?))
Comments
Post a Comment