Converters (merged with Converters Docu)

[DGDanforth]

I also don't see any need for an id field within a Converter.

Right, the id is not needed.

[DGDanforth]

To me a simple and meaningful extension would be to add two procedures:

PROCEDURE RegisterEx(..., OUT c: Converter);
PROCEDURE Unregister(c: Converter);

where RegisterEx can be used for registering a temporarily used converter,
i.e. one that is subject to Unregister at a later time.
Such a case is typical when developing a new converter because
multiple edit-compile-load-register cycles can be involved.

The only slight problem I see with "PROCEDURE Unregister(c: Converter);" is that the converter 'c' may reside in the middle of the list and hence
a recursive removal of 'c' would be needed.

With OpenRegistry and CloseRegistry all converters added after the open would be removed by the close.

[DGDanforth]

In (My)Converters I just added a few lines of code to transform the 'list' into a 'set'.
That entailed creating the hidden procedure 'Equal(c1, c2)' which returns true if the
converters are equal on a field by field comparison.

I did that because in old code I found that I had added a converter twice and it showed
up twice in the 'Files of type' list.

-Doug

[Josef Templ]

Changing next- to next* is a nice idea.
It gives a large amount of freedom for a minimal amount of change.

- Josef

[DGDanforth]

Changing next- to next* is a nice idea.
It gives a large amount of freedom for a minimal amount of change.

- Josef

Yes, one can "cut" the list at an arbitrary point or even reorder it.
-Doug

[Ivan Denisov]

Changing next- to next* is a nice idea.
It gives a large amount of freedom for a minimal amount of change.

It seems to be very simple feature. Should we change status to beta if we will include this issue in 1.7 ?

[DGDanforth]

Changing next- to next* is a nice idea.
It gives a large amount of freedom for a minimal amount of change.

It seems to be very simple feature. Should we change status to beta if we will include this issue in 1.7 ?

Do you mean step back from release candidate to beta?
We can just try it as unstable and see how people use and like it.
-Doug

[Ivan Denisov]

Do you mean step back from release candidate to beta?
We can just try it as unstable and see how people use and like it.

So let's also leave it for 1.8 unstable.

[DGDanforth]

Agreed.

[Josef Templ]

Well, 1.8 means binary incompatible to 1.7.
1.7.1, 1.7.2 etc. means binary compatible (bug fixes, minor extensions).
The next version should not be 1.8 but 1.7.1.
And, no, I don't want to work on multiple versions in parallel.
This complicates things significantly.

To summarize, I don't feel very comfortable with the idea of having 1.8 shortly after 1.7.
1.7.x must be a stable version that exists for quite some time.

The Converters change would not be binary compatible.
If we already agree that we want to have it, it should be done in 1.7.

- Josef