WEBVTT

00:01.199 --> 00:00:02.320
My name is Ian Eure,

00:00:02.320 --> 00:00:03.199
and welcome to my talk

00:00:03.199 --> 00:00:05.120
"Old McCarthy Had a Form".

00:00:05.120 --> 00:00:05.759
In this talk,

00:00:05.759 --> 00:00:07.759
I'm going to be discussing EIEIO,

00:00:07.759 --> 00:00:09.920
which is an Emacs Lisp implementation

00:00:09.920 --> 00:00:12.320
of the Common Lisp object system.

00:12.320 --> 00:00:13.519
CLOS is a way of writing

00:13.519 --> 00:00:15.360
object-oriented Common Lisp code,

00:00:15.360 --> 00:00:17.920
and with EIEIO you have much of that same

00:17.920 --> 00:00:19.920
power but inside Emacs.

00:00:19.920 --> 00:00:21.359
I'm going to be using those two names

00:00:21.359 --> 00:00:22.988
interchangeably throughout this talk,

00:00:22.988 --> 00:00:26.640
since they're nearly equivalent.

00:26.640 --> 00:00:27.534
You might wonder,

00:00:27.534 --> 00:00:28.880
"Why would I want to write 

00:00:28.880 --> 00:00:31.439
object Emacs Lisp code?".

00:00:31.439 --> 00:00:33.440
I like it because I like writing

00:00:33.440 --> 00:00:34.960
in a functional programming style,

00:00:34.960 --> 00:00:36.896
or I like to do an imperative style

00:00:36.896 --> 00:00:39.040
that captures interactive key sequences

00:00:39.040 --> 00:00:41.200
that I might enter manually.

00:41.200 --> 00:00:42.800
Well, I think, different kinds of programs

00:42.800 --> 00:00:45.120
need different kind of programming paradigms,

00:00:45.120 --> 00:00:47.760
and sometimes OOP is the one that fits.

00:00:47.760 --> 00:00:49.708
Also, if you've done much OOP before,

00:00:49.708 --> 00:00:50.655
you might be surprised by 

00:00:50.655 --> 00:00:52.879
how EIEIO works and the sorts of power

00:00:52.879 --> 00:00:55.039
that it brings to your programs.

00:55.039 --> 00:00:58.480
So, let's talk about that model now.

00:58.480 --> 00:01:00.000
Classes are pretty much what 

00:01:00.000 --> 00:01:01.120
you would expect if you've done

00:01:01.120 --> 00:01:02.879
OOP programming before.

01:02.879 --> 00:01:04.400
In the CLOS model, 

00:01:04.400 --> 00:01:06.400
they only have fields,

00:01:06.400 --> 00:01:08.000
they only encapsulate values,

00:01:08.000 --> 00:01:10.720
they don't have anything to do with methods.

01:10.720 --> 00:01:13.040
So, in this case, we have a base class for

01:13.040 --> 00:01:15.040
an EMMS player backend,

00:01:15.040 --> 00:01:18.159
and it has one field (a slot is what

00:01:18.159 --> 00:01:20.000
it's called in CLOS terminology),

00:01:20.000 --> 00:01:22.720
which indicates whether it's playing or not,

00:01:22.720 --> 00:01:24.080
and it's declared abstract,

00:01:24.080 --> 00:01:25.439
so you can't create an instance

00:01:25.439 --> 00:01:27.040
of an object based on this class,

00:01:27.040 --> 00:01:29.280
you can only extend it with another class,

00:01:29.280 --> 00:01:31.119
that's an EIEIO extension,

00:01:31.119 --> 00:01:33.439
but I think it's a pretty good one.

01:33.439 --> 00:01:34.640
You can also see there's a class

00:01:34.640 --> 00:01:37.119
that implements an mpv player back-end,

00:01:37.119 --> 00:01:39.680
and it extends the base class,

00:01:39.680 --> 00:01:40.960
it doesn't add any slots,

00:01:40.960 --> 00:01:44.479
and those get inherited from the base class.

01:44.479 --> 00:01:45.936
If you want these to do much more

00:01:45.936 --> 00:01:46.960
than encapsulate data,

00:01:46.960 --> 00:01:48.880
you need to start writing methods.

00:01:48.880 --> 00:01:50.324
The CLOS model is to have 

00:01:50.324 --> 00:01:51.439
a generic function.

00:01:51.439 --> 00:01:52.399
A generic function is

00:01:52.399 --> 00:01:53.680
kind of like an interface, 

00:01:53.680 --> 00:01:55.600
it's just a name and an argument list,

01:55.600 --> 00:01:57.280
and there's no implementation,

00:01:57.280 --> 00:01:58.560
you have to write a method

00:01:58.560 --> 00:02:00.960
in order to have an actual implementation.

00:02:00.960 --> 00:02:02.880
When you call the generic function,

00:02:02.880 --> 00:02:04.960
the system will do a dynamic dispatch

00:02:04.960 --> 00:02:06.560
to a method that matches based on

00:02:06.560 --> 00:02:08.319
its argument types and how the method

00:02:08.319 --> 00:02:12.239
has declared that it should be invoked.

02:12.239 --> 00:02:14.239
Here's an example of some methods

00:02:14.239 --> 00:02:16.480
for our mpv player backend,

00:02:16.480 --> 00:02:19.599
you can see that it'll play anything

00:02:19.599 --> 00:02:21.200
other than something

00:02:21.200 --> 00:02:23.200
with a keyword of `unplayable`,

00:02:23.200 --> 00:02:25.328
and it just has dummy start and stop methods

00:02:25.328 --> 00:02:27.680
that return "Started" and "Stopped" text.

00:02:27.680 --> 00:02:29.599
A method is just one implementation

00:02:29.599 --> 00:02:30.552
of a generic function,

00:02:30.552 --> 00:02:32.640
and you can have as many as you need.

02:32.640 --> 00:02:33.920
In order to determine

00:02:33.920 --> 00:02:35.519
which method gets dispatched

00:02:35.519 --> 00:02:36.879
when you call a generic function,

00:02:36.879 --> 00:02:38.080
they're specialized based on

02:38.080 --> 00:02:39.360
their argument type.

00:02:39.360 --> 00:02:40.640
In this case, you can see that

00:02:40.640 --> 00:02:41.680
first argument says

00:02:41.680 --> 00:02:44.480
`player talk/emms-player-mpv`,

00:02:44.480 --> 00:02:46.239
that means that if that first argument

00:02:46.239 --> 00:02:48.480
is an instance of the mpv player

00:02:48.480 --> 00:02:50.080
or a subclass of it,

00:02:50.080 --> 00:02:52.000
then those methods will be invoked,

00:02:52.000 --> 00:02:53.560
unless there's a more specific one

00:02:53.560 --> 00:02:55.440
based on that argument type.

02:55.440 --> 00:02:56.656
You don't have to define 

00:02:56.656 --> 00:02:57.760
the generic functions.

00:02:57.760 --> 00:02:59.040
If you define a method,

00:02:59.040 --> 00:03:00.451
then it'll implicitly define

00:03:00.451 --> 00:03:03.599
the generic function for you.

03:03.599 --> 00:03:05.440
Specialization is really powerful.

00:03:05.440 --> 00:03:06.939
It lets the methods define 

00:03:06.939 --> 00:03:08.400
how they get invoked

00:03:08.400 --> 00:03:10.472
If you've done much programming in Clojure,

00:03:10.472 --> 00:03:12.959
this sounds a little bit like multi-methods,

00:03:12.959 --> 00:03:16.319
but with multi-methods, only the main method,

00:03:16.319 --> 00:03:18.000
the equivalent of the generic function,

00:03:18.000 --> 00:03:19.920
can determine how they're dispatched.

00:03:19.920 --> 00:03:21.519
So, as the writer of an interface,

00:03:21.519 --> 00:03:23.120
you might not be able to foresee 

00:03:23.120 --> 00:03:25.519
every way that someone who's implementing

00:03:25.519 --> 00:03:26.959
a version of that interface

03:26.959 --> 00:03:28.400
would like to dispatch.

00:03:28.400 --> 00:03:29.920
CLOS doesn't have that problem,

00:03:29.920 --> 00:03:31.200
you get to define your

03:31.200 --> 00:03:34.080
own invocation semantics.

03:34.080 --> 00:03:35.360
You're also not limited to

00:03:35.360 --> 00:03:37.200
dispatching based on the value

00:03:37.200 --> 00:03:39.920
being a subclass of an EIEIO type.

00:03:39.920 --> 00:03:41.280
You can dispatch based on

03:41.280 --> 00:03:42.879
a primitive type like integer,

00:03:42.879 --> 00:03:45.360
you can dispatch based on the value,

03:45.360 --> 00:03:47.599
you can dispatch on multiple arguments,

03:47.599 --> 00:03:49.599
and there's also a default dispatch

00:03:49.599 --> 00:03:50.688
that will get applied

00:03:50.688 --> 00:03:53.200
if there's no others that are defined.

00:03:53.200 --> 00:03:54.319
If you don't have a default,

00:03:54.319 --> 00:03:55.439
then you'll just get an error

03:55.439 --> 00:03:56.480
from the system,

00:03:56.480 --> 00:03:57.439
and if that doesn't cover it,

00:03:57.439 --> 00:03:59.040
you can even define your own.

03:59.040 --> 00:04:00.239
Definition is with the

00:04:00.239 --> 00:04:01.760
`cl-generic-generalizers`,

00:04:01.760 --> 00:04:03.680
which is itself a generic function.

00:04:03.680 --> 00:04:05.680
Much of CLOS is built in CLOS,

00:04:05.680 --> 00:04:08.319
which I think is really cool.

04:08.319 --> 00:04:09.599
In addition to all that,

00:04:09.599 --> 00:04:12.319
you have four different types of methods,

04:12.319 --> 00:04:13.680
and those are distinguished by

00:04:13.680 --> 00:04:16.000
what's called a qualifier.

04:16.000 --> 00:04:18.400
Every function can have methods

00:04:18.400 --> 00:04:20.239
that have all four different 

00:04:20.239 --> 00:04:21.280
types of qualifiers,

00:04:21.280 --> 00:04:22.960
and based on your class inheritance,

00:04:22.960 --> 00:04:25.680
you might have multiple of each type.

04:25.680 --> 00:04:26.800
There's the primary method,

00:04:26.800 --> 00:04:28.560
which is equivalent to the method

00:04:28.560 --> 00:04:29.919
in any other OOP system,

00:04:29.919 --> 00:04:32.160
so we're not going to cover that too much.

04:32.160 --> 00:04:33.759
Then there's a `before` method.

00:04:33.759 --> 00:04:35.600
This is evaluated before

00:04:35.600 --> 00:04:37.440
the primary method for side effects,

00:04:37.440 --> 00:04:40.080
and its return value is discarded.

00:04:40.080 --> 00:04:41.120
There's an `after` method,

00:04:41.120 --> 00:04:42.560
which is the same but happens after

00:04:42.560 --> 00:04:44.479
the method has finished evaluating.

04:44.479 --> 00:04:46.639
And then there's an `around` method

00:04:46.639 --> 00:04:49.199
that happens around all the other three.

04:49.199 --> 00:04:51.120
And by using these types of methods

00:04:51.120 --> 00:04:52.560
and using class inheritance

00:04:52.560 --> 00:04:54.560
to compose them into your classes,

00:04:54.560 --> 00:04:56.479
you can add some really powerful

00:04:56.479 --> 00:04:58.240
mixin type functionality.

00:04:58.240 --> 00:04:59.764
You can use before and after

00:04:59.764 --> 00:05:01.280
to build things like logging,

00:05:01.280 --> 00:05:02.479
and you can use around

00:05:02.479 --> 00:05:04.880
to implement things like memoization.

05:04.880 --> 00:05:06.720
If you've done much Emacs Lisp programming,

00:05:06.720 --> 00:05:08.160
those before after and around

00:05:08.160 --> 00:05:09.919
might jog your memory because

05:09.919 --> 00:05:11.440
they're the same features you get

00:05:11.440 --> 00:05:14.160
with Emacs's built-in function advice.

05:14.160 --> 00:05:15.680
The thing with function advice is that

05:15.680 --> 00:05:17.199
it only works on functions

00:05:17.199 --> 00:05:18.240
in the global namespace,

00:05:18.240 --> 00:05:20.360
and there's no kind of conditionality, 

00:05:20.360 --> 00:05:21.840
they always get dispatched

00:05:21.840 --> 00:05:23.440
when that function is invoked.

05:23.440 --> 00:05:25.600
The nice thing about the CLOS system is that

00:05:25.600 --> 00:05:27.039
whether they get invoked or not

05:27.039 --> 00:05:28.872
depends on whether they exist in

00:05:28.872 --> 00:05:30.160
the class hierarchy,

00:05:30.160 --> 00:05:31.520
so you can add them to your

00:05:31.520 --> 00:05:32.880
class hierarchy if you want

00:05:32.880 --> 00:05:34.000
that extra functionality 

00:05:34.000 --> 00:05:35.440
like logging or memoization,

00:05:35.440 --> 00:05:37.120
and you can exclude it if you don't.

00:05:37.120 --> 00:05:38.320
I think that's really powerful

05:38.320 --> 00:05:42.639
and a very interesting way of doing it.

05:42.639 --> 00:05:44.639
It also supports multiple inheritance,

05:44.639 --> 00:05:46.639
which is the mechanism that you can use

05:46.639 --> 00:05:48.560
to compose all these different kinds of

05:48.560 --> 00:05:50.479
behaviors into a single object that does

05:50.479 --> 00:05:52.240
all the things that you want.

00:05:52.240 --> 00:05:54.720
Here's a quick example of a logger.

00:05:54.720 --> 00:05:56.240
So, you can see the class just has

00:05:56.240 --> 00:05:58.319
a single slot called `messages`,

00:05:58.319 --> 00:05:59.840
it has a `log` method

00:05:59.840 --> 00:06:01.440
that pushes a new message,

00:06:01.440 --> 00:06:03.840
which is a format string, into that,

00:06:03.840 --> 00:06:05.520
and then it will return them back out,

00:06:05.520 --> 00:06:07.280
or it'll just return the latest.

06:07.280 --> 00:06:08.479
And there's a simple example

00:06:08.479 --> 00:06:09.600
that shows it logging,

00:06:09.600 --> 00:06:11.280
and then shows it coming back out,

00:06:11.280 --> 00:06:14.080
pretty much what you would expect.

06:14.080 --> 00:06:16.400
Here's another class that adapts

00:06:16.400 --> 00:06:19.039
the `emms-player` to the `logger` class.

00:06:19.039 --> 00:06:20.560
It only extends the logger

00:06:20.560 --> 00:06:22.400
because it doesn't need any features

00:06:22.400 --> 00:06:25.039
of the `emms-player` class itself.

00:06:25.039 --> 00:06:27.440
It just implements methods that dispatch

00:06:27.440 --> 00:06:30.240
based on it being that logging player class,

00:06:30.240 --> 00:06:31.759
and you can see it logs whenever

00:06:31.759 --> 00:06:34.240
a track is started or stopped,

00:06:34.240 --> 00:06:36.240
and it also adds some track

00:06:36.240 --> 00:06:37.520
to tell you whether or not 

00:06:37.520 --> 00:06:38.560
the track was playable,

00:06:38.560 --> 00:06:41.199
that is using the around method.

00:06:41.199 --> 00:06:43.199
So, you can see we have all three methods

00:06:43.199 --> 00:06:45.280
before, after, and around in this class,

00:06:45.280 --> 00:06:48.160
so you can see how those work.

00:06:48.160 --> 00:06:49.440
Then you need one more,

00:06:49.440 --> 00:06:50.184
which is the class

00:06:50.184 --> 00:06:51.759
that mixes it all together,

00:06:51.759 --> 00:06:54.080
So, that's the `logging-player-mpv`,

00:06:54.080 --> 00:06:56.639
and it extends both the `logging-player` class

06:56.639 --> 00:06:59.680
and the `emms-player-mpv` class.

06:59.680 --> 00:07:01.440
What's really interesting about this is

07:01.440 --> 00:07:03.360
that even though the logging player is

07:03.360 --> 00:07:05.520
part of the `emms-player` hierarchy,

00:07:05.520 --> 00:07:06.472
it doesn't depend on

00:07:06.472 --> 00:07:08.240
a specific implementation,

00:07:08.240 --> 00:07:10.400
so you can combine the two different

00:07:10.400 --> 00:07:12.639
classes that lets the logging class

00:07:12.639 --> 00:07:13.919
only care about logging,

07:13.919 --> 00:07:15.440
and the `emms-player` class

00:07:15.440 --> 00:07:17.039
only care about playing,

00:07:17.039 --> 00:07:18.240
and that is a really nice

07:18.240 --> 00:07:19.599
way of separating your concerns

00:07:19.599 --> 00:07:21.440
that I think is very powerful.

07:21.440 --> 00:07:22.515
Here's a quick example of

00:07:22.515 --> 00:07:23.599
just how that works,

00:07:23.599 --> 00:07:25.199
and you can see the `unplayable`

07:25.199 --> 00:07:26.160
track is not playable,

00:07:26.160 --> 00:07:27.840
and it gets logged as such,

00:07:27.840 --> 00:07:29.360
`foo` is playable, and you can see

07:29.360 --> 00:07:31.120
the logs in started and stopped.

00:07:31.120 --> 00:07:32.560
So, you can see it's having

00:07:32.560 --> 00:07:34.000
the side effects from those methods,

00:07:34.000 --> 00:07:36.960
and it's also returning 

00:07:36.960 --> 00:07:40.319
the value off the player as well.

07:40.319 --> 00:07:41.599
I think this system has a bunch of

07:41.599 --> 00:07:43.120
really nice properties.

07:43.120 --> 00:07:44.080
First and foremost,

00:07:44.080 --> 00:07:45.840
it feels like a normal Lisp,

00:07:45.840 --> 00:07:47.360
all you're doing is calling functions,

00:07:47.360 --> 00:07:49.840
there's no magic involved.

07:49.840 --> 00:07:51.919
Also, you can use either or both of the

07:51.919 --> 00:07:53.840
classes or generic functions.

00:07:53.840 --> 00:07:55.120
If you only need to

00:07:55.120 --> 00:07:56.960
encapsulate data into a structure,

00:07:56.960 --> 00:07:58.479
then you can only use classes,

07:58.479 --> 00:08:00.400
you don't have to use generic functions.

08:00.400 --> 00:08:02.080
And if you only need dynamic dispatch,

08:02.080 --> 00:08:03.068
you can only implement

00:08:03.068 --> 00:08:04.720
a generic function and methods.

00:08:04.720 --> 00:08:06.560
You don't get forced into a model

00:08:06.560 --> 00:08:08.000
where you have to use both.

00:08:08.000 --> 00:08:09.247
You can mix and match for

00:08:09.247 --> 00:08:10.800
whatever needs your program has,

00:08:10.800 --> 00:08:13.039
which I think is really amazing.

08:13.039 --> 00:08:15.440
Any value can conform to an interface,

08:15.440 --> 00:08:17.039
meaning a generic function.

00:08:17.039 --> 00:08:19.520
So, you don't have to use those classes.

00:08:19.520 --> 00:08:20.479
You can even implement

00:08:20.479 --> 00:08:22.240
a generic function over `nil`,

00:08:22.240 --> 00:08:23.599
which gives you those really nice

08:23.599 --> 00:08:24.800
properties of Lisp,

00:08:24.800 --> 00:08:26.460
where you have nil-punning, you know,

00:08:26.460 --> 00:08:28.800
if you take the head of a nil list,

00:08:28.800 --> 00:08:30.479
then the output is `nil`,

00:08:30.479 --> 00:08:31.283
but you can do that

00:08:31.283 --> 00:08:32.880
with your object system too.

00:08:32.880 --> 00:08:34.320
And a really nice feature of that is

08:34.320 --> 00:08:35.919
that you have no possibility of

00:08:35.919 --> 00:08:36.959
null pointer exceptions

00:08:36.959 --> 00:08:38.719
like you do in other languages.

00:08:38.719 --> 00:08:39.919
They have a calling convention

00:08:39.919 --> 00:08:42.880
where you call object dot method,

08:42.880 --> 00:08:45.600
but in CLOS, you call a generic function,

00:08:45.600 --> 00:08:47.279
and you just give it some arguments.

00:08:47.279 --> 00:08:48.959
Typically, the first one is going to be

00:08:48.959 --> 00:08:51.680
an EIEIO class object,

00:08:51.680 --> 00:08:53.200
but it doesn't have to be,

00:08:53.200 --> 00:08:54.640
but because you're not calling that

00:08:54.640 --> 00:08:55.519
instance of an object,

00:08:55.519 --> 00:08:57.279
there's nothing to be nil in the first place,

00:08:57.279 --> 00:08:58.320
so there's no possibility of

00:08:58.320 --> 00:09:00.080
a nil pointer exception.

09:00.080 --> 00:09:01.376
And then the ability to

00:09:01.376 --> 00:09:02.480
have multiple inheritance

00:09:02.480 --> 00:09:04.000
and mix in all of these different

00:09:04.000 --> 00:09:05.760
functionalities into your final object

00:09:05.760 --> 00:09:07.279
is very powerful.

09:07.279 --> 00:09:09.839
Because you have multiple inheritance,

00:09:09.839 --> 00:09:11.120
your final object that

00:09:11.120 --> 00:09:12.560
composes all of those things

00:09:12.560 --> 00:09:14.080
is both a player and a logger,

00:09:14.080 --> 00:09:15.600
and it can be substituted into code

00:09:15.600 --> 00:09:17.279
that expects either of them.

00:09:17.279 --> 00:09:19.040
It's not an adapter class

09:19.040 --> 00:09:21.360
that only allows you to do one thing,

00:09:21.360 --> 00:09:22.560
it does both of them.

00:09:22.560 --> 00:09:24.800
I think that's amazing.

09:24.800 --> 00:09:26.320
So, here are some practical examples

09:26.320 --> 00:09:27.387
where I think maybe this

00:09:27.387 --> 00:09:28.720
could be a good idea.

00:09:28.720 --> 00:09:30.399
And I like to think about,

09:30.399 --> 00:09:32.320
"What is OOP actually good for?".

00:09:32.320 --> 00:09:34.640
I think it has three really amazing powers,

09:34.640 --> 00:09:36.399
encapsulation, abstraction,

00:09:36.399 --> 00:09:37.279
and extensibility,

00:09:37.279 --> 00:09:39.200
so let's look at those.

09:39.200 --> 00:09:40.959
Encapsulation is just keeping

00:09:40.959 --> 00:09:42.480
related data together.

00:09:42.480 --> 00:09:43.680
Here's an example from the

09:43.680 --> 00:09:45.360
transmission Torrent client.

00:09:45.360 --> 00:09:46.399
In order for it to work,

00:09:46.399 --> 00:09:47.600
it needs to have all four of

09:47.600 --> 00:09:49.920
these variables set consistently,

00:09:49.920 --> 00:09:52.240
but if you use the customization interface,

09:52.240 --> 00:09:53.920
they're kind of strewn all over the buffer

00:09:53.920 --> 00:09:55.760
because that shows them alphabetically

00:09:55.760 --> 00:09:57.040
by variable name instead of

00:09:57.040 --> 00:09:59.920
grouping them logically by function.

09:59.920 --> 00:10:01.327
You also have all these

00:10:01.327 --> 00:10:02.480
in the global namespace,

00:10:02.480 --> 00:10:04.720
so you need this disambiguation in front,

00:10:04.720 --> 00:10:06.800
you have to have a transmission prefix,

00:10:06.800 --> 00:10:08.720
so it's kind of ugly.

10:08.720 --> 00:10:10.240
An alternative example would be to

10:10.240 --> 00:10:11.760
encapsulate all of that

00:10:11.760 --> 00:10:13.360
in a single class.

10:13.360 --> 00:10:16.160
This has one slot for each of those values,

00:10:16.160 --> 00:10:17.040
except the username

00:10:17.040 --> 00:10:18.000
and password is broken out,

00:10:18.000 --> 00:10:20.240
there was only one in the previous example,

00:10:20.240 --> 00:10:23.120
but it works pretty much the same.

10:23.120 --> 00:10:25.200
The really neat thing about this is that

10:25.200 --> 00:10:27.279
the customization interface understands

10:27.279 --> 00:10:29.920
how to customize EIEIO objects,

00:10:29.920 --> 00:10:32.640
so you can set your custom variable

00:10:32.640 --> 00:10:34.000
to the value of an object,

00:10:34.000 --> 00:10:35.760
and in the customization interface,

00:10:35.760 --> 00:10:37.040
it shows you all of the fields,

00:10:37.040 --> 00:10:38.399
and it lets you edit the values

00:10:38.399 --> 00:10:40.079
of those slots directly.

00:10:40.079 --> 00:10:41.760
So, that keeps that logical grouping

00:10:41.760 --> 00:10:44.800
that I think makes things really easy to use.

10:44.800 --> 00:10:46.160
Another thing it's really good at is

10:46.160 --> 00:10:48.268
abstraction, and this is really core to

00:10:48.268 --> 00:10:49.408
a lot of what Emacs does

00:10:49.408 --> 00:10:51.200
because it runs on so many different systems,

00:10:51.200 --> 00:10:53.308
and it works with so many different

00:10:53.308 --> 00:10:55.120
kinds of similar tools.

10:55.120 --> 00:10:56.109
Here's an example from

00:10:56.109 --> 00:10:58.079
the built-in SQL implementation.

00:10:58.079 --> 00:10:59.360
This is the definition of

00:10:59.360 --> 00:11:01.040
the postgres backend,

00:11:01.040 --> 00:11:02.160
there's one of these for

00:11:02.160 --> 00:11:04.000
every supported database backend.

00:11:04.000 --> 00:11:05.440
And you can see, this is a pretty

11:05.440 --> 00:11:08.480
classic interface abstraction pattern.

11:08.480 --> 00:11:09.680
On the left-hand side,

00:11:09.680 --> 00:11:10.880
you have a symbol that's common

00:11:10.880 --> 00:11:12.399
among all the database backends,

00:11:12.399 --> 00:11:14.160
and the code that doesn't 

00:11:14.160 --> 00:11:16.240
know about the implementation can use,

00:11:16.240 --> 00:11:17.519
no matter what implementation

00:11:17.519 --> 00:11:19.040
is being specified.

00:11:19.040 --> 00:11:20.000
On the right-hand side,

00:11:20.000 --> 00:11:21.120
you have the implementation

00:11:21.120 --> 00:11:22.560
specific values,

00:11:22.560 --> 00:11:24.399
in some cases these are just strings,

00:11:24.399 --> 00:11:25.760
or regexes, and in others

00:11:25.760 --> 00:11:27.519
those are actual functions.

11:27.519 --> 00:11:29.440
So, really this already is

00:11:29.440 --> 00:11:30.720
object orientation,

00:11:30.720 --> 00:11:32.959
it's just an ad-hoc system for it,

00:11:32.959 --> 00:11:34.880
but you don't have to use an ad-hoc system

00:11:34.880 --> 00:11:35.519
because there's this

00:11:35.519 --> 00:11:38.000
nice formal one instead.

11:38.000 --> 00:11:38.880
Another thing that it's

00:11:38.880 --> 00:11:40.959
really good at is extensibility,

00:11:40.959 --> 00:11:42.160
we saw some of that with

00:11:42.160 --> 00:11:44.800
the emms-player example earlier.

00:11:44.800 --> 00:11:46.160
But here's another thing I think

00:11:46.160 --> 00:11:48.720
it would be interesting to explore.

11:48.720 --> 00:11:51.279
Emacs has this idea of derived modes

11:51.279 --> 00:11:52.639
where you have a mode that's based on

11:52.639 --> 00:11:54.639
another, and that's a pretty clear

11:54.639 --> 00:11:57.040
inheritance pattern straight out of OOP

11:57.040 --> 00:11:58.560
as far as I'm concerned.

00:11:58.560 --> 00:12:00.079
What would it look like

00:12:00.079 --> 00:12:02.959
if major modes were EIEIO classes,

00:12:02.959 --> 00:12:04.800
and you could extend your mode

12:04.800 --> 00:12:06.399
by extending the class.

00:12:06.399 --> 00:12:08.240
I think that's a really interesting idea,

00:12:08.240 --> 00:12:10.880
and I'd like to explore that more.

12:10.880 --> 00:12:14.079
In conclusion, I think EIEIO is amazing,

12:14.079 --> 00:12:16.079
and I had no idea that such a powerful

12:16.079 --> 00:12:18.079
object orientation system

00:12:18.079 --> 00:12:20.160
was available in the Emacs.

12:20.160 --> 00:12:21.519
My goal with this talk

00:12:21.519 --> 00:12:23.519
is for anyone who writes Emacs Lisp,

00:12:23.519 --> 00:12:25.360
to look at these classes of problems,

00:12:25.360 --> 00:12:27.360
encapsulation, abstraction,

00:12:27.360 --> 00:12:28.639
and extensibility,

00:12:28.639 --> 00:12:29.600
and if you run into

00:12:29.600 --> 00:12:31.279
those problems in your code,

12:31.279 --> 00:12:33.279
instead of immediately reaching

00:12:33.279 --> 00:12:34.959
and building your own system,

00:12:34.959 --> 00:12:35.760
I want you to think:

00:12:35.760 --> 00:12:37.279
"Oh there's a thing for that,

00:12:37.279 --> 00:12:39.040
and I can just use it."

12:39.040 --> 00:12:40.560
That's my talk, thanks.

00:12:40.560 --> 00:12:41.560
Hack on!

00:12:41.560 --> 00:12:43.880
[captions by bhavin192 (Bhavin Gandhi)]