Re: Seeking for papers about tagged types vs access to subprograms

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Mon, 13 May 2013 09:22:24 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

>> The "activation" must then be done in a statement, and the
>> declaration leaves the object in some inactive initial state.
>
> That is not a problem so long this state is not exposed. The idea is that
> when you have an object which may transit from state to state (e.g. a
> connection object, when the connection can be lost), you should not  
> expose
> this state. You better make the object to maintain the state (e.g. by
> making the connection restored by the object automatically) and leave its
> interface free of the state (e.g. an operation on unconnected object  
> would
> block or else raise Busy_Error etc).

Except for the exception which implies a lot of more things, the idea is  
indeed nice, while not universal. To stick with this example, that depends  
on the level of the application (it may or may not be aware of possible  
loss of connection), depends on the protocol in use (there may or may not  
be a way to know if the connection can be restored, if it is loss of if  
the peer closed it), that may be replacing a problem with another (state  
vs delay), and so on.

I agree with you (or may not, depending on the concrete case), except with  
this: “That is not a problem so long this state is not exposed”; this  
seems to suggest another design is an error and this is an universal  
pattern.


>> Another limitation in your approach is that the opening and closing of
>> different files must be strictly nested: if you declare and open file A,
>> then declare and open file B, file B must be closed before file A is
>> closed (as long as it all happens in the same task). Such forced
>> constraints between the states of different object is often not wanted.
>
> You can have a container, e.g. a bag, to handle this.
>
> Jeffrey's model translates this into the problem of object's scope
> (lifetime), which saves time and mental efforts. Each programmer faces it
> on daily basis and has his ready-to-use solutions already.

The same: may be an option, however nothing universal with it (ex. may be  
too much to pull the container concept, or for the second, objects  
identities may be important and one object may be opened and closed  
multiple times).

There is the topic of premature optimizations, there may be as well a  
topic about premature decisions (especially an issue if it adds  
dependencies or complexity).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University