all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* modern OO
@ 2024-09-12  6:40 Emanuel Berg
  0 siblings, 0 replies; only message in thread
From: Emanuel Berg @ 2024-09-12  6:40 UTC (permalink / raw)
  To: emacs-devel

In the other thread I wrote a bunch of stuff on eieio, which
has impressed me a lot.

Now I also remember what I complained about further that eieio
has solved, or rather that was ages before I said that, of
course, but nevertheless - and that is the problems with the
`defun' interfaces - both interactive and "from Lisp".

But I have already written about that so won't repeat myself
unnecessarily, 'nuff said, that particular thing, with
conventions, documentation, default values, validation
(including/not the least with respect to type), it got that
covered which is a HUGE boost.

But what I wanted to ask eieio is from 1995! :O

When you use it, it doesn't feel that old - it feels good -
but it is old, no doubt, and when you look thru the source you
see this even more - it is inheritance (sub- and
superclasses), abstract classes, multiple inheritance with
interfaces, tree traversal order, accessors to the slots (the
members; getters and setters), and types, types, and
more types.

This is old-school OO where you focus a lot, too much some
would say, on data, encapsulation, data hiding, private and
public members, and validators in getters and setters; also
old-school OO has a much bigger focus on inheritance and
creating subclasses. Even I, who think inheritance is
over-rated and error-prone, as it gets out of hand (not just
I say this), but even I started to use it much more than
I thought I ever would.

Modern-OO is not so much focused on data, optimally it should
be just that - encapsulated and hidden, coupled with the
methods that operate on it - so then, why return anything at
all, really? Instead of the data focus the focus is what the
objects should do. So the saying is "tell, don't ask", i.e.
tell the object what to do, and provide them with everything
they need (send the whole inventory lock and stock, if that is
what they need), just provide them with everything they need
to do their particular job.

I agree this is much better than "asking" for information to
be returned, "what do you know about Ivan?" - why, so I can
contact him rather than the object? But if they object isn't
doing anything, why do we want it? To give us a number and
leave us with the task of calling? Oh, no, that whole ideology
of returning stuff is from functional programming, and, while
it works for just that, stuff get returned, other than that,
nothing gets done, everyone just manipulate data ever so
slightly and then it is - returned.

But that said, not that eieio works well for both styles, it
isn't forcing you to use getters and setters but you can use
methods (draw-wall (w wall)) - tell/provide/do rather than
ask/compute/return.

So I wonder if Emacs has more OO implementations I could try?

Okay, keep it real, thanks for this session. Zzz

-- 
underground experts united
https://dataswamp.org/~incal




^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2024-09-12  6:40 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-12  6:40 modern OO Emanuel Berg

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.