add note about untyped/Dynamic

This commit is contained in:
Justin Donaldson 2013-08-21 22:29:31 -07:00
parent 92a6c91644
commit 580f1a4fe0

View File

@ -387,6 +387,7 @@ class LearnHaxe3{
////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////
// Converting Value Types // Converting Value Types
////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////
trace("***CONVERTING VALUE TYPES***");
// You can convert strings to ints fairly easily. // You can convert strings to ints fairly easily.
@ -402,7 +403,51 @@ class LearnHaxe3{
// See documentation for parsing in Std for more details. // See documentation for parsing in Std for more details.
//////////////////////////////////////////////////////////////////
// Dealing with Types
//////////////////////////////////////////////////////////////////
/*
As mentioned before, Haxe is a statically typed language. All in
all, static typing is a wonderful thing. It enables
autocompletions, and can be used to check the correctness of a
program in very thorough ways. Plus, the Haxe compiler is super fast.
You probably won't be waiting on it very much.
*HOWEVER*, there are times when you just wish the compiler would let
something slide, and not throw a type error in a limited case.
To do this, Haxe has two separate keywords. The first is the
"Dynamic" type:
*/
var dyn: Dynamic = "any type of variable, such as this string";
/*
All that you know for certain with a Dynamic variable is that the
compiler will no longer worry about what type it is. It is like a
wildcard variable: You can pass it instead of any variable type,
and you can assign any variable type you want.
The other more extreme option is the "untyped" keyword
*/
untyped {
var x:Int = 'foo';
var y:String = 4;
}
/*
The untyped keyword operates on entire *blocks* of code, skipping
any type checks that might be otherwise required. This keyword should
be used very sparingly, such as in limited conditionally-compiled
situations where type checking is a hinderance.
In general, skipping type checks is *not* recommended. Use the
enum, inheritance, or structural type models in order to verify the
correctness of your program. Only when you're certain that none of
the type models work should you resort to "Dynamic" or "untyped".
*/
////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////
// Basic Object Oriented Programming // Basic Object Oriented Programming