Archive for the ‘Cplusplus’ Category

h1

Object Orientation is Inherently Dynamic

June 29, 2014

Even in static and compiled languages, therefore the despatch of a method to an object needs to be decided at run time. This is true of C++, where the _vtable is used for runtime dispatch, and also if function oanguages, where variant types ……. a variable whose actual type is decided by its current value….are used for despatch.

This raises the question of whether the best way to add OO to a static language is minimally , as C++ does, or add a whole dynamic layer as Objective C does….and if you are going down the latter route, should the layers have different or .similar syntax? Id be inclined to go for a minimal difference.

How to glue a dynamic layer to a static layer? If static code is embedded in dynamic code, some kind of dynamic despatch will be needed based on runtime parameter values. ( I’m assuming the dynamic layer will have only duck typing)

Static types passed into an embedded dynamic call will have to have their values boxed. Returns from dynamic calls , including data fetched from dynamic storage, is tricked. It can’t .be reliably unboxed into a naturally typed value,….either a runtime error will have to be thrown, or iy will have to into a variant.

Advertisements
h1

Staged constuction: a missing pattern?

August 7, 2012

Mr HostileFork argues that initialising an object after it has been constructed is against good object-orentiated design as exmplified by C++;. Contrary as ever, I will argue that C++ is anti good design.

The idea of once-and-for-all
construction is not a good match for processing that builds up complex data
structures in a number of stages. All the required data might not be initially
available to do the processing upfront, and it might be undesirableto do all the  
construction at once on timing grounds.
On the other hand, naively implemented “get” functions might try to return
data that isn;t ready yet. On way of solving that is for the “get..” for stage
N to check that the data from stage N-1 is ready, and if not, call the get of the previous
stage. N gets can therefore chain back. The user does not have to worry about
callign a series of methods in the right order. The check will prevent unnecessary
duplication of effort, since no processing is performed unconditionally (methods that engage
in staged construction can be made private). (Necessary re-performing of stages
where data has changed requires more complexity…blanking out all the data
belonging to the upstream stages to force them to be reperformed), The downside
is a small amount of extra runtime to perform the check. This technique resembles
the way SQL interfaces typically do not perform the query till the first fetch.(Lazy Initialisation
pattern).  
 
Alternatively, the stages could be turned into
a hierarchy. The class representing the Nth stage embeds an object of stage
N-1, or calls the constructor of its parent (and so on). However,
the C++/Java style of OO is not much more accomodating to the nesting/wrapping than
it is to staged construction.

UPDATE:

Staged construction and destruction are needed for resource allocation and deallocation. Objects could be seen as a special case of two-state state machines, which leap from unconstrusted to constructed in a single bound. This idea is followed through in the incipient language Plaid. State machines are considered limited as languages, but there is a difference between a language entirely bassd on SMs, and a language that allows them to be constructed in conjunction with general purpose facilities.

The best things to do with state are to hide it as much as possible, or put it under as much explicit control as possible. Therefore, an ideal language would have a functional language embedded in a state machine language.