Message-ID: <303144791.19333.1416949497327.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_19332_1984079801.1416949497326" ------=_Part_19332_1984079801.1416949497326 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Boo is a statically typed language, like Java or C#. This means your boo= applications will run about as fast as those coded in other statically typ= ed languages for .NET or Mono. But using a statically typed language someti= mes constrains you to an inflexible and verbose coding style, with the some= times necessary type declarations (like "x as int", but this is n= ot often necessary due to boo's Typ= e Inference) and sometimes necessary type casts (see Casting Types). Boo's support for Type Inference and eventually generics help her= e, but...
Sometimes it is appropriate to give up the safety net provided by static= typing. Maybe you just want to explore an API without worrying too much ab= out method signatures or maybe you're creating code that talks to external = components such as COM objects. Either way the choice should be yours not m= ine.
Along with the normal types like object, int, string...boo has a special= type called "duck". The term is inspired by the ruby programming= language's duck typing feature ("If it walks like a duck and quacks l= ike a duck, it must be a duck").
If you declare an object as type duck or cast to type duck (or turn on t= he implicit duck typing option, see below), then boo will not try to resolv= e any methods or operations you call on that object at compile time. Instea= d it will convert those operations into methods that do not resolve until r= untime. So at compile time it simply trusts that you know what you are doin= g ("it walks like a duck so it must be a duck"). This is easier t= o understand by looking at some examples.
This code illustrates some things you can do with duck types that you ca= n't with static types (unless you add in casting, see Casting Types).
If it helps, whenever you see "duck", think "any" or= "anything". That object can be anything, and I can do w= hatever to it since it is duck typed and not static typed.
See also how the example would look without duck typing.
You can replace "ie as duck" in the internet explorer example = with "ie" and still have it run if you turn on the implicit duck = typing option. See also the examples in the tests/testcases/ducky/ folder.
You can set this option in various ways depending on which tool you are = using:
What this option does is basically make anything that is of type "o= bject" be of type "duck" instead.
Turning on the ducky option allows you to more quickly test out code, an= d makes coding in boo feel much more like coding in Python. However, it slo= ws down the speed of your application due to not using static typing. So wh= en you are done testing, you may wish to turn the ducky option back off and= add in various type declarations and casts. See Casting Types.
Regular Type Inference is st= ill in effect even when the ducky option is turned on, so if you declare &q= uot;x =3D 4", then x is still an int. This allows your code to still b= e convertible to run without the ducky option by adding in the appropriate = type declarations and casts.
The -ducky option now automatically treats any class that implements the= IQuackFu interface as a duck type too.
Your compiled assembly will still be CLS compliant (usable from other la= nguages) if you use duck types. "Duck" is only a virtual type dur= ing the compile process. Duck types are converted into regular, CLS-complia= nt "object" types in the assembly. Again, see what the IE example= looks like without duck typin= g to get an idea of how the compiler converts your code. Also, IQuackFu= is a regular interface. Not special at all except to the boo compiler.