eieio question / `dufun'kt Elisp

eieio question / `dufun'kt Elisp

[Emanuel Berg]

eieio again, question first thing, is there a better way to
express booleans or just what we call t or nil than to call
them symbols? Since a lot of things are symbols. Example:

(defclass cyclic (borderless)
    <incal>   ((src     :initarg :src     :type list   :initform nil)
    <incal>    (enabled :initarg :enabled :type symbol :initform nil)))

This part of eieio is very useful BTW, we should have
something similar for defuns as well. Check type, set to
default value, validate, associate with useful data and
metadata all in *one* chart, all automated and after it
is done.

Compared to plain Elisp it is a dream. The important thing
isn't is it OO not, is it functional, is it something else,
blaha blaha, rather two questions are important

(1) is there a plan and policy how to handle and reduce the
    complexity that is inevitable? (i.e. a plan that works)

(2) is it optimized for development speed and the
    physical/mental well-being of the coder?

You gotta have "yes" on both those in 2024 to stay relevant.
with eieio - yes, in its own way, absolutely.

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

Re: eieio question / `dufun'kt Elisp

[Thierry Volpiatto]

Emanuel Berg <incal@dataswamp.org> writes:

> eieio again, question first thing, is there a better way to
> express booleans or just what we call t or nil than to call
> them symbols?

    :custom boolean

-- 
Thierry

Re: eieio question / `dufun'kt Elisp

[Emanuel Berg]

Thierry Volpiatto wrote:

>> eieio again, question first thing, is there a better way to
>> express booleans or just what we call t or nil than to call
>> them symbols?
>
>     :custom boolean

Okay, that easy. How do you know what types there are?
They mention several functions in cl- that do related business
but I've yet to find just a list?

Thanks!

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