Catchall concept is useful in programming

This is about a concept that I call the "catchall" concept (don't know if there is a more commonly used term for it). This concept can take many forms and is useful in programming.

A description and some examples may make it clear:

Description:

When developing apps, we sometimes come across situations that can't easily be captured in a structured or formal way. In such cases, using this catchall concept can be of help. One way to think about it is, as the solution to use when all other solutions don't seem suitable enough, or don't match the specific requirement we're trying to address - hence the term "catchall".

Now the examples:

1. This is a very common one, but still exemplifies the catchall concept. Many apps (whether desktop or web-based) that have a form to be filled in, use one or more text area (or multi-line text box) controls (the Windows GUI term) or widgets (the UNIX GUI term) in which the user can enter free-format or unstructured text. These controls are typically used to capture data that cannot easily fit into the more rigid, shorter length text or numeric or date fields of the underlying database table.

2. I heard from a friend who has ERP experience, that ERP software packages like SAP, come predefined with many extra, but initially unused text, numeric and date fields in some or all of their database tables. These fields might have names like CharField1, CharField2, IntField1, FloatField1, etc. - i.e. they are not really related to any specific concept of the application, like OrderNumber, OrderDate, etc. Then, when the ERP vendors customize the application, say a Sales module, for a client, they check whether all the attributes reflecting the business requirements of the app, are mapped onto appropriate existing database fields. If not, and if extra fields are needed for this client, they use some of those predefined unused fields for this purpose. In this way, they avoid (for the time being) the need to modify the database schema, and still meet the client's needs.

3. In a software product (related to database middleware) that I worked on, we defined a C-based API for programmers to call. It was deployed as a Windows DLL. We created a number of API functions for the product's requirements (e.g. GetConnection, PrepareStatement, FireQuery, etc. - not those exact names). However, in order to future-proof the product somewhat, we then added an extra catchall function parameter of type (void *) as the last parameter of each API function. This parameter was not initially used for any purpose within the function definition. The purpose of adding this function parameter was to be able to use it later to pass any sort of additional data into the function. That is, the calling programmer could pass some data, cast to (void *), and we could correspondingly modify that API function to use that data in some way (and possibly modify the returned value, if any, accordingly.) Then, just by recompiling and redeploying the DLL, their modified code which called that function with the additional argument containing some actual data, would work - AND, since the function's prototype hadn't changed, their old code wouldn't break.

This, of course, was a kludge, and was not meant as the final solution. The idea was that over time, we would identify those functions being called with the extra parameter, and refactor them, with properly named and more specific parameter(s) replacing the catchall (void *) parameter.

4. Another example is the Python feature of the last (optional) "keywords argument" that can be used with functions defined using this style:

def foo(first_args, *arguments, **keywords):

This case is even more flexible, because a convention can be defined between the calling and called programmer's code, by agreeing, when needed, to pass values for the **keywords argument as follows:

Foo=Value1, Bar=Value2, ...

and the code inside the function would be modified accordingly.

Vasudev Ram - Dancing Bison Enterprises.