limited use of [index:string] about npm-ramda HOT 5 CLOSED

I have just trapped on this, and it confused me a lot. I expected "props" to have the same signature as "prop" except for input args. Why isn't it so? I believe loosing a bit of type safety is a affordable trade off here. At least there could be all possible overloads to choose from.
So as for me "props" should look like this.

props<T>(ps: string[]): (obj: any) => T[];

from npm-ramda.

Hey, I'm sorry for chiming in, but I think there are a lot of issues here:

1. The issue originally report by @donnut seems to no longer apply as of typescript 1.8, as indicated by the referenced stackoverflow question. Hence, we can (and should?) have the [index:string]

1.a) I really don't understand the third to six lines of the type signature in propEq:

    propEq<T>(name: string, val: T, obj: any): boolean;
    propEq<T>(name: number, val: T, obj: any): boolean;
    propEq<T>(name: string, val: T): (...args: any[]) => boolean;
    propEq<T>(name: number, val: T): (...args: any[]) => boolean;
    propEq<T>(name: string): (val: T, ...args: any[]) => boolean;
    propEq<T>(name: number): (val: T, ...args: any[]) => boolean;

Shouldn't it be:

    propEq<T>(name: string, val: T, obj: any): boolean;
    propEq<T>(name: number, val: T, obj: any): boolean;
    propEq<T>(name: string, val: T): (obj:any]) => boolean;
    propEq<T>(name: number, val: T): (obj:any) => boolean;
    propEq<T>(name: string): (val: T, obj:any) => boolean;
    propEq<T>(name: number): (val: T, obj:any) => boolean;

Or better yet, obj:{[index:string]: any } ?

2. I totally agree with @yazla that props and prop should have related signatures, which is not the case, and it is confusing. But given the new capabilities of the typescript compiler I mentioned above, I actually think it is prop which needs to be changed.

What do you think?

from npm-ramda.

Hum, I stand corrected, this seems to only be fixed on typescript 1.9, which is now bleeding edge / alpha. So, I guess if we are still some months away of having this PR fixed in a more 'production ready' environment :(

from npm-ramda.

That explains why my quick try wasn't able to reproduce it.

from npm-ramda.

At this point, TS 2.0 is stable, so the original issue should no longer be a concern. propEq has been adjusted in line with @jcristovao's request by now.

from npm-ramda.