fantasyland / fantasy-land

Specification for interoperability of common algebraic structures in JavaScript
MIT License
10.11k stars 375 forks source link

Why putting "fantasy-land/" before everything in readme? #335

Open babak-karimi-asl opened 1 year ago

babak-karimi-asl commented 1 year ago

for example instead of writing :

a['fantasy-land/equals'](a) === true

why not just:

a.equals( a ) === true , or just simply a equals a .

or this: a['fantasy-land/concat'](b)['fantasy-land/concat'](c) is equivalent to a['fantasy-land/concat'](b['fantasy-land/concat'](c)) (associativity)

to this: a.concat(b).concat(c) === a.concat(b.concat(c)) (associativity)

these concepts are confusing enough by themselves, specially for beginners , so no need to add more complications.

CrossEye commented 1 year ago

You can see the discussion in #92.

A short example: if we don't specify a prefix like that, then a geospatial library with a geographic map method cannot be made Fantasyland compatible, because Fantasyland claims the ownership of the map method. But with the prefix, there's no conflict. It does make these docs hard to read, though, and I'd love to see a good fix for that.

babak-karimi-asl commented 1 year ago

@CrossEye thanks for responding.

this is fantasy-land's readme , so it belongs to fantasy-land.

it can be declared at the top of the readme : all of the below methods are in "fantasy-land" namespace.

Avaq commented 11 months ago

@babak-karimi-asl I think it's because of what Fantasy Land tries to be. Fantasy Land is: "A specification for interoperability of common algebraic structures", not "a specification of common algebraic structures". Therefore, with the focus on interoperability, the exact JavaScript structures take the front stage and legibility of the laws (which are defined in many other places) comes second.