Enabling backwards compatibility
-
So this is an approach that proved so successful that it was made into a standard. You're writing a shared library and you're concerned to ensure future compatibility across services. Problems include: * How to support non built-in types? (e.g. MyCustomType) * How to support float, int, double, etc? * How to prevent constantly updating interfaces from complicating builds? Best approach? Well, how about you convert all your arguments into Strings to transfer across the wire and then convert them back. Every method has the following signature:
public String[] doSomething(String[] args, String userId)
Then you have a static library that allows:
TypeUtils.stringify(Object object); // native types are supported by simply ""+myVar
Object obj = TypeUtils.fromString(String string, String fromType);Easy. (Note you may need to cast the object returned from TypeUtils.fromString(). User id is there to ensure security, obviously. You don't have to use the TypeUtils but you are encouraged to, for convenience. This way, when you swap args[2] and args[3], or when you introduce a new argument at the end, you don't have to declare a new version of the interface. Simply keep the same version interface jar throughout and require everyone to use the very latest implementation.
This is why I don't program
-
So this is an approach that proved so successful that it was made into a standard. You're writing a shared library and you're concerned to ensure future compatibility across services. Problems include: * How to support non built-in types? (e.g. MyCustomType) * How to support float, int, double, etc? * How to prevent constantly updating interfaces from complicating builds? Best approach? Well, how about you convert all your arguments into Strings to transfer across the wire and then convert them back. Every method has the following signature:
public String[] doSomething(String[] args, String userId)
Then you have a static library that allows:
TypeUtils.stringify(Object object); // native types are supported by simply ""+myVar
Object obj = TypeUtils.fromString(String string, String fromType);Easy. (Note you may need to cast the object returned from TypeUtils.fromString(). User id is there to ensure security, obviously. You don't have to use the TypeUtils but you are encouraged to, for convenience. This way, when you swap args[2] and args[3], or when you introduce a new argument at the end, you don't have to declare a new version of the interface. Simply keep the same version interface jar throughout and require everyone to use the very latest implementation.
This is why I don't program
-
So this is an approach that proved so successful that it was made into a standard. You're writing a shared library and you're concerned to ensure future compatibility across services. Problems include: * How to support non built-in types? (e.g. MyCustomType) * How to support float, int, double, etc? * How to prevent constantly updating interfaces from complicating builds? Best approach? Well, how about you convert all your arguments into Strings to transfer across the wire and then convert them back. Every method has the following signature:
public String[] doSomething(String[] args, String userId)
Then you have a static library that allows:
TypeUtils.stringify(Object object); // native types are supported by simply ""+myVar
Object obj = TypeUtils.fromString(String string, String fromType);Easy. (Note you may need to cast the object returned from TypeUtils.fromString(). User id is there to ensure security, obviously. You don't have to use the TypeUtils but you are encouraged to, for convenience. This way, when you swap args[2] and args[3], or when you introduce a new argument at the end, you don't have to declare a new version of the interface. Simply keep the same version interface jar throughout and require everyone to use the very latest implementation.
This is why I don't program
That is the modern way of doing it, it even has an approved name: JSON! Except that, by default, in JSON certain types of object (e.g. functions, RegExps) are not supported and some have ambiguous mappings (e.g. Date literals can be identical to certain String literals). JSON, therefore, has an implicit advantage in unusability over your method - it adds ambiguity and complexity for no net benefit; surely this is how all constructs should be.
-
That is the modern way of doing it, it even has an approved name: JSON! Except that, by default, in JSON certain types of object (e.g. functions, RegExps) are not supported and some have ambiguous mappings (e.g. Date literals can be identical to certain String literals). JSON, therefore, has an implicit advantage in unusability over your method - it adds ambiguity and complexity for no net benefit; surely this is how all constructs should be.
Well, I feel stupid now. You mean that architect was visionary? :wtf:
-
That is the modern way of doing it, it even has an approved name: JSON! Except that, by default, in JSON certain types of object (e.g. functions, RegExps) are not supported and some have ambiguous mappings (e.g. Date literals can be identical to certain String literals). JSON, therefore, has an implicit advantage in unusability over your method - it adds ambiguity and complexity for no net benefit; surely this is how all constructs should be.
jsc42 wrote:
it even has an approved name: JSON!
I always thought that it was called SDD (String Driven Development)
Oxfords English < Official CCC Players Dictionary Excuse me for my improper grammar and typos. It's because English is my primary language, not my first language. My first languages are C# and Java. VB, ASP, JS, PHP and SQL are my second language. Indonesian came as my third language. My fourth language? I'm still creating it, I'll let you know when it's done! :-D
-
So this is an approach that proved so successful that it was made into a standard. You're writing a shared library and you're concerned to ensure future compatibility across services. Problems include: * How to support non built-in types? (e.g. MyCustomType) * How to support float, int, double, etc? * How to prevent constantly updating interfaces from complicating builds? Best approach? Well, how about you convert all your arguments into Strings to transfer across the wire and then convert them back. Every method has the following signature:
public String[] doSomething(String[] args, String userId)
Then you have a static library that allows:
TypeUtils.stringify(Object object); // native types are supported by simply ""+myVar
Object obj = TypeUtils.fromString(String string, String fromType);Easy. (Note you may need to cast the object returned from TypeUtils.fromString(). User id is there to ensure security, obviously. You don't have to use the TypeUtils but you are encouraged to, for convenience. This way, when you swap args[2] and args[3], or when you introduce a new argument at the end, you don't have to declare a new version of the interface. Simply keep the same version interface jar throughout and require everyone to use the very latest implementation.
This is why I don't program
I had to deal with that sort of thing on my last assignment, in VB of course. :sigh:
-
So this is an approach that proved so successful that it was made into a standard. You're writing a shared library and you're concerned to ensure future compatibility across services. Problems include: * How to support non built-in types? (e.g. MyCustomType) * How to support float, int, double, etc? * How to prevent constantly updating interfaces from complicating builds? Best approach? Well, how about you convert all your arguments into Strings to transfer across the wire and then convert them back. Every method has the following signature:
public String[] doSomething(String[] args, String userId)
Then you have a static library that allows:
TypeUtils.stringify(Object object); // native types are supported by simply ""+myVar
Object obj = TypeUtils.fromString(String string, String fromType);Easy. (Note you may need to cast the object returned from TypeUtils.fromString(). User id is there to ensure security, obviously. You don't have to use the TypeUtils but you are encouraged to, for convenience. This way, when you swap args[2] and args[3], or when you introduce a new argument at the end, you don't have to declare a new version of the interface. Simply keep the same version interface jar throughout and require everyone to use the very latest implementation.
This is why I don't program
-
So this is an approach that proved so successful that it was made into a standard. You're writing a shared library and you're concerned to ensure future compatibility across services. Problems include: * How to support non built-in types? (e.g. MyCustomType) * How to support float, int, double, etc? * How to prevent constantly updating interfaces from complicating builds? Best approach? Well, how about you convert all your arguments into Strings to transfer across the wire and then convert them back. Every method has the following signature:
public String[] doSomething(String[] args, String userId)
Then you have a static library that allows:
TypeUtils.stringify(Object object); // native types are supported by simply ""+myVar
Object obj = TypeUtils.fromString(String string, String fromType);Easy. (Note you may need to cast the object returned from TypeUtils.fromString(). User id is there to ensure security, obviously. You don't have to use the TypeUtils but you are encouraged to, for convenience. This way, when you swap args[2] and args[3], or when you introduce a new argument at the end, you don't have to declare a new version of the interface. Simply keep the same version interface jar throughout and require everyone to use the very latest implementation.
This is why I don't program
Timely post - I made this point in my codeproject article which highlighted that web developers have resorted to passing complex business data as strings because there is no industrial strength mechanism to do what more mature development platforms have. Data is really key to making line of business (LoB) web applications, but unfortunately the industry currently has the tail wagging the dog: we are trying to retro-fit robust business data services onto a scripted/markup platform. The two don't mix. We are forced to compromise, and this ain't good as we will find out with an enormous number of broken legacy web apps in the near future. The current methods of building cross-platform LoB web applications is simply not good enough.
-
So this is an approach that proved so successful that it was made into a standard. You're writing a shared library and you're concerned to ensure future compatibility across services. Problems include: * How to support non built-in types? (e.g. MyCustomType) * How to support float, int, double, etc? * How to prevent constantly updating interfaces from complicating builds? Best approach? Well, how about you convert all your arguments into Strings to transfer across the wire and then convert them back. Every method has the following signature:
public String[] doSomething(String[] args, String userId)
Then you have a static library that allows:
TypeUtils.stringify(Object object); // native types are supported by simply ""+myVar
Object obj = TypeUtils.fromString(String string, String fromType);Easy. (Note you may need to cast the object returned from TypeUtils.fromString(). User id is there to ensure security, obviously. You don't have to use the TypeUtils but you are encouraged to, for convenience. This way, when you swap args[2] and args[3], or when you introduce a new argument at the end, you don't have to declare a new version of the interface. Simply keep the same version interface jar throughout and require everyone to use the very latest implementation.
This is why I don't program
You're lucky. You can at least differentiate between array type arguments and others. And you do have argument names that hint at their intended use. I've encountered that philosophy in the early 90s, when trying to learn OLE2: in my search for documentation of the automation API provided by Excel, I've found that all functions exlusively used arguments of the type
Variant. :wtf: I would really have liked to know whether they are supposed to be integer values, short, or maybe even double, or in which order I am supposed to pass the arguments, but the documentation did not even contain argument names to give a hint of which is which, much less an explanation what the arguments are supposed to contain. According to MicroSoft and even other sources, at that time that documentation was the most elaborate to be had ,,, X| Fortunately I eventually found a good book on the topic (not by MS!), or I'd still be busy doing trial and error to find out just how to use that API... :~ -
I slowly begin to understand why C or C++ used to have no string datatype. It takes deep wisdom to weigh the problems from leaving it out against those that arise when that datatype gets into the wrong hands.
I'm invincible, I can't be vinced
I have become convinced that programming languages that offer String types should declare them as abstract and/or force you to typedef them before you can use them. "String userid" would not be allowed. Something like "typedef String Userid" would be required first. Declaration then becomes: Userid userid; All of the APIs would them end up with compile time checking for Userid and any mismatches would be compile errors. A lot of this thinking comes from a security angle. In a web app: String userInputWithPossibleInjectionAttacks; is the same type as String afterApplyingSanitationRules; Which String are you storing in your user comment database? Eventually in programs, each variable's "content" will have history/ACLs associated with it like we have for files on file systems. They just have not invented this programming language yet... but anyone who deals with user supplied data from outside (or even inside) their organization needs stuff like this.
-
Timely post - I made this point in my codeproject article which highlighted that web developers have resorted to passing complex business data as strings because there is no industrial strength mechanism to do what more mature development platforms have. Data is really key to making line of business (LoB) web applications, but unfortunately the industry currently has the tail wagging the dog: we are trying to retro-fit robust business data services onto a scripted/markup platform. The two don't mix. We are forced to compromise, and this ain't good as we will find out with an enormous number of broken legacy web apps in the near future. The current methods of building cross-platform LoB web applications is simply not good enough.
Sounds like a consulting opportunity to me! :-D
Charlie Gilley You're going to tell me what I want to know, or I'm going to beat you to death in your own house. "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
It's surprising how many people try to create their own solutions to problems which already have established and well-behaving solutions :S.
Quote:
It's surprising how many people try to create their own solutions to problems which already have established and well-behaving solutions :S.
Bear in mind that it's difficult, no ... impossible ... to keep up with all the available technology. I don't know how many times I've "invented" something only to find out later that someone else already did it (invariably, in a better way :)
-
Quote:
It's surprising how many people try to create their own solutions to problems which already have established and well-behaving solutions :S.
Bear in mind that it's difficult, no ... impossible ... to keep up with all the available technology. I don't know how many times I've "invented" something only to find out later that someone else already did it (invariably, in a better way :)
Very true, that's why I used "established". In this case WS* and more recently various RESTful standards (see for example OData) try to address this problem since 2003 (while other frameworks tried than even during the 90s)... It's quite natural for someone with a bit of experience to go search there first to see if they can use one prepared solution or at least get inspiration from. Of course, having a general grasp on where to search the answer on a problem is one of the most important skills of an architect/developper, and it's not something all people enjoy doing (some people for example prefer the pleasure and control of building something themselves, while others prefer to experiment with a lot of things others invented).
-
Timely post - I made this point in my codeproject article which highlighted that web developers have resorted to passing complex business data as strings because there is no industrial strength mechanism to do what more mature development platforms have. Data is really key to making line of business (LoB) web applications, but unfortunately the industry currently has the tail wagging the dog: we are trying to retro-fit robust business data services onto a scripted/markup platform. The two don't mix. We are forced to compromise, and this ain't good as we will find out with an enormous number of broken legacy web apps in the near future. The current methods of building cross-platform LoB web applications is simply not good enough.
For business needs strings are fine. I've programmed in Pick for over 20 years. Its only data type the multivalued variable length array is just a delimited string. So I don't have a problem at all with Web provided data being text.
-
I have become convinced that programming languages that offer String types should declare them as abstract and/or force you to typedef them before you can use them. "String userid" would not be allowed. Something like "typedef String Userid" would be required first. Declaration then becomes: Userid userid; All of the APIs would them end up with compile time checking for Userid and any mismatches would be compile errors. A lot of this thinking comes from a security angle. In a web app: String userInputWithPossibleInjectionAttacks; is the same type as String afterApplyingSanitationRules; Which String are you storing in your user comment database? Eventually in programs, each variable's "content" will have history/ACLs associated with it like we have for files on file systems. They just have not invented this programming language yet... but anyone who deals with user supplied data from outside (or even inside) their organization needs stuff like this.
They kind-of have that already. You might say
public class UserID : String { }