Dart Programming language Tutorial

how to learn dart programming and dart programming language vs javascript and google dart web programming language and special features
OliviaCutts Profile Pic
OliviaCutts,France,Teacher
Published Date:01-08-2017
Your Website URL(Optional)
Comment
ECMA-408 th 4 Edition / December 2015 Dart Programming Language Specification Reference number ECMA-123:2009 © Ecma International 2009 COPYRIGHT PROTECTED DOCUMENT © Ecma International 2015 This Ecma Standard has been adopted by the General Assembly of December 2015. "COPYRIGHT NOTICE © 2015 Ecma International This document may be copied, published and distributed to others, and certain derivative works of it may be prepared, copied, published, and distributed, in whole or in part, provided that the above copyright notice and this Copyright License and Disclaimer are included on all such copies and derivative works. The only derivative works that are permissible under this Copyright License and Disclaimer are: (i) works which incorporate all or portion of this document for the purpose of providing commentary or explanation (such as an annotated version of the document), (ii) works which incorporate all or portion of this document for the purpose of incorporating features that provide accessibility, (iii) translations of this document into languages other than English and into different formats and (iv) works by making use of this specification in standard conformant products by implementing (e.g. by copy and paste wholly or partly) the functionality therein. However, the content of this document itself may not be modified in any way, including by removing the copyright notice or references to Ecma International, except as required to translate it into languages other than English or into a different format. The official version of an Ecma International document is the English language version on the Ecma International website. In the event of discrepancies between a translated version and the official version, the official version shall govern. The limited permissions granted above are perpetual and will not be revoked by Ecma International or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and ECMA INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." © Ecma International 2015 iii iv © Ecma International 201 5 Dart Programming Language Specification (4th edition draft) Version 1.11 August 19, 2015 Contents 1 Scope 6 2 Conformance 6 3 Normative References 6 4 Terms and Definitions 6 5 Notation 6 6 Overview 8 6.1 Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7 Errors and Warnings 11 8 Variables 12 8.1 Evaluation of Implicit Variable Getters . . . . . . . . . . . . . . . 16 9 Functions 16 9.1 Function Declarations . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2 Formal Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2.1 Required Formals . . . . . . . . . . . . . . . . . . . . . . . 20 9.2.2 Optional Formals . . . . . . . . . . . . . . . . . . . . . . . 20 9.3 Type of a Function . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.4 External Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 22 110 Classes 22 10.1 Instance Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1.1 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.2 Getters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.3 Setters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.4 Abstract Instance Members . . . . . . . . . . . . . . . . . . . . . 27 10.5 Instance Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.6 Constructors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.6.1 Generative Constructors . . . . . . . . . . . . . . . . . . . 29 10.6.2 Factories . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.6.3 Constant Constructors . . . . . . . . . . . . . . . . . . . . 34 10.7 Static Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.8 Static Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.9 Superclasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.9.1 Inheritance and Overriding . . . . . . . . . . . . . . . . . 37 10.10 Superinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 11 Interfaces 41 11.1 Superinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 11.1.1 Inheritance and Overriding . . . . . . . . . . . . . . . . . 41 12 Mixins 43 12.1 Mixin Application . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12.2 Mixin Composition . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13 Enums 45 14 Generics 45 15 Metadata 46 16 Expressions 47 16.0.1 Object Identity . . . . . . . . . . . . . . . . . . . . . . . . 48 16.1 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 16.2 Null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 16.3 Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 16.4 Booleans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 16.4.1 Boolean Conversion . . . . . . . . . . . . . . . . . . . . . 54 16.5 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 16.5.1 String Interpolation . . . . . . . . . . . . . . . . . . . . . 58 16.6 Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 16.7 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 16.8 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 16.9 Throw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 16.10 Function Expressions . . . . . . . . . . . . . . . . . . . . . . . . 63 16.11 This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 16.12 Instance Creation . . . . . . . . . . . . . . . . . . . . . . . . . . 65 216.12.1 New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 16.12.2 Const . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 16.13 Spawning an Isolate . . . . . . . . . . . . . . . . . . . . . . . . . 69 16.14 Function Invocation . . . . . . . . . . . . . . . . . . . . . . . . . 69 16.14.1 Actual Argument List Evaluation . . . . . . . . . . . . . 71 16.14.2 Binding Actuals to Formals . . . . . . . . . . . . . . . . . 71 16.14.3 Unqualified Invocation . . . . . . . . . . . . . . . . . . . 72 16.14.4 Function Expression Invocation . . . . . . . . . . . . . . 73 16.15 Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 16.15.1 Method Lookup . . . . . . . . . . . . . . . . . . . . . . . 73 16.15.2 Getter and Setter Lookup . . . . . . . . . . . . . . . . . 74 16.16 Top level Getter Invocation . . . . . . . . . . . . . . . . . . . . . 74 16.17 Method Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . 74 16.17.1 Ordinary Invocation . . . . . . . . . . . . . . . . . . . . . 74 16.17.2 Cascaded Invocations . . . . . . . . . . . . . . . . . . . . 76 16.17.3 Super Invocation . . . . . . . . . . . . . . . . . . . . . . . 77 16.17.4 Sending Messages . . . . . . . . . . . . . . . . . . . . . . . 78 16.18 Property Extraction . . . . . . . . . . . . . . . . . . . . . . . . . 79 16.18.1 Getter Access and Method Extraction . . . . . . . . . . . 79 16.18.2 Super Getter Access and Method Closurization . . . . . . 81 16.18.3 General Closurization . . . . . . . . . . . . . . . . . . . . 82 16.18.4 Named Constructor Extraction . . . . . . . . . . . . . . . 83 16.18.5 Anonymous Constructor Extraction . . . . . . . . . . . . 83 16.18.6 General Super Property Extraction . . . . . . . . . . . . . 84 16.18.7 Ordinary Member Closurization . . . . . . . . . . . . . . 84 16.18.8 Named Constructor Closurization . . . . . . . . . . . . . . 85 16.18.9 Anonymous Constructor Closurization . . . . . . . . . . . 86 16.18.10 Super Closurization . . . . . . . . . . . . . . . . . . . . . 86 16.19 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 16.19.1 Compound Assignment . . . . . . . . . . . . . . . . . . . 90 16.20 Conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 16.21If-null Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 92 16.22 Logical Boolean Expressions . . . . . . . . . . . . . . . . . . . . 92 16.23 Equality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 16.24 Relational Expressions . . . . . . . . . . . . . . . . . . . . . . . 94 16.25 Bitwise Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 95 16.26 Shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 16.27 Additive Expressions . . . . . . . . . . . . . . . . . . . . . . . . 96 16.28 Multiplicative Expressions . . . . . . . . . . . . . . . . . . . . . 97 16.29 Unary Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 98 16.30 Await Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 99 16.31 Postfix Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 99 16.32 Assignable Expressions . . . . . . . . . . . . . . . . . . . . . . . 101 16.33 Identifier Reference . . . . . . . . . . . . . . . . . . . . . . . . . 102 16.34 Type Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 16.35 Type Cast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 317 Statements 106 17.1 Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 17.2 Expression Statements . . . . . . . . . . . . . . . . . . . . . . . . 107 17.3 Local Variable Declaration . . . . . . . . . . . . . . . . . . . . . . 108 17.4 Local Function Declaration . . . . . . . . . . . . . . . . . . . . . 108 17.5 If . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 17.6 For . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 17.6.1 For Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 17.6.2 For-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 17.6.3 Asynchronous For-in . . . . . . . . . . . . . . . . . . . . . 111 17.7 While . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 17.8 Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 17.9 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 17.10 Rethrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 17.11 Try . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 17.12 Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 17.13 Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 17.14 Break . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 17.15 Continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 17.16 Yield and Yield-Each . . . . . . . . . . . . . . . . . . . . . . . . 124 17.16.1 Yield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 17.16.2 Yield-Each . . . . . . . . . . . . . . . . . . . . . . . . . . 125 17.17 Assert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 18 Libraries and Scripts 127 18.1 Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 18.2 Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 18.3 Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 18.4 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 18.5 URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 19 Types 136 19.1 Static Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 19.1.1 Type Promotion . . . . . . . . . . . . . . . . . . . . . . . 138 19.2 Dynamic Type System . . . . . . . . . . . . . . . . . . . . . . . . 138 19.3 Type Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . 139 19.3.1 Typedef . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 19.4 Interface Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 19.5 Function Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 19.6 Type dynamic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 19.7 Type Void . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 19.8 Parameterized Types . . . . . . . . . . . . . . . . . . . . . . . . . 145 19.8.1 Actual Type of Declaration . . . . . . . . . . . . . . . . . 145 19.8.2 Least Upper Bounds . . . . . . . . . . . . . . . . . . . . . 145 420 Reference 146 20.1 Lexical Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 20.1.1 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 147 20.1.2 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 20.2 Operator Precedence . . . . . . . . . . . . . . . . . . . . . . . . . 148 5Dart Programming Language Specification 6 ecmaScope 1 Scope This Ecma standard specifies the syntax and semantics of the Dart program- ming language. It does not specify the APIs of the Dart libraries except where those library elements are essential to the correct functioning of the language itself (e.g., the existence of class Object with methods such as noSuchMethod, runtimeType). ecmaConformance 2 Conformance A conforming implementation of the Dart programming language must provide and support all the APIs (libraries, types, functions, getters, setters, whether top-level, static, instance or local) mandated in this specification. A conforming implementation is permitted to provide additional APIs, but not additional syntax, except for experimental features in support of null-aware cascades and tear-offs that are likely to be introduced in the next revision of this specification. ecmaNormativeReferences 3 Normative References The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. 1. The Unicode Standard, Version 5.0, as amended by Unicode 5.1.0, or successor. 2. Dart API Reference, https://api.dartlang.org/ ecmaTermsAndDefinitions 4 Terms and Definitions Terms and definitions used in this specification are given in the body of the specification proper. Such terms are highlighted in italics when they are introduced, e.g., ‘we use the term verbosity to refer to the property of excess verbiage’. 5 Notation notation We distinguish between normative and non-normative text. Normative text defines the rules of Dart. It is given in this font. At this time, non-normative text includes:Dart Programming Language Specification 7 Rationale Discussion of the motivation for language design decisions appears in ital- ics. Distinguishing normative from non-normative helps clarify what part of the text is binding and what part is merely expository. Commentary Comments such as “The careful reader will have noticed that the name Dart has four characters” serve to illustrate or clarify the specification, but are redundant with the normative text. The difference between commentary and rationale can be subtle. Commentary is more general than rationale, and may include illustrative examples or clarifications. Open questions (in this font). Open questions are points that are unsettled in the mind of the author(s) of the specification; expect them (the questions, not the authors; precision is important in a specification) to be eliminated in the final specification. Should the text at the end of the previous bullet be rationale or commentary? Reserved words and built-in identifiers (16.33) appear in bold. Examples would be switch or class. Grammar productions are given in a common variant of EBNF. The left hand side of a production ends with a colon. On the right hand side, alternation is represented by vertical bars, and sequencing by spacing. As in PEGs, alter- nation gives priority to the left. Optional elements of a production are suffixed by a question mark like so: anElephant?. Appending a star to an element of a production means it may be repeated zero or more times. Appending a plus sign to a production means it occurs one or more times. Parentheses are used for grouping. Negation is represented by prefixing an element of a production with a tilde. Negation is similar to the not combinator of PEGs, but it consumes input if it matches. In the context of a lexical production it consumes a single character if there is one; otherwise, a single token if there is one. An example would be: AProduction: AnAlternative AnotherAlternative OneThing After Another ZeroOrMoreThings OneOrMoreThings+ AnOptionalThing? (Some Grouped Things) ˜NotAThing A LEXICAL THING ; Both syntactic and lexical productions are represented this way. Lexical productions are distinguished by their names. The names of lexical productions consist exclusively of upper case characters and underscores. As always, withinDart Programming Language Specification 8 grammatical productions, whitespace and comments between elements of the production are implicitly ignored unless stated otherwise. Punctuation tokens appear in quotes. Productions are embedded, as much as possible, in the discussion of the constructs they represent. A list x ,...,x denotes any list of n elements of the form x , 1≤ i≤ n. 1 n i Note that n may be zero, in which case the list is empty. We use such lists extensively throughout this specification. The notation x ,...,x /y ,...,y E denotes a copy of E in which all 1 n 1 n occurrences of y , 1≤i≤n have been replaced with x . i i We sometimes abuse list or map literal syntax, writing o ,...,o (respec- 1 n tivelyk : o ,...,k : o ) where the o and k may be objects rather than 1 1 n n i i expressions. The intent is to denote a list (respectively map) object whose elements are the o (respectively, whose keys are the k and values are the o ). i i i The specifications of operators often involve statements such as x op y is equivalent to the method invocation x.op(y). Such specifications should be understood as a shorthand for: 0 • x op y is equivalent to the method invocation x.op (y), assuming the class 0 ofx actually declared a non-operator method namedop defining the same function as the operator op. This circumlocution is required because x.op(y), where op is an operator, is not legal syntax. However, it is painfully verbose, and we prefer to state this rule once here, and use a concise and clear notation across the specification. When the specification refers to the order given in the program, it means the order of the program source code text, scanning left-to-right and top-to-bottom. References to otherwise unspecified names of program entities (such as classes or functions) are interpreted as the names of members of the Dart core library. Examples would be the classes Object and Type representing the root of the class hierarchy and the reification of runtime types respectively. overview 6 Overview Dart is a class-based, single-inheritance, pure object-oriented programming language. Dart is optionally typed (19) and supports reified generics. The run- time type of every object is represented as an instance of class Type which can be obtained by calling the getter runtimeType declared in class Object, the root of the Dart class hierarchy. Dart programs may be statically checked. The static checker will report some violations of the type rules, but such violations do not abort compilation or preclude execution. Dart programs may be executed in one of two modes: production mode or checked mode. In production mode, static type annotations (19.1) haveDart Programming Language Specification 9 absolutely no effect on execution with the exception of reflection and structural type tests. Reflection, by definition, examines the program structure. If we provide reflective access to the type of a declaration, or to source code, it will inevitably produce results that depend on the types used in the underlying code. Type tests also examine the types in a program explicitly. Nevertheless, in most cases, these will not depend on type annotations. The exceptions to this rule are type tests involving function types. Function types are structural, and so depend on the types declared for their parameters and on their return types. In checked mode, assignments are dynamically checked, and certain viola- tions of the type system raise exceptions at run time. The coexistence between optional typing and reification is based on the following: 1. Reified type information reflects the types of objects at runtime and may always be queried by dynamic typechecking constructs (the analogs of in- stanceOf, casts, typecase etc. in other languages). Reified type information includes class declarations, the runtime type (aka class) of an object, and type arguments to constructors. 2. Static type annotations determine the types of variables and function decla- rations (including methods and constructors). 3. Production mode respects optional typing. Static type annotations do not affect runtime behavior. 4. Checked mode utilizes static type annotations and dynamic type information aggressively yet selectively to provide early error detection during development. Dart programs are organized in a modular fashion into units called libraries (18). Libraries are units of encapsulation and may be mutually recursive. However they are not first class. To get multiple copies of a library running simultaneously, one needs to spawn an isolate. scoping 6.1 Scoping A namespace is a mapping of names denoting declarations to actual decla- rations. Let NS be a namespace. We say that a name n is in NS if n is a key of NS. We say a declaration d is in NS if a key of NS maps to d. A scope S induces a namespace NS that maps the simple name of each 0 0 variable, type or function declaration d declared in S to d. Labels are not 0 included in the induced namespace of a scope; instead they have their own dedicated namespace. It is therefore impossible, e.g., to define a class that declares a method and a field with the same name in Dart. Similarly one cannot declare a top-level function with the same name as a library variable or class. It is a compile-time error if there is more than one entity with the same name declared in the same scope.Dart Programming Language Specification 10 In some cases, the name of the declaration differs from the identifier used to declare it. Setters have names that are distinct from the corresponding getters because they always have an = automatically added at the end, and unary minus has the special name unary-. Dart is lexically scoped. Scopes may nest. A name or declaration d is available in scope S if d is in the namespace induced by S or if d is available in the lexically enclosing scope of S. We say that a name or declaration d is in scope if d is available in the current scope. If a declarationd namedn is in the namespace induced by a scopeS, thend hides any declaration named n that is available in the lexically enclosing scope of S. A consequence of these rules is that it is possible to hide a type with a method or variable. Naming conventions usually prevent such abuses. Nevertheless,the following program is legal: class HighlyStrungf String() = ”?”; g Names may be introduced into a scope by declarations within the scope or by other mechanisms such as imports or inheritance. The interaction of lexical scoping and inheritance is a subtle one. Ultimately, the question is whether lexical scoping takes precedence over inheritance or vice versa. Dart chooses the former. Allowing inherited names to take precedence over locally declared names can create unexpected situations as code evolves. Specifically, the behavior of code in a subclass can change without warning if a new name is introduced in a superclass. Consider: library L1; class Sfg library L2; import ‘L1.dart’; foo() = 42; class C extends Sf bar() = foo();g Now assume a method foo() is added to S. library L1; class Sffoo() = 91;g If inheritance took precedence over the lexical scope, the behavior of C would change in an unexpected way. Neither the author of S nor the author of C are necessarily aware of this. In Dart, if there is a lexically visible method foo(), it will always be called. Now consider the opposite scenario. We start with a version of S that con- tains foo(), but do not declare foo() in library L2. Again, there is a change in behavior - but the author of L2 is the one who introduced the discrepancy that effects their code, and the new code is lexically visible. Both these factors make it more likely that the problem will be detected. These considerations become even more important if one introduces con- structs such as nested classes, which might be considered in future versions ofDart Programming Language Specification 11 the language. Good tooling should of course endeavor to inform programmers of such situ- ations (discreetly). For example, an identifier that is both inherited and lexically visible could be highlighted (via underlining or colorization). Better yet, tight in- tegration of source control with language aware tools would detect such changes when they occur. privacy 6.2 Privacy Dart supports two levels of privacy: public and private. A declaration is private iff its name is private, otherwise it is public. A name q is private iff any one of the identifiers that comprise q is private, otherwise it is public. An identifier is private iff it begins with an underscore (the character) otherwise it is public. A declaration m is accessible to library L if m is declared in L or if m is public. This means private declarations may only be accessed within the library in which they are declared. Privacy applies only to declarations within a library, not to library declara- tions themselves. Libraries do not reference each other by name and so the idea of a private library is meaningless. Thus, if the name of a library begins with an underscore, it has no effect on the accessibility of the library or its members. Privacy is, at this point, a static notion tied to a particular piece of code (a library). It is designed to support software engineering concerns rather than security concerns. Untrusted code should always run in an another isolate. It is possible that libraries will become first class objects and privacy will be a dynamic notion tied to a library instance. Privacy is indicated by the name of a declaration - hence privacy and naming are not orthogonal. This has the advantage that both humans and machines can recognize access to private declarations at the point of use without knowledge of the context from which the declaration is derived. concurrency 6.3 Concurrency Dart code is always single threaded. There is no shared-state concurrency in Dart. Concurrency is supported via actor-like entities called isolates. An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (16.17.4). No state is ever shared between isolates. Isolates are created by spawning (16.13). 7 Errors and Warnings errorsAndWarnings This specification distinguishes between several kinds of errors. Compile-time errors are errors that preclude execution. A compile-timeDart Programming Language Specification 12 error must be reported by a Dart compiler before the erroneous code is executed. A Dart implementation has considerable freedom as to when compilation takes place. Modern programming language implementations often interleave compilation and execution, so that compilation of a method may be delayed, e.g., until it is first invoked. Consequently, compile-time errors in a method m may be reported as late as the time of m’s first invocation. As a web language, Dart is often loaded directly from source, with no inter- mediate binary representation. In the interests of rapid loading, Dart implemen- tations may choose to avoid full parsing of method bodies, for example. This can be done by tokenizing the input and checking for balanced curly braces on method body entry. In such an implementation, even syntax errors will be detected only when the method needs to be executed, at which time it will be compiled (JITed). In a development environment a compiler should of course report compilation errors eagerly so as to best serve the programmer. If an uncaught compile-time error occurs within the code of a running isolate A, A is immediately suspended. The only circumstance where a compile-time error could be caught would be via code run reflectively, where the mirror system can catch it. Typically, once a compile-time error is thrown and A is suspended, A will then be terminated. However, this depends on the overall environment. A Dart engine runs in the context of an embedder, a program that interfaces between the engine and the surrounding computing environment. The embedder will often be a web browser, but need not be; it may be a C++ program on the server for example. When an isolate fails with a compile-time error as described above, control returns to the embedder, along with an exception describing the problem. This is necessary so that the embedder can clean up resources etc. It is then the embedder’s decision whether to terminate the isolate or not. Static warnings are those errors reported by the static checker. They have no effect on execution. Many, but not all, static warnings relate to types, in which case they are known as static type warnings. Static warnings must be provided by Dart compilers used during development such as those incorporated in IDEs or otherwise intended to be used by developers for developing code. Compilers that are part of runtime execution environments such as virtual machines should not issue static warnings. Dynamic type errors are type errors reported in checked mode. Run-time errors are exceptions raised during execution. Whenever we say that an exceptionex is raised or thrown, we mean that a throw expression (16.9) of the form: throw ex; was implicitly evaluated or that a rethrow statement (17.10) of the form rethrow was executed. When we say that a C is thrown, where C is a class, we mean that an instance of class C is thrown. If an uncaught exception is thrown by a running isolateA,A is immediately suspended. 8 Variables variablesDart Programming Language Specification 13 Variables are storage locations in memory. variableDeclaration: declaredIdentifier (‘, ’ identifier) ; declaredIdentifier: metadata finalConstVarOrType identifier ; finalConstVarOrType: final type? const type? varOrType ; varOrType: var type ; initializedVariableDeclaration: declaredIdentifier (‘=’ expression)? (‘, ’ initializedIdentifier) ; initializedIdentifier: identifier (‘=’ expression)? ; initializedIdentifierList: initializedIdentifier (‘, ’ initializedIdentifier) ; A variable that has not been initialized has the initial value null (16.2). A variable declared at the top-level of a library is referred to as either a library variable or simply a top-level variable. A static variable is a variable that is not associated with a particular in- stance, but rather with an entire library or class. Static variables include library variables and class variables. Class variables are variables whose declaration is immediately nested inside a class declaration and includes the modifier static. A library variable is implicitly static. It is a compile-time error to preface a top-level variable declaration with the built-in identifier (16.33) static. Static variable declarations are initialized lazily. When a static variable vDart Programming Language Specification 14 is read, iff it has not yet been assigned, it is set to the result of evaluating its initializer. The precise rules are given in section 8.1. The lazy semantics are given because we do not want a language where one tends to define expensive initialization computations, causing long application startup times. This is especially crucial for Dart, which must support the coding of client applications. A final variable is a variable whose binding is fixed upon initialization; a final variable v will always refer to the same object after v has been initialized. The declaration of a final variable must include the modifier final. It is a static warning if a final instance variable that has been initialized at its point of declaration is also initialized in a constructor. It is a compile- time error if a local variable v is final and v is not initialized at its point of declaration. A library or static variable is guaranteed to have an initializer at its declaration by the grammar. Attempting to assign to a final variable anywhere except in its declaration or in a constructor header will cause a runtime error to be thrown as discussed below. The assignment will also give rise to a static warning. Any repeated assignment to a final variable will also lead to a runtime error. Taken as a whole, the rules ensure that any attempt to execute multiple assign- ments to a final variable will yield static warnings and repeated assignments will fail dynamically. A constant variable is a variable whose declaration includes the modifier const. A constant variable is always implicitly final. A constant variable must be initialized to a compile-time constant (16.1) or a compile-time error occurs. We say that a variable v is potentially mutated in some scope s if v is not final or constant and an assignment to v occurs in s. If a variable declaration does not explicitly specify a type, the type of the declared variable(s) is dynamic, the unknown type (19.6). A variable is mutable if it is not final. Static and instance variable declara- tions always induce implicit getters. If the variable is mutable it also introduces an implicit setter. The scope into which the implicit getters and setters are introduced depends on the kind of variable declaration involved. A library variable introduces a getter into the top level scope of the enclosing library. A static class variable introduces a static getter into the immediately enclosing class. An instance variable introduces an instance getter into the immediately enclosing class. A mutable library variable introduces a setter into the top level scope of the enclosing library. A mutable static class variable introduces a static setter into the immediately enclosing class. A mutable instance variable introduces an instance setter into the immediately enclosing class. Local variables are added to the innermost enclosing scope. They do not induce getters and setters. A local variable may only be referenced at a source code location that is after its initializer, if any, is complete, or a compile-time error occurs. The error may be reported either at the point where the premature reference occurs, or at the variable declaration.Dart Programming Language Specification 15 We allow the error to be reported at the declaration to allow implementations to avoid an extra processing phase. The example below illustrates the expected behavior. A variable x is declared at the library level, and another x is declared inside the function f. var x = 0; f(y)f var z = x; // compile-time error if (y)f x = x + 1; // two compile time errors print(x); // compile time error g var x = x++; // compile time error print(x); g The declaration inside f hides the enclosing one. So all references to x inside f refer to the inner declaration of x. However, many of these references are illegal, because they appear before the declaration. The assignment to z is one such case. The assignment to x in the if statement suffers from multiple problems. The right hand side reads x before its declaration, and the left hand side assigns to x before its declaration. Each of these are, independently, compile time errors. The print statement inside the if is also illegal. The inner declaration of x is itself erroneous because its right hand side at- tempts to read x before the declaration has terminated. The left hand side is not, technically, a reference or an assignment but a declaration and so is legal. The last print statement is perfectly legal as well. As another example var x = 3, y = x; is legal, because x is referenced after its initializer. A particularly perverse example involves a local variable name shadowing a type. This is possible because Dart has a single namespace for types, functions and vari- ables. class Cfg perverse()f var v = new C(); // compile-time error C aC; // compile-time error var C = 10; g Inside perverse(), C denotes a local variable. The type C is hidden by the vari- able of the same name. The attempt to instantiate C causes a compile-time error be- cause it references a local variable prior to its declaration. Similarly, for the decla- ration of aC (even though it is only a type annotation). As a rule, type annotations are ignored in production mode. However, we do not want to allow programs to compile legally in one mode and not an- other, and in this extremely odd situation, that consideration takes precedence. The following rules apply to all static and instance variables. A variable declaration of one of the forms T v;, T v = e; , const T v =Dart Programming Language Specification 16 e;, final T v; or final T v = e; always induces an implicit getter function (10.2) with signature T get v whose invocation evaluates as described below (8.1). A variable declaration of one of the forms var v;, var v = e; , const v = e;, final v; or final v = e; always induces an implicit getter function with signature get v whose invocation evaluates as described below (8.1). A non-final variable declaration of the form T v; or the form T v = e; always induces an implicit setter function (10.3) with signature void set v = (T x) whose execution sets the value of v to the incoming argument x. A non-final variable declaration of the form var v; or the form var v = e; always induces an implicit setter function with signature set v = (x) whose execution sets the value of v to the incoming argument x. evaluationOfImplicitVariableGetters 8.1 Evaluation of Implicit Variable Getters Letd be the declaration of a static or instance variable v. Ifd is an instance variable, then the invocation of the implicit getter of v evaluates to the value stored in v. If d is a static or library variable then the implicit getter method of v executes as follows: • Non-constant variable declaration with initializer. If d is of one of the forms var v = e; , T v = e; , final v = e; , final T v = e;, static v = e; , static T v = e; , static final v = e; or static final T v = e; and no value has yet been stored into v then the initializer expression e is evaluated. If, during the evaluation of e, the getter for v is invoked, a CyclicInitializationError is thrown. If the evaluation succeeded yielding an object o, let r =o, otherwise let r = null. In any case, r is stored into v. The result of executing the getter is r. • Constant variable declaration. If d is of one of the forms const v = e; , const T v = e; , static const v = e; or static const T v = e; the result of the getter is the value of the compile time constant e. Note that a compile time constant cannot depend on itself, so no cyclic references can occur. Otherwise • Variable declaration without initializer. The result of executing the getter method is the value stored in v. functions 9 Functions Functions abstract over executable actions.

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.