Re: Attaching context info to an error

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

> Just see eglot.el and jsonrpc.el for examples.  It's a constructor
> in the C++ style.  Meaning the client of the library, when making
> an object, won't get just a bunch of data.  They will either
> get a fully functioning object _or_ an error.  You can't do that
> in plain Elisp without "-init" custom constructors, just as
> you can't do that in C without foo = (Foo*)malloc() + init_foo(foo).

Not sure where using a "smart constructor" function (what you call
"-init" custom constructor) is less work than defining
a `initialize-instance` method.

> Furthermore, just like in typical OO, derivation of such classes
> are guaranteed to have the base class parts valid and constructed
> in their `intialize :after` this is the bread and butter of CLOS,
> and it's awkward and error-prone to program without it.

Ah... I think I'm beginning to see why I don't see the benefit: in my
world, objects are basically immutable, so an object that's partly
initialized (as in your "have the base class parts valid") is just
already very weird :-)

> Right, it's because I _know_ that you wrote these things that I find
> it odd you do now see how useful they are.

There's a difference between knowing how to build a car and being
a good driver, yes.

I can write a Prolog interpreter but my Prolog programming skills suck.
Similarly, I'm more comfortable using Haskell-style type classes (or
the closely related C++ templates) than "classic OOP" with subtyping.

>> Redefinition of a class is definitely not currently supported (with no
>> plan to support it in the foreseeable future).
> In this case, it was a new version of jsonrpc.el that has to
> be backward compatible to clients programming against the older
> version.

Then your bug report would be a feature request, I guess.
E.g. include a small patch to `jsonrpc.el` showing the code
you would *like* to use.

> CLOS class redefinition is big business indeed, but just removing
> a slot here in the same image worked nicely here for demonstration
> purposes: it still errored as reassuringly as it would have if in
> another Emacs session.

Yes, I'm aware of this.
But ELisp is a fairly limited "programming system" (as opposed to
programming language", see doi:10.1145/2384592.2384611).

I'm a PL guy and one from the functional programming side (i.e. averse
to mutation) to boot, so redefining the classes of existing objects
makes my head hurt.


        Stefan