backward compatibility
Alexandru Corlan
I am sending this also the new shelisp group at googlegroups,
I hope you received the invitation.
I've been thinking about backward compatibility. Differences
in this kind of software can induce very subtle change in the
applications and be a big pain (lots of wasted time) for the user.
It has to be relatively unstable for some time.
Now, you propose a new (and admitedly better) implementation
that returns 3 results (stdout, stderr and result). The former
version of script would have returned both stdout and stderr
as a string.
The problem is that existing code that parses the return
from script for errors would need deep changes.
We could avoid touching existing code, and instead add new code to
it. For example, we can rename the 2007 version of 'script' as
'script-1'. We add a sepparate implementation, script-2.
Then, we have interfaces that could be macros. The '2007'
interface could expand a call to 'script' as a call to 'script-1'.
A newer interface would expand it to 'script-2'. [Maybe there
is already an established mechanism to do this that I do not know?]
One can call the specific method he needs even it his code
already uses the former interface.
We need to document all these but it is not that hard.
Alexandru
Alexandru Corlan
> have a problem with that?
Me, I think :) Anyway, this is an issue in general: shelisp developers
would always fear something subtle changed and would be discuraged to
experiment, and something may actually change and the user
would be discuraged.
>
> The change would mean the following for them:
> If they don't change their code at all, then they only capture stdout
> instead of stdout and stderr. The remaining values returned will
> not affect their code (multiple return values are ignored when
> their is no binding form for them).
Again, this was only one example.
>
> I see why you want to keep the API stable. And it makes sense,
> in my opinion. On the other hand it is a good idea to use an
> existing library to abstract from implementation differences,
> and this library is trivial-shell here.
> Also note that you can convert almost every command "cmd" to
> be compatible with the old version by writing "cmd 2>&1".
I know, but I have layers upon layers of code doing my websites
for example. Each change costs time as testing is also necessary.
> Like this, we can still merge the information that comes from stderr
> and stdout. It is not possible to split them afterwards, though.
>
> What do you think?
I welcome your proposed behaviour for script.
I would just let the existing code as is, and add new code using
the new behaviour because of the cost of tinkering with
my existing code. I am sure any other user in the same situation
would welcome this. Also, you wouldn't have to worry about
workarounds.
The same is true also for many other developments in the future.
It would be nice for each revision to be a drop-in replacement
and still have lots of new ideas and solutions in it.
Alexandru
Alexandru Corlan
I looked over methods of function shadowing, module overloading and
such and it looks like a bewilering subject with all sorts of
incompatible workarounds.
I think the most strightforward way, that is easy to explain to any
user and will not lead to deep and subtle regressions is to name new
variants of existing functions differently, typically with a small
number appended (for example script3). It is immediately easy
to understand and will always work as expected.
The user will chose, or will invoke his prefered shadowing mechanism.
Alexandru
Alexandru Corlan
> Which version of script will they use?
I think by default, in order not to change anything, the old version
if loaded with (require "shelisp"). Also, by default no call to (require
"trivial-shell") would be issued.
There would be a function, could be (use-read-macros-4) that
would require trivial-shell and change the readtable such
that the new macros would be used. (more macros and extensions
may occur in the future, as well as variants; for example '?'
may not be a convenient escape for some scripting languages).
Also, for example, a (require "shelisp4") could be issued
[I think to call the version that would include your code
shelisp4] instead of (require "shelisp") that would load
the new macros by default. People starting with shelisp
now would probably prefer that.
It may look complicated, but it depends how we document things.
Most people will use shelisp just for one or another feature,
and in their one way. They just need that way not to change
and be confident that it doesn't.
Perl, I think, has beed developed with a similar phylosophy
and is used in a similar way.