next upload (was: Re: bug 219448)

[Paul Boekholt]

On Sat, 21 May 2005 09:43:02 +0100, Alastair McKinstry <mckinstry@computer.org> said:

> I was already packaging 2.0.2 when I received your mail; can you explain
> this issue a bit further? I don't see how implementing 2.0.0 helps (will
> hold off uploading 2.0.2 for the moment)

Packaging 2.0.0 would be OK because that version does not have the
incompatibility of 2.0.2.  In 2.0.2, an "autoload" statement such as
autoload("f", bar)

evaluated in namespace foo will create a name foo->f that will cause the
file bar to be evaluated in namespace foo when that function is called,
that is, when foo.sl calls f().  But if bar.sl contained the definition
public define f()
than this will lead to an error in slang 2.0.2,  you'd get the error

f already has static or private linkage in this unit

In this case the word "public" in bar.sl was superfluous, and removing it
would get rid of the error.  However the fact that slang 2.0.2 will load
the file in the foo namespace, instead of just using the global
namespace, can cause deeper incompatibilities.  For example if bar.sl:f
looks like
define f()
{
   g();
}

and both the global namespace and the foo namespace have a g(), 2.0.0 as
well as 1.x will use Global->g() and 2.0.2 will use foo->g() (if foo->g()
is static that is, private functions are now private to the file they are
in).

So the solution is to make sure that the autoloads are above the
"implements" line.  So in foo.sl this involves the change

implements("foo");
autoload("f", "bar");

to

autoload("f", "bar");
implements("foo");


It gets even worse when the require() and provide() functions of slang 2
(in /usr/share/slsh/require.sl) are used in a future version of JED.  Then
all requires and provides will also have to be moved above any implements
statements.

So quite a few scripts will have to be updated.