Non-guarantees

The way a software library works is usually described in terms of what it *does*. Developers who use such library can depend on this expressed functionality. For example, a library can give a guarantee that a return value of certain method is a non-null array with elements that are all non-null.

There are, however, also things that are *not* guaranteed by the library. We call them non-guarantees. In general, anything that is not explicitly documented should be regarded as not guaranteed by the developer who uses the library.

It is useful to have a list of the (most important) non-guarantees as well, so that developers using the library do not make improper assumptions.

Some of the behavior that is not guaranteed may be implementation dependent and subject to change over the time. There are, however, some non-guarantees that are very intentional, inherent to the product design, and are not subject to change.

The list below attempts to identify the relevant non-guarantees for QuickOPC.

• It is not guaranteed that objects addressed in EasyXXClient method calls will end up in a single OPC call to the target OPC server.

• It is not guaranteed that objects addressed in EasyXXClient method calls will appear in the OPC call(s) to the target OPC server in the same order as on input.

• If you call EasyXXClient.Method1 on time₁ and you then call EasyXXClient.Method2 on time₂, before EasyXXClient.Method1 returns, it is not guaranteed that the OPC operations for Method1 will be called before those for Method2.

• It is not guaranteed that the first notifications caused by the EasyXXClient.SubscribeXXXX method call will only come after this method has returned.

• It is not guaranteed that after the EasyXXClient.UnsubscribeXXXXX method returns, no notifications will come for the affected objects.