Why there is no `creed.of` method?

The FL Applicative spec includes the of method but it does not seem to be available on creed:

> creed.of(1)
TypeError: creed.of is not a function

Any reason not to have it?

It could be mentioned that of is actually more basic than Applicative and is part of the Pointed Functor Spec, see also https://github.com/MostlyAdequate/mostly-adequate-guide-it/blob/master/ch9.md#pointy-functor-factory.

It seems that creed.fulfill is doing what of is meant to do, which is somewhat non-standard name and is longer to write. Also, when it is not called of, the question arises whether it conforms to the Pointed Functor spec, which I understand it does.

If creed.fulfill is indeed intended to satisfy the Pointed Functor spec (together with map), maybe also alias it as of and add tests for the spec?

[briancavalier]

tl;dr I’m open to simplifying/streamlining the API for a 2.0 release

@dmitriz Creed was intended to help bridge between A+ / ES and FL. It was created at a time when native promises had significant performance problems, async/await wasn’t easy to use everywhere, and FL was still fairly new.

So, many of the 1.x API decisions were made under quite different circumstances than exist today. It’s easier to see some of the API inconsistencies with hindsight. I’m sure there’s plenty of room for improvement, and I do appreciate your fresh perspective on it.

The API is intended to be used primarily as named exports, and creed.Promise is exported mostly just in case someone might ever need it. Perhaps not the best reason, but again, hindsight. of being on Promise was mostly for FL compat.

As @bergus mentioned, creed’s Promise was intended as a drop in replacement for A+/ES. The shim() function will forcibly install creed’s Promise as global Promise. There were (and still are, imho) advantages to that:

1. Afaik, creed is still faster and more memory friendly than native promises.
2. Using multiple promise implementations in a single app incurs assimilation penalties. Many promise implementations, including creed, can optimize interactions (bypassing then) with their own promises, but are forced to interact with other implementations by only using then. Thus, if your app uses explicit promise via creed, it is beneficial that other promises created via global Promise are also creed promises.
3. Creed’s async stack traces are pretty helpful.

All of that said, I’d certainly be open to simplifying/streamlining the API for a 2.0 release.

[unscriptable]

1. Creed’s async stack traces are pretty helpful.

Correction: Creed’s async stack traces are awesome!