Cfinterface returntype limitation

> why would you want to define a constructor
> for an interface?

Because one might want to ensure the class provides a constructor taking a
specific combination of arguments.

In the context of CF, there is no concept of constructors, so init() is
just a method. CF has no way of knowing there's a notional agreement in
the community that init() methods are generally used in lieu of a
constructor.

--
Adam

> It seems that the returntype validation in cfinterface and implementing classes
> is a bit too limiting....I can't see how a CFC function could ever return an
> instance of itself.

This works OK for me.

<!--- IFoo.cfc --->
<cfinterface>
<cffunction name="getSelf" returntype="IFoo">
</cffunction>
</cfinterface>

<!--- Foo.cfc --->
<cfcomponent implements="shared.cf.cfml.I.interface.IFoo">
<cffunction name="getSelf" returntype="IFoo">
<cfreturn this>
</cffunction>
</cfcomponent>

<!--- foo.cfm --->
<cfset o = createObject("component", "Foo").getSelf()>
<cfdump var="#o#">


> Is there something I'm missing?

I think you're missing the part that if you're having some problems with
your code, it's always a good idea to post some code that demonstrates the
problem. Other than that: it's hard to tell.

--
Adam

Ignoring the question for a moment, why would you want to define a constructor for an interface? Using the java model, interfaces generally define a contract for methods of a class (ie functions of a component), and not constructors. Interfaces are not meant to be instantiated. Though technically the init() function straddles both worlds, it is really more of a constructor than a method/function.