Mike Kelp wrote on 01/11/06 11:33 AM

I personally don't see why it is such a big deal that interface aren't implemented in CF now.

I want them badly and there are many reasons why. For one thing, interfaces are very useful in API code that you expect other developers to use. When writing something for any one to use, "kick everyone's rear into following the contract" is not an option is it?

Interfaces offer us the ability to not only define some needs for an object but validate it so that a developer writing an object based off of our interface knows where the problem is when his object does not work.

I want clean heirarchies of objects that can describe themselves. I don't want my developers to have to remember how all my "pseudo interfaces" work. Interfaces could help see if in a lot of places, especially when included in all the documentation generators.

Interfaces allow us to be more flexible because one object can implement ten interfaces if it fits the bill and be very flexible. Did we forget the OO rule of programming to an interface, not implementation. Changes also come much easier, because a change can be made to an interface and any objects that depend on the interface can be found easily.

Wanting interfaces in not about asking CF to be Java. (By the way, while the language itself isn't java, it does compile into java, so the compiler/run-time benefits of interfaces are even more evident there) It is asking for a standard OO tool that could greatly benefit development in CF and usability of code written in CF if used correctly.

While I want Macromedia to implement "cool new features" as you said, I am a developer first and a "check out the cool new feature" guy second. I need to trust that I can build reliable, manageable code before I need "Cool Feature A". "Kick everyone's rear into following the contract" when a great tool that could solve the problem could be added to CF, is not an acceptable solution to me. I prefer to kick everyone's rear as little as possible and let them work effectively.

Sorry for the long post.

Dave Ross wrote on 01/11/06 12:16 PM

well said Mike!

Null wrote on 01/11/06 12:31 PM

"Sean *Corn*field has seems to be on the 'don't need them' side of the fence nowadays and has sparked a lot of comments"

Yeah.. that would be too complicated and we may wind up with a language that resembles C# and is able to actually compete in the marketplace. Sean's attitude regarding making CF more like a 'real programming langauge' only maintains the status quo and allows critics to continue to claim that CF is 'dumbed down Java'. Macromedia took a robust language (Java) and dumbed it down so it as is as limited as it's already lagging market share.

We should have a better product than .NET because we have to pay an arm and leg for it! I find Macromedia's approach to keeping ColdFusion limited and bypassing cfscript enhancements in favor of tag enjancements completely insulting and has caused many shops to completely abandon ColdFusion altogether. It will eventually be CFs downfall unless Adobe recognizes this and radically changes their approach.

Nick wrote on 01/11/06 1:47 PM

I agree with the original post. I really think interfaces end up becoming a burden, and a problem when cross-referencing material.

I think not having an interface forces you to learn all aspects of a language, rather than just the basics. You are a much more efficient coder when you can mentally reference required functionality, in my opinion.

Chris Scott wrote on 01/11/06 1:58 PM

Mike, very elequent. I pretty much totally agree, and am happy that the pro interface camp is now up to 3!

Null what the hell are you talking about. Go work in .Net than. Use whatever tool you feel most comfortable and efficent in and that's the end of it. You're paying a small price for the many many services that cf makes increadibly easy. The language is tag based who cares, why are you bitching about cfscript and saying the tag language is limiting or dumbed down java? You could not be any more wrong! The power of the language is being shown by the tremendous development happining right now with ORM tools, MVC frameworks, ColdSpring, and by the way, what do you think writing an AOP framework is trivial? Give me a break! Go to he... Ah forget it!

Scott Stroz wrote on 01/11/06 2:56 PM

'I find Macromedia's approach to keeping ColdFusion limited and bypassing cfscript enhancements in favor of tag enjancements completely insulting and has caused many shops to completely abandon ColdFusion altogether.'

If you are insulted by the fact that Adobe or Macromedia has bypassed enhancements to cfscript, maybe you need to get out a bit more often.

Can you name one "shop" that has abandonned CF because of the same reason?

And could you elaborate more on how they are keeping ColdFusion 'limited'?

Scott Stroz wrote on 01/11/06 2:58 PM

Oops...I almost forgot...

Bravo, Mike!

Steve Bryant wrote on 01/11/06 3:21 PM

I am relatively certain that we don't *need* interfaces.

I still think that I would *like* interfaces. If for nothing else, then to get a better error.

I would rather get an error when I first run the component telling me that it doesn't match the interface than get one later when I try to use it that forces me to determine that problem on my own.

That being said, perhaps I just haven't seen the light to a an approach that better fits the ColdFusion universe.

Barneyb wrote on 01/11/06 4:36 PM

The reason for interfaces has nothing to do with method checking and the like, and everything to do with typing. In other words, I can say my Dog CFC extends Animal and implements Pet, and then instance of it can be passed as either Animals or Pets. Very powerful, but impossible with CFCs currently, unless Pet extends Animal.

That's why interfaces would rule.

And as a further argument against all the "method error" complaints, it's impossible anyway, since an interface check is a compile-time thing, and since CFCs can have methods dynamically added and removed, any sort of compile time check would be worthless (not to mention cumbersome to implement in a logical manner - CF has dynamic recompilation, remember). How's that for a run-on sentance. It's not like the error CF generates doesn't already tell you what method is missing.

Bruce wrote on 01/11/06 6:02 PM

Joe:

Reference your statement about not needing a null type in CF. The example you cite is not one that should generate an exception. Not having a spouse is a normal (preferable) occurence, it is not "exceptional."

Exceptions are for handling "exceptional" events that should not be handled by my usual code/logic. If the potential is that someone will not have a spouse then my code should account for it; especially if this potential is quite common/likely to occur.

A way to handle your example is for my CFC to have a method person.hasSpouse() that returns true or false so you easily could do

if ( person.hasSpouse() )
person.getSpouse();
else
"Your a lucky man.";

That said I am for the null type since it is used in database columns and in Java (and I use Java classes in my CF apps).


Bruce

Scott Barnes wrote on 01/11/06 6:31 PM

I'm for interfaces, for the same reasons as most have stated here and elsewhere.

I dislike inheritance chains that exist simply for the sake of allowing certain "types" to be pushed around the model. Abiding by a "virtual" contract is cumbersome at best, especially if you have a fragmeneted team accessing the code base. Some organisations don't have a 1:1 coding environment, so one day teamA can decide that in order adhere to the framework of choice, they must abide by certain rules.

Yet, time passes, and teamB takes the realm and unless their is someone mindful of the fact that these rules existed, the overall intention is disolved.

Interfaces also enforce a contract as well, so in a sense i really don't see the overal position on "why they shouldn't exist".

The problem i keep seeing in this types of arguments is that we the Coldfusion community keep pushing ourselves to adopt strong OO approaches to our coding environment (ie frameworks for one). We preach to one another about best practicies centered around our adoptions that are typically derived from languages like Java - yet - the moment someone asks for a bit more power to make it "Easier" to adopt such principals, the folks that do preach suddenly pull out the "well it isn't java" or "its a simple language, if you want that, go learn java"...

My overall position these days with coldfusion is that it will not hurt the language in any way shape or form, if enhancements such as NULL or INTERFACES (even method overloading) as in the end, the language is built in such a way you DON'T *HAVE* to use them should you find them to difficult.

I think assuming coldfusion is meant to be this "OO for Dummies" language is not very fair as i personally regard the language still as a server-side buffer between complex much more powerful languages or databases. If we have more enhancments added to its war chest that make the transition from a web-based delivery channel to a server-side solution (whether it stops at CF or continues down the pipe into Java) then all the more power to it.

Method overloading I could do with out, Interfaces i could do with, and properites being allowed to have NULL values on construct, to me makes sense?

Mike Kelp wrote on 01/11/06 7:28 PM

Wow, this has really turned into an interesting conversation.

For one, I don't know why the merits of CF as a language have come into this. Anyone who doubts what the language is capable of is doesn't know the language well enough and doesn't realize that companies like Bank Of America don't generally invest in tools that aren't very capable these days. I don't like .Net personally, but that doesn't mean I think that you can't do everything I do in CF in that or even the other way around. A language's syntax should be in line with it's purpose. The shift from scripting like syntaxes to XML is very common nowadays for GUI implementations and web applications no matter what platform you use. Fact is, it fits the environment better. CF allows scripting in my opinion because it is often a preferred format for "processing" code. That's my guess at least.

By the way, this might start another conversational wildfire, but I am also for optional strong typing in ColdFusion. While I wouldn't use it everywhere, it is nice for quite a few things and would probably make the "remember to javaCast() everything" situation better when working with java objects. Also large amounts of processing code could be made more fast and efficient if the server is doing a lot of work in a particular application or a dynamic page has a high request rate. Just some things that would boost performance and maybe even shut some critics up. I think this feature is implemented very well in ActionScript and shows just how useful it can be.

Glad to see I'm not alone,
Mike.

Cliff Meyers wrote on 01/11/06 8:04 PM

Add me to the pro-interface camp :) Pretty much every modern OO language has some approach allowing for a class to live in more than one hierarchy. Here is a nice chart that indicates the strategies used in a bunch of languages:

http://www.jvoegele.com/software/langcomp.html

This isn't about making CF "more like Java"... it's about adding a feature that basically every modern programming language has in one form or another. It's also important to realize that nulls, static typing and interfaces are three separate issues. Just because Java has them all doesn't mean that the arguments for/against each are the same...

Nulls: would require significant reworking to the CF internals (at least, I believe Sean's said as much on the mailing lists) and would likely cause all kinds of issues distinguishing between empty strings. I agree that throwing exceptions is the way to go and CF supports this nicely.

Strong typing: would likely cause all kinds of backwards compatibility issues and ultimately force developers to use of strong typing which would be probably be painful for a lot of people. Note: I don't think CF could ever be statically typed since we've been able to concatenate numbers and strings together for eons with any kind of implicit casting. A lot of people throw around static and strong typing but they're actually two different things. Good discussion of strong, weak, static and dynamic typing at the bottom of this page:
http://www.ferg.org/projects/python_java_side-by-side.html

Interfaces: would likely cause minimal disruption to the CF engine. There shouldn't be any backwards compatibility issues if designed correctly. And If a developer doesn't like interfaces in CF then you don't need to use them :)

(1) Add an "implements" attribute to the CFCOMPONENT tag which is a comma-delimited list of the implented interface names

(2) Add a "type" attribute to CFCOMPONENT that accepts either "component" or "interface" and defaults to "component" if omitted

(3) Add as many CFFUNCTION tags as you like to a CFCOMONENT type="interface" CFC and optionally specify argument types or return types, just as the developer has the flexibility to specify or not specify argument types/returntypes now. This isn't overloading (wouldn't be feasible in a weak-dynamic typed language such as CF) just the option of making the interface more strongly defined but still leaving the developer the option to keep it more flexible if they so wish.

This seems like it wouldn't be too terribly difficult for the CF team to implement so the value that it'd give to developers should hopefully be proportional to the level of effort for implementing it. The inability to do multiple inheritance is a fairly substantial missing feature and it'd be really nice to see Adobe bang this out.

I don't give a hoot about nulls and strong typing ;)