Skip to content
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

"Static method" or properties on functions gives rise to issue #22408

Closed
babakness opened this issue Mar 8, 2018 · 6 comments
Closed

"Static method" or properties on functions gives rise to issue #22408

babakness opened this issue Mar 8, 2018 · 6 comments
Labels
Duplicate An existing issue was already created

Comments

@babakness
Copy link

I looked for duplicates, perhaps this is related?
#5863

Not sure...

Suppose we have some IO function that returns an object. In Javascript, Classes are more or less just functions

const IO = f => ({
  f,
  map: g => IO( (...args) => g ( f(...args) ) ) ,
  join: () => f()
})

IO.of = (val) => IO(()=>val)

The of class function raises an issue with Property 'of' does not exist on type '(f: any) => { f: any; map: (g: any) => any; join: () => any; }'.

Expected behavior is that TS understands that of is a property or "static method" of sorts on the IO function.

The error goes away by doing one of the following

const IO = (f => ({
  f,
  map: g => IO( (...args) => g ( f(...args) ) ) ,
  join: () => f()
})) as any

Or something like this

interface P {
  f: any,
  map: (f) => P,
  join: any
}
interface F { 
  (f): P; 
  of: (f) => P; 
}


const IO = (f => ({
  f,
  map: g => IO( (...args) => g ( f(...args) ) ) ,
  join: () => f()
})) as F


IO.of = (val) => IO(()=>val)

It seems that of should be inferred without this however. Also, in the later example, Intellisense doesn't seem to realize that map return a new copy of P interface but that is probably news for a different team ;-)

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. labels Mar 8, 2018
@RyanCavanaugh
Copy link
Member

We do this sort of inference in JavaScript now; see #21974

For TypeScript it's a bit less obvious because we don't want every property write to be equivalent to a property declaration, so it becomes an exercise in dividing up the gray areas into "You tried to write to a non-existant property (error)" and "You intended to declare a new property via an assignment".

@yortus
Copy link
Contributor

yortus commented Mar 9, 2018

I'd be wary of implicit property declarations in TypeScript, because they would mask a common source of errors (ie typos) that TypeScript currently catches. I think its better to keep some explicit syntax difference so TS can continue to distinguish between new property declarations and plain old typos.

@yortus
Copy link
Contributor

yortus commented Mar 10, 2018

Also this seems to be covered by #15868. @RyanCavanaugh you already approved that one 😁.

@RyanCavanaugh
Copy link
Member

We're pretty skeptical (in the classical sense) of implicit property declarations, but there are a few places where it seems safe. For example, immediately following a function declaration or function-expression-initialized const, there's basically nothing legitimate you can do with a function that involves assigning to its properties except for creating a function/object hybrid. In that "immediately following" region it's also unlikely you meant to assign to something else. So we're probably looking at some very restricted set of syntax where it's nearly 100% unambiguous what you intended to do.

@RyanCavanaugh
Copy link
Member

Ah look at that

@RyanCavanaugh RyanCavanaugh added Duplicate An existing issue was already created and removed Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. Suggestion An idea for TypeScript labels Mar 11, 2018
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@microsoft microsoft locked and limited conversation to collaborators Jul 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

4 participants