interesting.
I'm looking around for a language/runtime that can happily switch
between strong- and weak-typing to check out how they'd do it -
Perhaps a 4GL built on top of C - and can't find any
it'd be pretty ground breaking stuff....("ahem, very 'couragous', minister")
On 4/4/06, Gary Menzel <[EMAIL PROTECTED]> wrote:
> 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]
----------------------------------------------------------
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]
