bug#19564: 24.4; eieio backward compatibility

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> That doesn't explain to me *why* it needs it.
>> Why does Helm need to know the initarg of a slot?
> Helm needs to know the value of each slot in class to convert it to
> alist.

But the initarg is not the slot, so that doesn't explain why you need
the initargs?

> But well I don't see the problem, class-slot-initarg exists and I just
> want to use it, why should I avoid using it ?

As exlained in bug#19552, EIEIO's use of namespaces and
internal/external definitions was terribly messy (and it's still far
from ideal), so you were left having to guess whether you were allowed
to use something.

> Is its use prohibited ? :-)

Well since it's not part of CLOS, I think it should be considered
internal to EIEIO's implementation, and hence I renamed it accordingly
with the "eieio--" prefix (and slightly changed its calling convention).

> I could get rid of class-slot-initarg and now the bug is fixed in helm.

Could you give me a quick description of what you replaced it with?

> The problem is not solved though if some old external program use this.

Indeed.  I can add an obsolete backward-compatible definition to handle
that, but I'd first like to better understand why it was used: maybe it
shouldn't be declared internal after all.

> There is also a problem now with compiled files, emacs-24.4 compiled
> files are not compatibles with emacs-25 compiled files and vice-versa.

Files compiled with Emacs-25 are indeed not expected to work on
Emacs-24, but the other way should work (tho some of the changes in
EIEIO aren't backward compatible at their core, but so far those seemed
not to affect existing .elc files), so if it doesn't please M-x
report-emacs-bug, so we can see if/how we can fix it.


        Stefan