Move all functions to namespaced Type Representative

Recently, I started updating two libs (creed and most) to support FL 2.0, and added Static Land support to most. In the process, I read this thread that led to standardizing on Type Representatives for static functions like of and empty.

All of that led me to the thought of leveraging Type Representatives more fully. I wanted to put the idea out for discussion to see if it seems interesting:

Rather than many namespaced methods, e.g. x[fl.map](f), FL could move to functions on a single namespaced Type Representative, e.g. x[fl].map(f, x), where x[fl] is the location of x’s Type Representative, and fl is the only required FL string/Symbol.

This is obviously a substantial change, but I think it would have several benefits:

1. It standardizes on functions, rather than a mix of functions and methods.
2. It reduces the number of namespaced properties on instances to exactly 1, allowing functions on the Type Representative to be non-namespaced (though they could remain namespaced if that’s desirable)
3. It removes the need to use .constructor as the location of the Type Representative. Although, it may also be worth considering whether it’s useful to add the Type Representative as Constructor[fl] for cases where where no instance is available.
4. While it doesn’t completely unify FL and Static Land, it does come close:
   • this new, richer Type Representative is effectively a Static Land dictionary, and
   • provides a standard location for Static Land dictionaries. When an instance is available, it reduces the need to explicitly pass Static Land dictionaries around.

I don’t think this has many downsides compared to the current FL 2.0 approach. For example, ergonomics: the prefixed methods required by FL 2.0 are, imho, already fairly unergonomic for app devs. Library devs will endure them in order to get the benefits of being FL compliant. Moving to functions on a single namespaced type representative seems like it retains the same level of ergonomics.

Any FL delegation library such as fantasy-sorcery or Ramda would need to change its dispatching, which would be a breaking change, but the dispatching is no more complex.

What do you think of the idea of having all functions on a single namespaced Type Representative?

[rpominov]

Hi all. Could you please vote on this?

In theory, if I’d create a PR for this, would you prefer it to has minimal amount of changes, or would bring most of static-land with itself?

🎉 for as minimal changes as possible, ❤️ for the whole package.

Note that I’ve worked a lot on the structure and terminology of static-land, and in my opinion it would make sense to use what I’ve ended up with. If we try to preserve that of current Fantasy Land document the result might be confusing and harder to understand.

Also note that if you vote I will not automatically expect of you to support the PR, just want to know what you think has a higher chance of moving forward.

And I probably won’t open a PR right away, there will be a temporary fork, which we’ll be able to polish before an attempt on final merge. I just want to understand what is better direction in your opinion.

[rpominov]

I would love to, but actually I’m not sure I’m good for the task. I think this’ll require basically a rewrite from a whole different perspective. And having wrote static-land I’m not sure I like the result. My english is mediocre, and education in some areas related to the specification also not great. So not sure I should do this, but I want to help in other ways.

Also it feels like we need more discussion on the specifics before any PR. And it won’t be manageable to do all of them in this issue, or inside a PR. So I thought having a temporal repository to manage this process is a good idea.