> strong typing could
easily be an option that could be enabled or disabled by a setting (either
through a tag or through the CF Administrator) even in complete isolation to
interfaces .....
I remember Ray asking for this (no doubt
others) way back during the Neo / RedSky betas!
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Gary Menzel
Sent: 03 April 2006 23:40
To: [email protected]
Subject: Re: [CFCDev] Mixins vs.
Interfaces
The answer is simple (and
I have suggested this before)......
...... if you want Interfaces then you have to have strong typing (as Barry
pointed out) .....
..... if you want loose typing then (maybe) you dont have interfaces ......
..... strong typing could easily be an option that could be enabled or disabled
by a setting (either through a tag or through the CF Administrator) even in
complete isolation to interfaces .....
.... There is no reason why CF cant have both and no reason to build them in
such a way as to mandate their use .....
CF has Components - but no-one is forced to use them.
CF has Functions - but no-one is forced to use them.
CF has the <CFMODULE> tag - no no-one is forced to use it.
So.... CF could easily have the options of Strong Typing and Interfaces without
forcing people to use them. Then it is up to each development team to
enforce their own standards in how the product is used and what items are
subject to code review. Best of both worlds.
Coldfusion allows people to write total rubbish code (we've all seen it - and
probably all done it).
Coldfusion should also allow people to write tight well-defined code to strict
standards.
So - let's hope Adobe will add in the features that make the language a rich
object-oriented platform while retaining the rustic charm of the "knock
up" facilities that are really useful for quick results.
Regards,
Gary
On 4/4/06, Barry
Beattie <[EMAIL PROTECTED]>
wrote:
one of the stumbling
blocks (it seems) in doing interfaces properly in
ColdFusion is strong typing.
I'm on an ASP.NET project at the moment and I'm
dumbfounded how
they've screwed up (V 1.1): valueTypes cannot be NULL. (so what's the
uninitialised value of a DateTime or integer to pass as an argument?
I'd say NULL, not 1/1/0001 and 0.... and in CF as empty string)
to even think about strong typing in CF implies the introduction of
NULL. After all the bloated carry-on I'm experiancing compared to
ColdFusion, I'd resist any thought of CF going down this (strong
typing) path.
my 2c
barry.b
On 4/4/06, Peter Bell <
[EMAIL PROTECTED]> wrote:
> Right. As Haikal points out, the value of interfaces (and strong typing
for
> that matter) is that it forces programmers to write more completely
> self-describing code. If you HAVE to specify an interface, it is easier
for
> other programmers to understand what methods a class can implement.
>
> Mixins are fine for individual or small team development. To scale, you
need
> to find a way of documenting the mixins in a way that everyone in your
team
> will agree on. I've still never had a chance to play with ColdSpring, but
> I'd guess you could either use a format similar to its XML to describe
where
> to weave the mixins in (using the AOP functionality) and then whether you
> chose to write your own weaver, use ColdSpring's or make the XML "for
> reference only" would be a personal choice.
>
> If I was doing this, I'd use the XML to generate "final classes"
based on
> the coded classes and mixins. In my experience, if code won't break if
your
> documentation is out of date, your documentation will become out of date,
so
> I typically make documentation functional so the code won't be generated
> correctly without it, thus giving all of the documentation benefits of
> interfaces in a language that doesn't happen to implement them natively.
>
> Come to think of it, using some simple conventions, it would probably be
> fairly straightforward to create an "interfaces" directory where
you could
> code interfaces using a psuedo-Java like syntax and use that to generate
the
> appropriate class files by mixing in the appropriate additional classes
> (which would be stored seperately in a mixins directory with one class per
> file, with file names based on the class names) either at generation time
or
> (with a little more thought) at runtime. Think cfincludes (as per regular
> mixins) but with sub-include logic based on a parsing of the
"interface"
> code. Of course, XML would be a little easier to parse . . .
>
> Best Wishes,
> Peter
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf
> Of Hal Helms
> Sent: Monday, April 03, 2006 12:05 PM
> To: [email protected]
> Subject: RE: [CFCDev] Mixins vs. Interfaces
>
>
> I'm afraid this is one of those subjects that tends to bring out the
> religious tendencies of developers. Some people love mixins; some love
> interfaces. Personally, I think they're both great; they just have
different
> uses.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
> Of Haikal Saadh
> Sent: Monday, April 03, 2006 2:30 AM
> To: [email protected]
> Subject: [CFCDev] Mixins vs. Interfaces
>
>
> I'm surprised that Vince Bonfanti's blog post on interfaces vs. mixins
> (
http://blog.newatlanta.com/index.cfm?mode=entry&entry=F17880FB-12E2-D573-B8
> 81AA26B14EBCC5)
> hasn't gotten much of a reaction? Compared to an older post on Sean
> Corfield's blog
> (
http://www.corfield.org/blog/index.cfm/do/blog.entry/entry/Interfaces_in_Co
> ldFusion)?
> Is this because we're all sick of the debate?
>
> One thing that's nagging me about Mixins is, that when working on a
complex
> application with a good sized team, it becomes hard to determine why (or
> even when :( ) an object possesses certain operatons.
>
> I mean, in Java, if you have:
> public class Duck implements Fryable, Throwable, Serializable{} It's
evident
> that someone needs to fry a duck, have a ballistic duck, and a transmit a
> duck down a wire (Whether it's over IP or sneakernet or whether it's flies
> is largely irrelevant at this point, but you can count on it to be
> transmitted when the need comes).
>
> Whereas with mixins, at some stages you have a comatose duck, a fryable
> duck, and a flameproof duck, an unliftable duck, and duck that's too fat
to
> fit into a wire.
>
> Maybe it's because I know java, and have not much to do with Ruby apart
from
> a RoR Hello World, but I have a feeling that I'm missing a point?
>
> And what about the mention that the next release of BD will have CFC
> interface support? And the rumours at WebDU that CF8 will have interfaces
as
> well?
>
>
> --
> Haikal Saadh, Applications Programmer
> Teaching and Learning Support Services
> K405, Queensland University of Technology,
Kelvin Grove Campus
> [EMAIL PROTECTED], 3864 8633
CRICOS No. 00213J
>
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words
'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org)
and supported by CFXHosting
> (www.cfxhosting.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words
'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org
) and supported by CFXHosting
> (www.cfxhosting.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words
'unsubscribe cfcdev' as the subject of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org)
and supported by CFXHosting ( www.cfxhosting.com).
>
> An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
>
>
>
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words
'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org)
and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
This e-mail is from Reed Exhibitions (Oriel House, 26 The Quadrant, Richmond, Surrey, TW9 1DL, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions. Visit our website at http://www.reedexpo.com
|
