Skip to content

Consider changing the name of the package? #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
cyberglot opened this issue Apr 29, 2021 · 2 comments
Open

Consider changing the name of the package? #1

cyberglot opened this issue Apr 29, 2021 · 2 comments

Comments

@cyberglot
Copy link

LVar is a thing that already exists and even though your package seems fairly related, LVars have precise semantics. It would be nicer if we could avoid confusion among all our vars.

@srid
Copy link
Owner

srid commented Apr 29, 2021

Ah, I didn't know that something else was already using the Data.LVar namespace.

Sure, let's change it. I would like to have something that is shortish and easy to remember, which is why I avoided names like TMVarL or TMLVar.

What about SVar (as subscribe-able)? Will have to look at other possibilities ...

EDIT: Or maybe TLVar, as a compromise.

EDIT(note to self): Pick a suitable name $foo, so that addon packages can be named appropriately, eg: $foo-filesystem for fsnotify based "mounting" on to LVar (or don't bother with this, and choose say fsmount as the package that uses tlvar package).

@ju1m
Copy link

ju1m commented Jan 21, 2023

@srid, your LVar looks rather like a special case (the TMVar case) of push-based reactive values.
For comparison, here's some other (more or less well implemented, more or less thread-safe) variants of reactive values:

Anyway, just to attach some context around your LVar in case that might help naming it, or improve the interface.

EDIT: There's also transient's EVar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants