atlas-engineer/nhooks

nhooks's Issues

Is it necessary to support adding named function themselves?

We don't get anything out of it, it seems -- adding anonymous function objects won't work because they don't have a name, and for named function, one can just add symbols themselves.

And it is easily misused. An extra #' instead of ' will screw up redefinitionability.

add-hook does not allow overriding existing handler

Currently calling add-hook over a handler with an existing name is a no-op.

But what if we want to replace the handler in question?

Right now, the only way is to remove the handler then re-add it.

I wonder if it's really what's most expected. It seems to me that we would normally expect the latest version of a handler to be registered.

So I suggest reverting the behaviour: add-hook replace handlers with the same name, and if the user does not want it, they can just check for existence with find-handler.

Thoughts? @BlueFlo0d

Version bump

Seems that we are pretty much ready. Release 1.0.0 then? @BlueFlo0d

Unexport `*hook*`?

Is it expected to re-export *hook* in nhook?
Is there a use case?

Should `equals` only compare `place` and not `value`?

In atlas-engineer/nyxt#2451 we are manually replacing the existing setter handler. This is most certainly something that nhooks should do for us by default.

One possible fix is to change equals so that it only compares the place, and not the value.
But then the notion of equality is a bit dubious.

Alternatively, keep equals as it is and just add another check in add-hook to remove existing setter.

@aartaka Thoughts?

CCL support?

Serapeum contrib hooks have support for CCL since the ftype is declaimed.

With the `nhooks' approach, it does not work anymore as highlighted here:
#5 (comment)

Any idea, anyone?

Release new version?

We've got at least one change.

Would be nice to answer the question on the README's roadmap: can handlers be generic functions?
The problem might be with type checking...

List all hooks

To implement hook listing as a command/function, one'd need to go through all the slots and variables and find those that are nhooks:hook-typed, which not all of the hooks are (let alone the strictness of typing on different implementations). Listing instances of nhooks:hook and subclasses may be better, but the best approach to it would be non-portable at best.

There is another way: in the nhooks library we can tweak the initializer to references all the hooks, which would then be reported by a nhooks:all-hooks functions or the like.

But this does not report the bound symbols, if any.
The first approach does it however.

Do we want both approaches?

This is a fairly general problem in CL, others must have dealt with it before, nah?