2

Closed

change class to interface

description

I think I'm proposing a very difficult, and radical change to the type definitions. But I'm reading the various definitions available at github.com/borisyankov/DefinitelyTyped

And it seems in most cases, interfaces are used to define the definitions, rather than solid classes.

The biggest benefit I can see for this is that TypeScript Interfaces are open, so you can't easily do this with classes:
module SP {
   class ClientContext {
        // methods
   }
}

module SP {
   class ClientContext {
         // more methods - e.g. the ones from SP2013
         // because ClientContext is now a duplicate reference.
   }
}
If this was done as:
module SP {
    interface IClientContext {
        // methods;
    }
    ClientContext: SP.IClientContext;
}
then later you can have another file that adds more members to IClientContext
module SP {
   interface IClientContext {
        // do more stuff
   }
}
This approach will really help you not end up with a monolithic giant SharePoint.d.ts file, rather we'd have it separated into different definitions, e.g.

knockout.d.ts
knockout.mapping.d.ts
knockout.validation.d.ts

both mapping and validation adds to the KnockoutStatic object's interface. and all three can co-exist happily, or knockout.d.ts can live without the other two.
Closed Jun 15, 2014 at 6:31 PM by gandjustas

comments

johnnliu wrote Jul 30, 2013 at 8:14 AM

I have a lot of personal interest down this path, since I do a lot of TypeScript with SP2010, so I'm keen to take the SP2013 definitions and remove a lot of the symbols that aren't in the SP2010 version.

omlin wrote Aug 1, 2013 at 11:52 AM

Hi John,

We already have separation of definitions (please have a look at Definitions folder under Source Code tab), but we prefer to deliver them all as one file because anyway since these are only definitions, they don't really add anything to your project. They only serve for intellisense. So imo it is very convenient to have them all as one file which you just thrust into your project and you're done.

Your proposal makes sense from the perspective of maintaining definitions for different versions of SharePoint, but why not to have just another copy of the definitions? Creating interfaces for every class is a damn much of a monkey job, and anyway it doesn't solve the problem: you still need classes, because you cannot do e.g. "var context = new SP.ClientContext(url)" without having a class. You cannot replace classes with interfaces because they are different things, even in JS.

So in this case, personally I would just create a copy of definitions and strip them from SP2013 stuff, and publish them. Done.

gandjustas wrote Aug 2, 2013 at 4:54 PM

Hi John,
You can use https://sptypescript.codeplex.com/SourceControl/latest#Definitions/SP.Init.d.ts and https://sptypescript.codeplex.com/SourceControl/latest#Definitions/SP.d.ts definitions separately. This definitions almost same for SharePoint 2010.

Can you provide some real cases and samples for separating interfaces?