No way to prototype constructor via interface?

Topics: Language Specification
Apr 18, 2013 at 5:56 PM
Edited Apr 18, 2013 at 6:01 PM
I don't get what's wrong here:
interface IFB2DOM {
    constructor(URL:string);
}

class FB2DOM implements IFB2DOM{
    constructor (URL:string){
        return this;
    }
}
Is it possible to define constructor in interface?
Apr 18, 2013 at 7:06 PM

Just in general design terms, it's bad form to tell an interface implementation how it should be constructed.

Apr 18, 2013 at 7:35 PM
Not THAT bad. I am going to have several heavily-linked classes and replace any of them with alternatives transparently for others by substituting js-file. Think of it as of plugins. And I want interfaces to hold the "agreement". That's what interfaces are for (opposing to indirect class inheritance) - they define whatever agreement on the class behavior I need to have and help my code to follow it. What harm can such a restriction ever produce?

Ps. And after all it's my leg and I want to shot it :)
Apr 18, 2013 at 8:23 PM

You can't new up an interface, though, so what does it benefit you to have a constructor on it? If you need a uniform function signature for creating instances of a type, that's what factories are for.

As for shooting yourself in the foot, you might be fine with it, but that doesn't mean everybody else should be given Desert Eagles. ;-)

From: GribUser

Not THAT bad. I am going to have several heavily-linked classes and replace any of them with alternatives transparently for others by substituting js-file. Think of it as of plugins. And I want interfaces to hold the "agreement". That's what interfaces are for (opposing to indirect class inheritance) - they define whatever agreement on the class behavior I need to have and help my code to follow it. What harm can such a restriction ever produce?

Ps. And after all it's my leg and I want to shot it :)

Read the full discussion online.

To add a post to this discussion, reply to this email ([email removed])

To start a new discussion for this project, email [email removed]

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Apr 18, 2013 at 9:39 PM
Edited Apr 18, 2013 at 10:08 PM
markrendle wrote:
You can't new up an interface, though, so what does it benefit you to have a constructor on it? If you need a uniform function signature for creating instances of a type, that's what factories are for
Yeah, that's what factories are for and that's how you make them - you define a virtual constructor. In the terms of TypeScript this is what the "interface" is about, at least it's the closest analogue I can find for "virtual constructor". If I can have two twin-classes and load them with <script src="opera.js"/> versus <script src="ie.js"/> or <script src="desktop.js"/> versus <script src="iphone.js"/> on the fly (common approach), why would I go for some more dedicated "class factory"? If the code above would work it would make a simple, fast and robust enough class factory.

I believe such a thing like TypeScript should allow some shortcuts (like NOT requiring every variable to have the type, "in general design terms" it sounds not so good to). TypeScript code will in 99% cases come together on-the-fly and this fact could, should and will be used by developers. Why deny them to rely on the browser to do the class factory job, in our case? We only need a tool to make this class factory more reliable by delegating code consistency tracking to the "compiler".

ps. Surely I will workaround this issue by removing constructor from interface and manualy keeping track of all twin-classes to have similar constructors. It's just when I started to do so I felt a bit strange. I thought I miss something and come here.
Apr 19, 2013 at 12:20 AM

So, if you're switching JS files which have "twin" class with the same name and constructor, what you should be using in your TypeScript is a definition file to declare the class, not an interface.

I'd supply a code sample but I'm in my phone and Swype keeps crashing, sorry. Google "DefinitelyTyped" to find a GitHub repo with dozens of definition files that declare classes.

Apr 19, 2013 at 12:21 AM

On my phone, not in it. I'm not having a Tron moment or anything.

Apr 19, 2013 at 7:40 AM
Edited Apr 19, 2013 at 7:48 AM
markrendle wrote:
So, if you're switching JS files which have "twin" class with the same name and constructor, what you should be using in your TypeScript is a definition file to declare the class, not an interface.
I still do not see how would it prevent me from overriding base constructor with incompatible one. My plan was to make and share interface definition and have the alarm beeping the very moment I make a class with a bad constructor.
Apr 19, 2013 at 1:07 PM
Ah, whatever. This is like banging my head against a wall, except without the endorphins.
Apr 19, 2013 at 1:48 PM
As for me it's just a bug. Interface must either directly prohibit declaring constructor (stupid, but at least consistent) or threat constructor as a constructor so it would affect implementation. Now it blames an implementation for error in interface which makes no sense.
I'll fire a ticket.
Jan 4, 2015 at 11:48 PM
I absolutely agree with GribUser. I'm coming from compiled and mature OOP languages world and to me it's absolutely a must for a language to be able to define anything I need in the interface as a contract for the rest of my code. In that case compiler will warn me or other guy he forgot to implement it. It's strange we need to argue on such an obvious thing.