Right, the id is not needed.Josef Templ wrote: I also don't see any need for an id field within a Converter.
Converters (merged with Converters Docu)
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Converters
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Converters
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 henceJosef Templ wrote: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.
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
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Converters
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
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
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Converters
Changing next- to next* is a nice idea.
It gives a large amount of freedom for a minimal amount of change.
- Josef
It gives a large amount of freedom for a minimal amount of change.
- Josef
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Converters
Yes, one can "cut" the list at an arbitrary point or even reorder it.Josef Templ wrote:Changing next- to next* is a nice idea.
It gives a large amount of freedom for a minimal amount of change.
- Josef
-Doug
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Converters
It seems to be very simple feature. Should we change status to beta if we will include this issue in 1.7 ?Josef Templ wrote:Changing next- to next* is a nice idea.
It gives a large amount of freedom for a minimal amount of change.
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Converters
Do you mean step back from release candidate to beta?Ivan Denisov wrote:It seems to be very simple feature. Should we change status to beta if we will include this issue in 1.7 ?Josef Templ wrote:Changing next- to next* is a nice idea.
It gives a large amount of freedom for a minimal amount of change.
We can just try it as unstable and see how people use and like it.
-Doug
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Converters
So let's also leave it for 1.8 unstable.DGDanforth wrote: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.
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Converters
Agreed.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Converters
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
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