WEBVTT

00:00:01.839 --> 00:00:04.160
Hello, EmacsConf!

00:00:04.160 --> 00:00:05.279
Thanks very much, first of all,

00:00:05.280 --> 00:00:07.200
to the organizers of the conference

00:00:07.200 --> 00:00:08.800
and to the audience,

00:00:08.801 --> 00:00:10.480
who I hope is out there somewhere,

00:00:10.480 --> 00:00:11.679
for giving me this chance

00:00:11.680 --> 00:00:12.880
to talk about Emacs

00:00:12.881 --> 00:00:16.240
and some of my poking around with Emacs Lisp.

00:00:16.241 --> 00:00:17.680
My name is Eric Abrahamsen.

00:00:17.681 --> 00:00:20.480
I'm not a professional programmer,

00:00:20.481 --> 00:00:23.039
but I use Emacs all day, every day,

00:00:23.040 --> 00:00:24.800
for writing, for translating,

00:00:24.800 --> 00:00:26.160
for project management,

00:00:26.160 --> 00:00:27.920
and most importantly, for email,

00:00:27.921 --> 00:00:30.640
which will be the subject of my talk today.

00:00:30.641 --> 00:00:32.880
So I'm talking about

00:00:32.881 --> 00:00:34.160
object-oriented code

00:00:34.161 --> 00:00:38.320
in Emacs' most famous, possibly oldest,

00:00:38.320 --> 00:00:39.520
definitely most notorious

00:00:39.521 --> 00:00:42.800
news reader / email client,

00:00:42.801 --> 00:00:44.000
so, in particular,

00:00:44.001 --> 00:00:46.000
object-oriented code in Gnus.

00:00:46.001 --> 00:00:50.239
Why object-oriented code?

00:00:50.239 --> 00:00:51.199
The way Gnus works is

00:00:51.200 --> 00:00:52.480
it started off as a news reader,

00:00:52.481 --> 00:00:55.920
so for accessing NNTP servers

00:00:55.921 --> 00:00:57.600
and later on grew a whole bunch

00:00:57.601 --> 00:00:59.760
of new functionality as a mail client,

00:00:59.761 --> 00:01:02.079
so it can talk to IMAP servers,

00:01:02.079 --> 00:01:04.320
Maildir directories,

00:01:04.321 --> 00:01:05.360
folders on your file system,

00:01:05.361 --> 00:01:06.640
all kinds of stuff,

00:01:06.640 --> 00:01:08.320
but it presents a unified interface

00:01:08.321 --> 00:01:08.960
to all those things,

00:01:08.961 --> 00:01:11.040
so it's basically polymorphism,

00:01:11.040 --> 00:01:14.560
one of the the basic fundamental principles

00:01:14.561 --> 00:01:15.680
of object oriented code.

00:01:15.681 --> 00:01:17.600
So it's a good fit.

00:01:17.601 --> 00:01:21.439
Second reason is it already is object-oriented,

00:01:21.440 --> 00:01:25.280
and I'll get into what that means in a second.

00:01:25.281 --> 00:01:28.479
So the background that you should know

00:01:28.480 --> 00:01:30.000
is that most of this code

00:01:30.001 --> 00:01:32.560
was written in the 90s.

00:01:32.560 --> 00:01:34.880
Emacs Lisp has only grown sort of

00:01:34.881 --> 00:01:38.640
official object orientation support libraries

00:01:38.640 --> 00:01:41.200
over the past 10 years or so,

00:01:41.200 --> 00:01:42.799
from about 2010 to the present.

00:01:42.800 --> 00:01:45.920
So what does Gnus do?

00:01:45.921 --> 00:01:49.520
So the basics of object orientation

00:01:49.521 --> 00:01:50.560
in most languages are:

00:01:50.560 --> 00:01:53.439
you define a class of some sort,

00:01:53.440 --> 00:01:55.040
and then you instantiate that class.

00:01:55.041 --> 00:01:57.920
These class instances have two things:

00:01:57.921 --> 00:02:00.719
they have data attributes (or slots,

00:02:00.720 --> 00:02:01.680
or members, or whatever

00:02:01.681 --> 00:02:02.640
you're going to call them),

00:02:02.641 --> 00:02:05.600
and they have methods

00:02:05.601 --> 00:02:08.399
which operate on individual instances.

00:02:08.399 --> 00:02:10.239
So you could say that

00:02:10.240 --> 00:02:11.840
you create or instantiate

00:02:11.841 --> 00:02:12.800
an instance of a class,

00:02:12.801 --> 00:02:14.800
and that instance owns two things.

00:02:14.801 --> 00:02:17.120
That owns its set of attributes,

00:02:17.120 --> 00:02:19.520
and it owns some methods,

00:02:19.521 --> 00:02:23.280
which also work on the instance.

00:02:23.280 --> 00:02:25.680
Both in Gnus' existing code

00:02:25.681 --> 00:02:28.560
and in the more standard object-oriented

00:02:28.561 --> 00:02:31.680
Emacs Lisp libraries, this relationship

00:02:31.681 --> 00:02:34.080
is turned on its head a little bit,

00:02:34.080 --> 00:02:39.599
in that data slots and instance methods

00:02:39.600 --> 00:02:41.760
are defined outside of the class

00:02:41.761 --> 00:02:42.959
or the instances themselves.

00:02:42.959 --> 00:02:45.040
They are top-level definitions.

00:02:45.040 --> 00:02:46.879
We'll get to what that means

00:02:46.879 --> 00:02:48.720
in the newer libraries in a bit,

00:02:48.721 --> 00:02:49.920
but first I want to talk about

00:02:49.921 --> 00:02:51.280
how Gnus does this.

00:02:51.281 --> 00:02:52.160
In order to do that,

00:02:52.161 --> 00:02:54.319
we are going to go deep into

00:02:54.319 --> 00:02:55.760
the darkest corner

00:02:55.761 --> 00:02:58.080
of the Gnus source code tree

00:02:58.081 --> 00:03:01.440
to a library called nnoo.el,

00:03:01.441 --> 00:03:04.080
very cryptically-titled library,

00:03:04.081 --> 00:03:06.800
and when we open it up, we find

00:03:06.800 --> 00:03:09.280
a library with no code comments

00:03:09.281 --> 00:03:11.040
and almost no doc strings.

00:03:11.040 --> 00:03:12.800
Almost as if Lars was a little ashamed--

00:03:12.800 --> 00:03:14.159
not ashamed, but knew he was doing

00:03:14.159 --> 00:03:16.000
something a little bit crazy

00:03:16.000 --> 00:03:18.080
and didn't want anyone to see.

00:03:18.081 --> 00:03:20.560
So this file contains

00:03:20.561 --> 00:03:22.400
the object-oriented mechanism

00:03:22.400 --> 00:03:23.920
whereby you can define

00:03:23.921 --> 00:03:25.760
different kinds of backends for Gnus,

00:03:25.760 --> 00:03:26.799
and then those backends

00:03:26.800 --> 00:03:30.879
can be instantiated as individual servers.

00:03:30.880 --> 00:03:32.480
As you define these backends,

00:03:32.480 --> 00:03:34.319
you're supposed to use two macros,

00:03:34.320 --> 00:03:35.680
which you can see here.

00:03:35.681 --> 00:03:37.280
One is called defvoo,

00:03:37.281 --> 00:03:39.440
and one is called deffoo.

00:03:39.441 --> 00:03:40.400
If you look at the definitions,

00:03:40.401 --> 00:03:41.920
the definitions look pretty simple.

00:03:41.921 --> 00:03:45.440
Here, defvoo basically turns into a defvar

00:03:45.440 --> 00:03:49.040
and foo turns into a defun.

00:03:49.040 --> 00:03:52.239
Along with those basic definitions,

00:03:52.239 --> 00:03:55.760
the library also does some registration,

00:03:55.760 --> 00:03:58.720
memoization, caching of those variables.

00:03:58.720 --> 00:04:00.879
It saves them in the structure for later use,

00:04:00.880 --> 00:04:03.360
so that we know that those are meant to be

00:04:03.360 --> 00:04:04.799
attributes and methods

00:04:04.800 --> 00:04:06.640
that are used with instances,

00:04:06.640 --> 00:04:07.519
with server instances.

00:04:07.520 --> 00:04:08.159
But you can see that

00:04:08.160 --> 00:04:10.000
there's no server instance definition here.

00:04:10.001 --> 00:04:12.159
There's no, like, no nothing.

00:04:12.160 --> 00:04:14.799
These are top-level definitions,

00:04:14.800 --> 00:04:20.239
so really, data attributes for new servers

00:04:20.240 --> 00:04:23.040
and methods or functions

00:04:23.041 --> 00:04:24.639
that operate on those instances

00:04:24.640 --> 00:04:27.840
are completely separate mechanisms.

00:04:27.841 --> 00:04:29.040
They don't really have anything to do

00:04:29.041 --> 00:04:29.520
with each other.

00:04:29.521 --> 00:04:31.680
They don't belong to the same data structures.

00:04:31.680 --> 00:04:34.080
So how do they work?

00:04:34.081 --> 00:04:37.120
Follow me. deffoo and defvoo,

00:04:37.120 --> 00:04:38.960
aka methods and attributes,

00:04:38.961 --> 00:04:41.360
these are all the things I just said.

00:04:41.360 --> 00:04:50.240
So when you define a a backend type in Gnus,

00:04:50.241 --> 00:04:52.400
what you get is this: a definition, a list.

00:04:52.400 --> 00:04:55.520
It'll say, there is such a backend as nnml,

00:04:55.520 --> 00:04:58.880
and these are its data attributes

00:04:58.880 --> 00:05:01.039
that any given instance can have,

00:05:01.040 --> 00:05:04.720
and then these are the functions or methods

00:05:04.721 --> 00:05:06.880
that are defined to operate on

00:05:06.880 --> 00:05:08.240
an instance of this backend,

00:05:08.241 --> 00:05:09.600
so a server that belongs to

00:05:09.601 --> 00:05:12.160
the nnml backend.

00:05:12.161 --> 00:05:13.600
So at least we have this data here.

00:05:13.601 --> 00:05:16.080
That's handy. We don't really touch that.

00:05:16.081 --> 00:05:19.600
That's, like, very, very, very deep Gnus code

00:05:19.601 --> 00:05:20.560
that doesn't really come up

00:05:20.560 --> 00:05:25.199
even as a bug squasher or whatever.

00:05:25.200 --> 00:05:26.160
We don't touch that very often,

00:05:26.161 --> 00:05:26.800
but there they are,

00:05:26.801 --> 00:05:29.199
and that's how they work.

00:05:29.200 --> 00:05:31.039
Now the next thing that obviously

00:05:31.040 --> 00:05:32.080
you want to know is, okay,

00:05:32.080 --> 00:05:33.759
where are... if I've started up Gnus,

00:05:33.760 --> 00:05:35.039
where are my servers?

00:05:35.039 --> 00:05:36.880
Where are these server objects,

00:05:36.881 --> 00:05:40.479
since this is object-oriented programming?

00:05:40.480 --> 00:05:41.520
And the weird thing

00:05:41.521 --> 00:05:43.759
that you will eventually figure out

00:05:43.760 --> 00:05:45.680
(in some cases, after years of poking around)

00:05:45.681 --> 00:05:46.880
in the Gnus source code

00:05:46.880 --> 00:05:48.880
is that servers do not exist

00:05:48.881 --> 00:05:51.360
in an ontological, philosophical sense,

00:05:51.361 --> 00:05:55.280
as objects. The primary data structures of Gnus

00:05:55.281 --> 00:05:58.160
are groups, and in sort of

00:05:58.161 --> 00:06:00.560
an object-oriented hierarchical mindset,

00:06:00.561 --> 00:06:03.039
you'd think, well, groups belong to servers,

00:06:03.040 --> 00:06:05.759
so servers must exist, but they don't.

00:06:05.759 --> 00:06:07.840
Each group... And here you can see

00:06:07.841 --> 00:06:09.360
some examples of groups...

00:06:09.360 --> 00:06:11.199
These are basically the data structures

00:06:11.199 --> 00:06:12.240
that represent a group.

00:06:12.241 --> 00:06:14.160
Each group also has a little entry here

00:06:14.161 --> 00:06:17.039
that tells you what server it belongs to,

00:06:17.039 --> 00:06:20.080
and each group replicates that data,

00:06:20.081 --> 00:06:21.600
saying which server it belongs to.

00:06:21.601 --> 00:06:24.000
So when Gnus is going through

00:06:24.001 --> 00:06:25.280
doing its business,

00:06:25.281 --> 00:06:27.039
trying to figure out updating mail

00:06:27.040 --> 00:06:28.479
from the groups or whatever,

00:06:28.480 --> 00:06:30.960
almost every time, it will cycle through

00:06:30.961 --> 00:06:32.960
all the list of groups.

00:06:32.960 --> 00:06:34.960
It'll look at all the server definitions,

00:06:34.960 --> 00:06:38.160
and it will categorize the groups by server,

00:06:38.160 --> 00:06:40.000
which is just weird,

00:06:40.001 --> 00:06:41.680
because you're sort of looking for...

00:06:41.681 --> 00:06:42.720
okay, where does the server exist?

00:06:42.721 --> 00:06:43.440
It doesn't exist.

00:06:43.441 --> 00:06:46.240
It's put together every time

00:06:46.241 --> 00:06:50.400
out of code elsewhere in the Gnus code base,

00:06:50.400 --> 00:06:53.599
specifically from these group definitions.

00:06:53.600 --> 00:06:54.479
So this is very odd,

00:06:54.480 --> 00:06:56.319
because in some sense...

00:06:56.320 --> 00:06:59.360
Like here, this one, its server is nnml

00:06:59.361 --> 00:07:01.680
and an empty string,

00:07:01.681 --> 00:07:02.880
so there's a certain sense here

00:07:02.881 --> 00:07:04.720
in which this server is not really

00:07:04.721 --> 00:07:06.160
an object at all. What it is

00:07:06.161 --> 00:07:07.120
is a set of instructions

00:07:07.121 --> 00:07:08.560
for how to find messages,

00:07:08.560 --> 00:07:10.319
and this set of instructions is:

00:07:10.320 --> 00:07:12.000
go to the default place

00:07:12.001 --> 00:07:14.000
where the user might have their mail

00:07:14.001 --> 00:07:16.319
and expect to find messages there

00:07:16.320 --> 00:07:18.479
in an nnml format, which is basically

00:07:18.480 --> 00:07:21.759
just one message per file.

00:07:21.760 --> 00:07:22.720
Any number of groups could have

00:07:22.721 --> 00:07:24.400
those same instructions, but they're not...

00:07:24.401 --> 00:07:25.440
It's not really a thing.

00:07:25.440 --> 00:07:26.720
It's really just a...

00:07:26.720 --> 00:07:28.639
It's more of a procedural instruction.

00:07:28.639 --> 00:07:30.160
On the other end of the spectrum,

00:07:30.161 --> 00:07:32.240
you might have an nnimap server,

00:07:32.241 --> 00:07:33.280
which very much is a thing.

00:07:33.281 --> 00:07:36.160
It has its own server, its own port,

00:07:36.161 --> 00:07:38.960
its own authentication system.

00:07:38.961 --> 00:07:40.639
So some of the servers are more like things,

00:07:40.640 --> 00:07:42.400
some of the servers are more like instructions.

00:07:42.400 --> 00:07:45.520
As Gnus works right now,

00:07:45.520 --> 00:07:47.280
most of the servers are treated like

00:07:47.280 --> 00:07:48.879
just instruction sets,

00:07:48.879 --> 00:07:50.879
and there's no place where you can

00:07:50.880 --> 00:07:51.840
go and find them.

00:07:51.841 --> 00:07:53.680
There's no one central variable

00:07:53.681 --> 00:07:56.160
that defines them all. So how do the...

00:07:56.160 --> 00:07:57.759
We'll talk about the methods in a second.

00:07:57.760 --> 00:07:59.520
How do the data attributes work?

00:07:59.520 --> 00:08:02.639
Put very crudely,

00:08:02.639 --> 00:08:04.479
your servers, when they're put together,

00:08:04.479 --> 00:08:06.879
they are kept in a variable,

00:08:06.880 --> 00:08:08.080
and it's called nnoo

00:08:08.080 --> 00:08:08.960
nno

00:08:08.960 --> 00:08:11.120
state a list and there's a concept to

00:08:11.120 --> 00:08:12.960
this of the current server

00:08:12.960 --> 00:08:16.560
so when we go here let's go back to

00:08:16.560 --> 00:08:19.039
our nnno definition a list so when we

00:08:19.039 --> 00:08:20.560
have an nnml

00:08:20.560 --> 00:08:22.240
server say we have one here and it's

00:08:22.240 --> 00:08:24.400
just this blank string

00:08:24.400 --> 00:08:26.639
these are all when you define that in

00:08:26.639 --> 00:08:28.879
your own uh server definition code

00:08:28.879 --> 00:08:31.919
you can put in different values for all

00:08:31.919 --> 00:08:32.399
of these

00:08:32.399 --> 00:08:35.760
various attributes and when noose comes

00:08:35.760 --> 00:08:37.039
when it comes time for news to operate

00:08:37.039 --> 00:08:38.959
on this server in particular ask it to

00:08:38.959 --> 00:08:40.640
you know open a group or get new mail

00:08:40.640 --> 00:08:42.080
what it will do is it will take

00:08:42.080 --> 00:08:45.360
that particular server's data from these

00:08:45.360 --> 00:08:45.920
symbols

00:08:45.920 --> 00:08:47.600
and it will copy all that information

00:08:47.600 --> 00:08:49.600
into the global devfars

00:08:49.600 --> 00:08:51.760
so for the time that you are operating

00:08:51.760 --> 00:08:53.120
on this particular server

00:08:53.120 --> 00:08:55.920
its individual data becomes the values

00:08:55.920 --> 00:08:56.800
of these global

00:08:56.800 --> 00:08:59.360
variables which when you realize what's

00:08:59.360 --> 00:09:00.560
happening is sort of terrifying you

00:09:00.560 --> 00:09:02.080
think oh my god

00:09:02.080 --> 00:09:04.480
but at the same time it's actually kind

00:09:04.480 --> 00:09:05.760
of impressive and it's amazing that it

00:09:05.760 --> 00:09:07.279
works as well as it does

00:09:07.279 --> 00:09:09.120
I'm actually a little bit in awe of the

00:09:09.120 --> 00:09:10.880
of the code in this in this library I

00:09:10.880 --> 00:09:12.560
think it's pretty impressive

00:09:12.560 --> 00:09:15.760
so as you nno change server

00:09:15.760 --> 00:09:18.320
uh this function here these values get

00:09:18.320 --> 00:09:20.080
copied into the global value into the

00:09:20.080 --> 00:09:21.440
global variables and then as you go on

00:09:21.440 --> 00:09:22.399
the next server

00:09:22.399 --> 00:09:24.000
that gets you know cleaned out and

00:09:24.000 --> 00:09:26.399
recopied there are a few

00:09:26.399 --> 00:09:29.680
um a few other slot types

00:09:29.680 --> 00:09:32.000
or attribute types which do because all

00:09:32.000 --> 00:09:33.440
of these attributes see they all start

00:09:33.440 --> 00:09:34.720
with the nml

00:09:34.720 --> 00:09:37.920
or in this case and in folder prefix

00:09:37.920 --> 00:09:40.560
but there are a few slot types that all

00:09:40.560 --> 00:09:41.760
servers need for

00:09:41.760 --> 00:09:43.279
for instance their most recent status

00:09:43.279 --> 00:09:45.920
message a status symbol like open denied

00:09:45.920 --> 00:09:46.640
whatever

00:09:46.640 --> 00:09:48.080
and that data is sort of scattered

00:09:48.080 --> 00:09:49.680
around the rest of the news

00:09:49.680 --> 00:09:51.200
code base in various variables or

00:09:51.200 --> 00:09:53.440
various places

00:09:53.440 --> 00:09:55.440
so that's that sort of just contributes

00:09:55.440 --> 00:09:56.560
to the confusion when you're trying to

00:09:56.560 --> 00:09:57.360
figure out why

00:09:57.360 --> 00:10:00.720
things are going wrong so that is our

00:10:00.720 --> 00:10:03.839
um nnoo which is and

00:10:03.839 --> 00:10:05.440
sort of how the attributes and these

00:10:05.440 --> 00:10:07.360
global variables work

00:10:07.360 --> 00:10:09.120
if we want to talk about defu and the

00:10:09.120 --> 00:10:10.480
methods we

00:10:10.480 --> 00:10:20.800
go to

00:10:20.800 --> 00:10:23.200
and so this is the place where all the

00:10:23.200 --> 00:10:25.600
server level methods are defined

00:10:25.600 --> 00:10:27.200
and what we have here are things like

00:10:27.200 --> 00:10:29.279
here's an example there's closed server

00:10:29.279 --> 00:10:32.640
this closed server is given a

00:10:32.640 --> 00:10:36.320
a server as a an argument

00:10:36.320 --> 00:10:38.079
it looks at the server and basically it

00:10:38.079 --> 00:10:40.560
finds the proper function to call on

00:10:40.560 --> 00:10:42.079
this particular server

00:10:42.079 --> 00:10:45.120
using the function new skip function by

00:10:45.120 --> 00:10:45.600
taking

00:10:45.600 --> 00:10:48.959
the sort of latter half of this function

00:10:48.959 --> 00:10:49.760
symbol

00:10:49.760 --> 00:10:52.079
and pasting it together with the symbol

00:10:52.079 --> 00:10:53.440
that represents the back end so

00:10:53.440 --> 00:10:56.800
if you were calling this on an nni map

00:10:56.800 --> 00:10:59.600
server your skip function would look at

00:10:59.600 --> 00:11:01.279
your imap server look at closed server I

00:11:01.279 --> 00:11:02.240
knew what

00:11:02.240 --> 00:11:07.839
it would come up with

00:11:07.839 --> 00:11:10.240
server sure enough there's an imac close

00:11:10.240 --> 00:11:11.920
server and it'll call this code and then

00:11:11.920 --> 00:11:12.240
it'll

00:11:12.240 --> 00:11:14.000
it'll go and do its other bookkeeping

00:11:14.000 --> 00:11:15.279
another sort of

00:11:15.279 --> 00:11:18.320
surrounding code and so that's not that

00:11:18.320 --> 00:11:19.279
actually works pretty well

00:11:19.279 --> 00:11:22.640
uh as as things go uh defu

00:11:22.640 --> 00:11:24.959
makes a record that this this function

00:11:24.959 --> 00:11:26.800
exists and nus gets function get

00:11:26.800 --> 00:11:28.320
function looks on that cache finds the

00:11:28.320 --> 00:11:29.600
function and calls it

00:11:29.600 --> 00:11:30.959
now what's particularly confusing is

00:11:30.959 --> 00:11:32.560
that you don't actually even have to use

00:11:32.560 --> 00:11:33.360
defu

00:11:33.360 --> 00:11:35.519
so whoever wrote and then mail gear

00:11:35.519 --> 00:11:38.399
which is a weird library

00:11:38.399 --> 00:11:39.920
said to heck with you I'm not using any

00:11:39.920 --> 00:11:41.600
of these

00:11:41.600 --> 00:11:43.120
any of this machinery I'm going to do it

00:11:43.120 --> 00:11:45.839
myself so we have

00:11:45.839 --> 00:11:49.680
def structs to hold uh the instance

00:11:49.680 --> 00:11:52.320
data and then we have just plain old

00:11:52.320 --> 00:11:53.040
defense

00:11:53.040 --> 00:11:55.680
for things like animal your close server

00:11:55.680 --> 00:11:57.279
request close all of these

00:11:57.279 --> 00:11:59.279
these server level uh variables and it

00:11:59.279 --> 00:12:00.320
just turns out that

00:12:00.320 --> 00:12:03.360
news in its belt and suspenders

00:12:03.360 --> 00:12:05.839
approach to uh to coding it'll actually

00:12:05.839 --> 00:12:07.279
just go out if it can't find

00:12:07.279 --> 00:12:10.320
the memoized function it'll just go out

00:12:10.320 --> 00:12:12.160
and say has anybody defined a function

00:12:12.160 --> 00:12:14.240
that looks like this pattern and then

00:12:14.240 --> 00:12:16.000
and then melder says yes I did and then

00:12:16.000 --> 00:12:17.920
we call it and then we go so it's just

00:12:17.920 --> 00:12:19.920
it's fine it works it just adds to the

00:12:19.920 --> 00:12:21.440
confusion why

00:12:21.440 --> 00:12:24.240
why does it work we don't know sometimes

00:12:24.240 --> 00:12:25.440
the only thing worse than not knowing

00:12:25.440 --> 00:12:26.880
why something doesn't work is

00:12:26.880 --> 00:12:30.000
not knowing why something does work um

00:12:30.000 --> 00:12:30.560
and then

00:12:30.560 --> 00:12:31.920
a last little bit I want to touch on

00:12:31.920 --> 00:12:33.680
here is inheritance which is another

00:12:33.680 --> 00:12:35.440
sort of cornerstone of object-oriented

00:12:35.440 --> 00:12:38.480
coding as far as I can tell only uh

00:12:38.480 --> 00:12:40.160
the only inheritance that goes on is in

00:12:40.160 --> 00:12:41.920
something called nn male

00:12:41.920 --> 00:12:45.519
which provides sort of common functions

00:12:45.519 --> 00:12:48.399
for back ends that keep their mail on

00:12:48.399 --> 00:12:49.360
your

00:12:49.360 --> 00:12:52.000
local machine and you can spool it you

00:12:52.000 --> 00:12:53.680
can delete it you can you know you own

00:12:53.680 --> 00:12:55.440
the messages it's not like an nntp

00:12:55.440 --> 00:12:56.160
server

00:12:56.160 --> 00:12:59.040
and so a lot of those male deer nnml

00:12:59.040 --> 00:13:00.160
whatever

00:13:00.160 --> 00:13:02.959
a lot of those have sort of similar code

00:13:02.959 --> 00:13:04.079
which they

00:13:04.079 --> 00:13:07.600
which they share via this nn mail

00:13:07.600 --> 00:13:09.600
you call it an abstract parent class I

00:13:09.600 --> 00:13:12.959
guess so if you have something like nnml

00:13:12.959 --> 00:13:15.440
it has a request scan uh when it goes

00:13:15.440 --> 00:13:16.720
into request scan

00:13:16.720 --> 00:13:18.800
it ends up calling nnmail.newmail and it

00:13:18.800 --> 00:13:21.760
says I am calling this as an nml server

00:13:21.760 --> 00:13:23.279
and here are some of my callback

00:13:23.279 --> 00:13:24.959
functions and my variables that I would

00:13:24.959 --> 00:13:26.000
like you to use

00:13:26.000 --> 00:13:28.000
when you are getting your email so in

00:13:28.000 --> 00:13:30.120
this way the code is sort of you know

00:13:30.120 --> 00:13:33.120
inter-interleaved between the the child

00:13:33.120 --> 00:13:35.680
class and the parent class even though

00:13:35.680 --> 00:13:37.120
we're not talking in terms of classes

00:13:37.120 --> 00:13:39.440
here at all really

00:13:39.440 --> 00:13:42.160
so that's how noose works right now I

00:13:42.160 --> 00:13:42.959
hope that's clear

00:13:42.959 --> 00:13:45.519
it certainly wasn't to me and I still

00:13:45.519 --> 00:13:46.560
have to go refresh my

00:13:46.560 --> 00:13:48.079
memory I'd like to talk a little bit

00:13:48.079 --> 00:13:50.079
about sort of the newer

00:13:50.079 --> 00:13:51.600
libraries that are available now for

00:13:51.600 --> 00:13:54.240
doing object-oriented code

00:13:54.240 --> 00:13:56.959
uh as I mentioned I think earlier nno

00:13:56.959 --> 00:13:59.279
the copyright headers for 1996 so that's

00:13:59.279 --> 00:14:00.320
pretty venerable

00:14:00.320 --> 00:14:02.639
coincidentally around the same time eric

00:14:02.639 --> 00:14:05.519
ludlum started developing e-I-e-I-o

00:14:05.519 --> 00:14:08.320
which is a which is sort of inspired by

00:14:08.320 --> 00:14:09.360
a common lisp's

00:14:09.360 --> 00:14:12.720
common lisp object system um I got a

00:14:12.720 --> 00:14:14.240
very good introduction to that from this

00:14:14.240 --> 00:14:14.959
book

00:14:14.959 --> 00:14:16.399
practical common lisp which I would

00:14:16.399 --> 00:14:18.000
encourage you to look at if you haven't

00:14:18.000 --> 00:14:20.079
which you probably have anyway

00:14:20.079 --> 00:14:22.320
e-I-e-I-o was incorporated into Emacs in

00:14:22.320 --> 00:14:23.920
2010

00:14:23.920 --> 00:14:27.839
so that yeah e-I-e-I-o provides um

00:14:27.839 --> 00:14:30.240
the deaf class statements it provides

00:14:30.240 --> 00:14:32.079
deaf generics deaf methods all that sort

00:14:32.079 --> 00:14:32.639
of stuff

00:14:32.639 --> 00:14:34.800
sort of a common lisp object-oriented

00:14:34.800 --> 00:14:36.320
code

00:14:36.320 --> 00:14:38.399
at some point stephan monier's money

00:14:38.399 --> 00:14:39.760
money another name I haven't pronounced

00:14:39.760 --> 00:14:41.199
it all out

00:14:41.199 --> 00:14:43.839
started either cleaning up that code or

00:14:43.839 --> 00:14:45.120
for one reason or another writing a

00:14:45.120 --> 00:14:46.959
re-implementation of generic functions

00:14:46.959 --> 00:14:48.000
which was added

00:14:48.000 --> 00:14:51.440
uh in 2015 and then throughout this time

00:14:51.440 --> 00:14:51.920
another

00:14:51.920 --> 00:14:54.639
sort of object-oriented style

00:14:54.639 --> 00:14:55.760
declaration is

00:14:55.760 --> 00:14:58.160
defstruct which started off in the cl

00:14:58.160 --> 00:15:00.000
libraries

00:15:00.000 --> 00:15:01.600
implemented with vectors later was

00:15:01.600 --> 00:15:02.959
implemented with records so they're

00:15:02.959 --> 00:15:04.639
easier to target

00:15:04.639 --> 00:15:06.720
anyway that's another option so how

00:15:06.720 --> 00:15:08.399
would we this is I'm probably out of

00:15:08.399 --> 00:15:09.279
time already but

00:15:09.279 --> 00:15:13.839
we're only getting to the part

00:15:13.839 --> 00:15:15.760
the whole point of this is how would we

00:15:15.760 --> 00:15:17.920
rewrite someone news's code to use these

00:15:17.920 --> 00:15:19.920
newer libraries

00:15:19.920 --> 00:15:21.760
if we didn't have to support third party

00:15:21.760 --> 00:15:23.839
libraries this wouldn't be that hard

00:15:23.839 --> 00:15:26.639
but out there noose is really up on uh

00:15:26.639 --> 00:15:28.160
you know backwards compatibility and not

00:15:28.160 --> 00:15:30.240
breaking people's stuff and you know

00:15:30.240 --> 00:15:33.040
multi-decade support for things so there

00:15:33.040 --> 00:15:34.240
are people out there who have written

00:15:34.240 --> 00:15:35.759
third-party libraries

00:15:35.759 --> 00:15:38.480
um defining new backends for you can use

00:15:38.480 --> 00:15:40.000
like hacker news or whatever as

00:15:40.000 --> 00:15:41.759
a as a server so we want to be able to

00:15:41.759 --> 00:15:43.199
support those if you didn't have to

00:15:43.199 --> 00:15:44.240
support those it'd be fine you'd

00:15:44.240 --> 00:15:46.079
re-implement you'd use generic functions

00:15:46.079 --> 00:15:47.440
you'd use either structure classes

00:15:47.440 --> 00:15:48.560
whatever but we got a

00:15:48.560 --> 00:15:51.040
it's a little bit tricky to support

00:15:51.040 --> 00:15:52.000
these other people's

00:15:52.000 --> 00:15:54.320
libraries so one of the things we can do

00:15:54.320 --> 00:15:56.079
is rewrite the defu

00:15:56.079 --> 00:15:59.279
so if you remember defu is the thing

00:15:59.279 --> 00:16:00.079
that uh

00:16:00.079 --> 00:16:03.120
or sorry uh defu

00:16:03.120 --> 00:16:04.800
is the thing that defines methods that

00:16:04.800 --> 00:16:07.040
operate on object answers

00:16:07.040 --> 00:16:10.160
instances and we can uh rewrite that to

00:16:10.160 --> 00:16:10.639
use

00:16:10.639 --> 00:16:13.440
cldef generic and that's this is fairly

00:16:13.440 --> 00:16:14.240
fairly simple

00:16:14.240 --> 00:16:15.440
it looks like a lot of code it's not a

00:16:15.440 --> 00:16:17.759
lot of good for instance we have the

00:16:17.759 --> 00:16:20.320
new closed server code that we looked at

00:16:20.320 --> 00:16:21.199
earlier

00:16:21.199 --> 00:16:22.720
and we have this phone call and the new

00:16:22.720 --> 00:16:24.560
skip function so this would look

00:16:24.560 --> 00:16:28.720
like using generic functions and methods

00:16:28.720 --> 00:16:30.240
it would look like this we'd have

00:16:30.240 --> 00:16:32.959
a generic def generic which is just a

00:16:32.959 --> 00:16:34.560
sort of a declaration

00:16:34.560 --> 00:16:36.320
and a doc string and then we have those

00:16:36.320 --> 00:16:37.680
implementations

00:16:37.680 --> 00:16:40.320
so we can see what the original code

00:16:40.320 --> 00:16:42.399
does here is it first says okay what

00:16:42.399 --> 00:16:44.720
type is our our is our argument here and

00:16:44.720 --> 00:16:45.839
if it's a string

00:16:45.839 --> 00:16:48.560
then go and get the proper s the proper

00:16:48.560 --> 00:16:50.160
method definition

00:16:50.160 --> 00:16:52.480
from that string so the way we do that

00:16:52.480 --> 00:16:53.920
with methods is we

00:16:53.920 --> 00:16:56.000
we say if the server is a string so if

00:16:56.000 --> 00:16:57.440
it matches this type

00:16:57.440 --> 00:16:58.720
then what we're going to do is just

00:16:58.720 --> 00:17:00.320
recall we're going to call this function

00:17:00.320 --> 00:17:02.160
all over again

00:17:02.160 --> 00:17:05.199
using uh basically the same code here

00:17:05.199 --> 00:17:06.400
the same code that takes a string and

00:17:06.400 --> 00:17:07.600
gets the object so

00:17:07.600 --> 00:17:10.640
this does this can add extra function

00:17:10.640 --> 00:17:11.600
calls

00:17:11.600 --> 00:17:12.880
depending on how you've written the rest

00:17:12.880 --> 00:17:14.880
of your code um but this is sort of the

00:17:14.880 --> 00:17:16.640
canonical way of doing this

00:17:16.640 --> 00:17:19.679
uh using methods then our next part here

00:17:19.679 --> 00:17:20.559
is

00:17:20.559 --> 00:17:22.000
nishkit function we're going to get a

00:17:22.000 --> 00:17:24.559
function called closed server

00:17:24.559 --> 00:17:26.079
the difference here is that all these

00:17:26.079 --> 00:17:27.360
functions are all going to be called

00:17:27.360 --> 00:17:28.000
close

00:17:28.000 --> 00:17:29.360
news close server they're not going to

00:17:29.360 --> 00:17:31.120
be called news like nni my

00:17:31.120 --> 00:17:32.799
closed server and ntp close server

00:17:32.799 --> 00:17:34.400
they're all going to have the same name

00:17:34.400 --> 00:17:36.160
and what we do is uh we have an around

00:17:36.160 --> 00:17:37.440
method

00:17:37.440 --> 00:17:40.640
for any server that is a const which is

00:17:40.640 --> 00:17:43.679
which is as close as we care to get uh

00:17:43.679 --> 00:17:45.520
for you know zeroing in on the type that

00:17:45.520 --> 00:17:46.799
we're looking for

00:17:46.799 --> 00:17:48.559
we put in a round method on that so that

00:17:48.559 --> 00:17:50.480
we can call the next method which we'll

00:17:50.480 --> 00:17:51.679
call the more specific

00:17:51.679 --> 00:17:53.440
method and then we have our other

00:17:53.440 --> 00:17:55.600
bookkeeping code to clean up you know

00:17:55.600 --> 00:17:57.280
set up tear down code we'll go around

00:17:57.280 --> 00:17:58.640
that

00:17:58.640 --> 00:18:00.080
and then in one of the back-end

00:18:00.080 --> 00:18:02.080
definitions for instance in an imap

00:18:02.080 --> 00:18:04.320
we have another news closed server thing

00:18:04.320 --> 00:18:05.760
this looks at the server

00:18:05.760 --> 00:18:08.880
and it says is this server a list that

00:18:08.880 --> 00:18:10.799
starts with a symbol and an imap and if

00:18:10.799 --> 00:18:12.480
it is then we're almost guaranteed that

00:18:12.480 --> 00:18:13.679
this is what we wanted

00:18:13.679 --> 00:18:15.840
and then this is where we would insert

00:18:15.840 --> 00:18:17.600
all the rest of the code from anonymous

00:18:17.600 --> 00:18:18.960
closed server

00:18:18.960 --> 00:18:20.799
where we'd re-redefine that to look like

00:18:20.799 --> 00:18:22.880
this so it's not that hard

00:18:22.880 --> 00:18:26.080
theoretically so what we would do

00:18:26.080 --> 00:18:28.720
is take the defu macro macro and then

00:18:28.720 --> 00:18:29.679
rewrite that

00:18:29.679 --> 00:18:32.240
so that it actually defines a cl def

00:18:32.240 --> 00:18:33.039
method like

00:18:33.039 --> 00:18:35.520
one of these now there's a couple of

00:18:35.520 --> 00:18:36.320
these things

00:18:36.320 --> 00:18:38.960
unfortunately it's not that easy get rid

00:18:38.960 --> 00:18:41.200
of you

00:18:41.200 --> 00:18:43.490
a couple of these things

00:18:43.490 --> 00:18:46.400
[Music]

00:18:46.400 --> 00:18:49.039
that don't use their server as the first

00:18:49.039 --> 00:18:49.919
argument

00:18:49.919 --> 00:18:52.400
or any of the arguments or it's an

00:18:52.400 --> 00:18:53.280
optional argument

00:18:53.280 --> 00:18:54.720
and we need the server to be in there to

00:18:54.720 --> 00:18:56.640
dispatch on its type

00:18:56.640 --> 00:18:58.799
if the server doesn't show up as a as a

00:18:58.799 --> 00:19:00.080
required

00:19:00.080 --> 00:19:01.760
argument we're not going to be able to

00:19:01.760 --> 00:19:03.600
locate the the proper

00:19:03.600 --> 00:19:07.440
function call so in the case of

00:19:07.440 --> 00:19:10.640
noose request group here we start with

00:19:10.640 --> 00:19:12.080
the group it's the group that matters

00:19:12.080 --> 00:19:12.720
and we get

00:19:12.720 --> 00:19:14.960
the newscommand method as an optional

00:19:14.960 --> 00:19:16.240
argument

00:19:16.240 --> 00:19:18.559
so that's not cool we don't want that so

00:19:18.559 --> 00:19:20.480
what we need instead is something that

00:19:20.480 --> 00:19:21.360
looks like this

00:19:21.360 --> 00:19:23.840
what we're going to do with uh this is

00:19:23.840 --> 00:19:25.360
gonna be just terrible terrible code but

00:19:25.360 --> 00:19:26.640
hopefully it won't get used very often

00:19:26.640 --> 00:19:28.160
it's gonna be really embarrassing

00:19:28.160 --> 00:19:30.559
um defu what's what definitely was gonna

00:19:30.559 --> 00:19:31.520
have to do is

00:19:31.520 --> 00:19:33.200
say okay is this a function that doesn't

00:19:33.200 --> 00:19:34.559
have the server as the first argument

00:19:34.559 --> 00:19:35.360
and if it does

00:19:35.360 --> 00:19:36.960
it's gonna say oh it's news request

00:19:36.960 --> 00:19:38.400
group what happens has to happen with

00:19:38.400 --> 00:19:39.280
news request group

00:19:39.280 --> 00:19:40.799
is we take the news command method and

00:19:40.799 --> 00:19:43.200
we're going to move it up to the front

00:19:43.200 --> 00:19:46.240
to the first argument here and it's

00:19:46.240 --> 00:19:47.520
either going to be

00:19:47.520 --> 00:19:48.720
it's either going to be given or it's

00:19:48.720 --> 00:19:50.840
going to be nil because it's it is

00:19:50.840 --> 00:19:52.080
optional

00:19:52.080 --> 00:19:54.320
okay I briefly edited the space time

00:19:54.320 --> 00:19:55.760
continuum there to conceal the fact that

00:19:55.760 --> 00:19:56.400
I had

00:19:56.400 --> 00:19:57.679
actually not finished writing the code

00:19:57.679 --> 00:19:59.440
that I was supposed to write anyway

00:19:59.440 --> 00:20:02.159
um so now we have once we've reordered

00:20:02.159 --> 00:20:02.960
the

00:20:02.960 --> 00:20:04.320
the arguments to the function then we

00:20:04.320 --> 00:20:05.760
have to check our various possible

00:20:05.760 --> 00:20:06.880
values one is

00:20:06.880 --> 00:20:08.640
uh that the server was not passed in in

00:20:08.640 --> 00:20:10.080
which case we recall

00:20:10.080 --> 00:20:12.400
request group with the server um the

00:20:12.400 --> 00:20:13.840
other is that it's just a string in

00:20:13.840 --> 00:20:15.360
which case we do that and then this is

00:20:15.360 --> 00:20:16.559
sort of the the normal

00:20:16.559 --> 00:20:18.559
the normal case that we would expect to

00:20:18.559 --> 00:20:20.720
cons so that's not that bad it's not you

00:20:20.720 --> 00:20:21.039
know

00:20:21.039 --> 00:20:23.760
it's not beautiful um I would be sort of

00:20:23.760 --> 00:20:24.480
ashamed to

00:20:24.480 --> 00:20:26.159
let anybody see that particular macro

00:20:26.159 --> 00:20:28.000
but I think that it would work okay

00:20:28.000 --> 00:20:30.640
now the more difficult thing is going to

00:20:30.640 --> 00:20:31.440
be

00:20:31.440 --> 00:20:34.640
the data variables so

00:20:34.640 --> 00:20:37.600
the equivalent of def vu because our two

00:20:37.600 --> 00:20:39.360
options for defining classes here are

00:20:39.360 --> 00:20:41.039
def struct and def class both of which

00:20:41.039 --> 00:20:41.919
required you

00:20:41.919 --> 00:20:45.280
to define the slots inside this macro

00:20:45.280 --> 00:20:46.960
itself

00:20:46.960 --> 00:20:49.039
so defu is top level um how do we get

00:20:49.039 --> 00:20:51.280
the top level this top level macro

00:20:51.280 --> 00:20:55.039
uh to insert slot names into these

00:20:55.039 --> 00:20:56.240
definitions it's

00:20:56.240 --> 00:20:58.960
it's possible that it'll be um that I

00:20:58.960 --> 00:21:00.240
could monkey patch

00:21:00.240 --> 00:21:03.039
uh an existing struct or an existing

00:21:03.039 --> 00:21:04.799
class to add a new slot into it that

00:21:04.799 --> 00:21:05.280
sounds

00:21:05.280 --> 00:21:07.760
ugly the other option would be to give

00:21:07.760 --> 00:21:09.600
it a server variable slot which is just

00:21:09.600 --> 00:21:11.520
a generalized bucket

00:21:11.520 --> 00:21:13.760
that holds anything that gets defined

00:21:13.760 --> 00:21:15.520
via def loop

00:21:15.520 --> 00:21:16.720
I don't like either of those solutions

00:21:16.720 --> 00:21:18.799
but I'm I don't see any other

00:21:18.799 --> 00:21:22.480
any other way of doing that so we re

00:21:22.480 --> 00:21:25.520
rewrite the nno declare macro to either

00:21:25.520 --> 00:21:27.440
be a destructor or a def class

00:21:27.440 --> 00:21:29.840
and we rewrite the def boom macro to

00:21:29.840 --> 00:21:31.039
somehow

00:21:31.039 --> 00:21:33.039
associate that variable name the symbol

00:21:33.039 --> 00:21:34.480
with the with the resulting class

00:21:34.480 --> 00:21:36.159
definition

00:21:36.159 --> 00:21:37.760
then the last question is do we use

00:21:37.760 --> 00:21:39.600
structure classes

00:21:39.600 --> 00:21:41.600
they both got their their strengths and

00:21:41.600 --> 00:21:43.200
their weaknesses

00:21:43.200 --> 00:21:46.480
the nice thing is that I mean I've got

00:21:46.480 --> 00:21:47.520
how many servers you're going to have

00:21:47.520 --> 00:21:49.600
really I've got I think less than 10

00:21:49.600 --> 00:21:51.919
uh truly deranged mine might have as as

00:21:51.919 --> 00:21:52.960
many as

00:21:52.960 --> 00:21:55.440
50 let's double that to 100 100 of

00:21:55.440 --> 00:21:56.480
anything is not going to matter it

00:21:56.480 --> 00:21:58.400
doesn't matter what we use

00:21:58.400 --> 00:22:00.159
death structures are simpler they're

00:22:00.159 --> 00:22:02.720
lighter weight they're defined on top of

00:22:02.720 --> 00:22:05.600
the direct the c records so you know

00:22:05.600 --> 00:22:06.960
that's nice

00:22:06.960 --> 00:22:08.559
the slots don't carry very much

00:22:08.559 --> 00:22:10.320
information with them there's no type

00:22:10.320 --> 00:22:11.760
information there's no doc string for

00:22:11.760 --> 00:22:14.480
the slots themselves

00:22:14.480 --> 00:22:16.559
they can also only do single inheritance

00:22:16.559 --> 00:22:17.919
which some might say

00:22:17.919 --> 00:22:21.120
was an advantage def class each slot

00:22:21.120 --> 00:22:22.640
gets a lot more information associated

00:22:22.640 --> 00:22:24.000
with it with it which I think can be

00:22:24.000 --> 00:22:24.480
nice

00:22:24.480 --> 00:22:27.120
it can do multiple inheritance if you're

00:22:27.120 --> 00:22:28.799
going to go there

00:22:28.799 --> 00:22:30.720
they are heavier weight in particular

00:22:30.720 --> 00:22:32.640
their printed representation is gross

00:22:32.640 --> 00:22:34.080
it's enormous

00:22:34.080 --> 00:22:35.840
so if you see one show up in a back

00:22:35.840 --> 00:22:37.520
trace or in your messages buffer can

00:22:37.520 --> 00:22:38.240
really

00:22:38.240 --> 00:22:39.520
it can really blow that up and make it

00:22:39.520 --> 00:22:41.360
hard to read this of course won't be an

00:22:41.360 --> 00:22:43.200
issue because our code won't have any

00:22:43.200 --> 00:22:46.240
errors in it um my argument for multiple

00:22:46.240 --> 00:22:48.320
inheritance here is that I can imagine

00:22:48.320 --> 00:22:51.280
new servers falling into sort of like a

00:22:51.280 --> 00:22:52.720
little two by two matrix of

00:22:52.720 --> 00:22:56.240
of parent classes one being news versus

00:22:56.240 --> 00:22:56.799
mail

00:22:56.799 --> 00:23:00.320
so news the messages belong to somebody

00:23:00.320 --> 00:23:00.720
else

00:23:00.720 --> 00:23:02.080
you can't touch them you can't delete

00:23:02.080 --> 00:23:03.840
them mail meaning

00:23:03.840 --> 00:23:06.000
the messages are under your command

00:23:06.000 --> 00:23:08.960
either a local mail dealer a remote imap

00:23:08.960 --> 00:23:11.039
you're allowed to spool them copy them

00:23:11.039 --> 00:23:12.640
delete them at will

00:23:12.640 --> 00:23:13.919
and then the other sort of line of the

00:23:13.919 --> 00:23:16.400
matrix would be a local file system

00:23:16.400 --> 00:23:19.760
versus some kind of a you know server

00:23:19.760 --> 00:23:20.559
port

00:23:20.559 --> 00:23:23.280
remote access and that second the server

00:23:23.280 --> 00:23:24.960
port remote access thing might require

00:23:24.960 --> 00:23:26.880
authentication it might require a keep

00:23:26.880 --> 00:23:28.559
alive for a connection

00:23:28.559 --> 00:23:30.159
um it's there's going to be a process

00:23:30.159 --> 00:23:31.600
there rather than just file system

00:23:31.600 --> 00:23:32.400
commands

00:23:32.400 --> 00:23:33.840
so I could see if I was going to do

00:23:33.840 --> 00:23:35.360
multiple inheritance that's what I would

00:23:35.360 --> 00:23:36.240
do those two

00:23:36.240 --> 00:23:39.039
those two possible parent classes anyway

00:23:39.039 --> 00:23:40.400
that's as far as I've gotten

00:23:40.400 --> 00:23:41.520
I thought that I would be able to write

00:23:41.520 --> 00:23:43.279
more of this code before I did this talk

00:23:43.279 --> 00:23:44.720
but instead I spent the whole time

00:23:44.720 --> 00:23:46.720
messing with video codecs but that's

00:23:46.720 --> 00:23:48.320
where we're at and I'm going to cut

00:23:48.320 --> 00:23:49.440
myself off now

00:23:49.440 --> 00:23:50.960
I hope there are questions I hope I'm

00:23:50.960 --> 00:23:53.440
there to to answer your questions

00:23:53.440 --> 00:23:55.919
and thanks very much again to everyone

00:23:55.919 --> 00:23:57.120
involved

00:23:57.120 --> 00:23:59.279
bye