Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 // Copyright (c) 2013, the Dart project authors. Please see the AUTHORS file | |
| 2 // for details. All rights reserved. Use of this source code is governed by a | |
| 3 // BSD-style license that can be found in the LICENSE file. | |
| 4 | |
| 5 part of dart.core; | |
| 6 | |
| 7 class _Deprecated { | |
| 8 const _Deprecated(); | |
| 9 } | |
| 10 | |
| 11 class _Override { | |
| 12 const _Override(); | |
| 13 } | |
| 14 | |
| 15 /** | |
| 16 * The annotation "@deprecated" marks a feature as deprecated. | |
| 17 * | |
| 18 * The intent of the "@deprecated" annotation is to inform users of a feature | |
| 19 * that they should change their code, even if it is currently still working | |
| 20 * correctly. | |
| 21 * | |
| 22 * A deprecated feature is scheduled to be removed at a later time. This means | |
| 23 * that a deprecated feature should not be used, or code using it will break | |
| 24 * at some point in the future. If there is code using the feature, that | |
| 25 * code should be rewritten to not use the deprecated feature. | |
| 26 * | |
| 27 * A deprecated feature should document how the same effect can be achieved, | |
| 28 * so the programmer knows how to rewrite the code. | |
| 29 * | |
| 30 * The "@deprecated" annotation applies to libraries, top-level declarations | |
| 31 * (variables, getters, setters, functions, classes and typedefs), | |
| 32 * class-level declarations (variables, getters, setters, methods, operators or | |
| 33 * constructors, whether static or not), named optional arguments and | |
| 34 * trailing optional positional parameters. | |
| 35 * | |
| 36 * Deprecation is transitive: | |
| 37 * If a library is deprecated, so is every member of it. | |
| 38 * If a class is deprecated, so is every member of it. | |
| 39 * If a variable is deprecated, so are its implicit getter and setter. | |
| 40 * | |
| 41 * A tool that processes Dart source code may report when: | |
| 42 * - the code imports a deprecated library. | |
| 43 * - the code exports a deprecated library, or any deprecated member of | |
| 44 * a non-deprecated library. | |
| 45 * - the code refers statically to a deprecated declaration. | |
| 46 * - the code dynamically uses a member of an object with a statically known | |
| 47 * type, where | |
| 48 * - the member is deprecated on the static type of the object, or | |
| 49 * - the member use is a method call with an optional parameter where the | |
| 50 * parameter is deprecated on the member in the object's static type. | |
| 51 * | |
| 52 * If the deprecated use is inside a library, class or method which is itself | |
| 53 * deprecated, the tool should not bother the user about it. | |
| 54 * A deprecated feature is expected to use other deprecated features. | |
| 55 */ | |
| 56 const deprecated = const _Deprecated(); | |
| 57 | |
| 58 /* | |
| 59 * The annotation "@override" marks an instance member as overriding a | |
| 60 * superclass member with the same name. | |
| 61 * | |
| 62 * The annotation applies to instance methods, getters and setters, and to | |
| 63 * instance fields, where it means that the implicit getter and setter of the | |
| 64 * field is marked as overriding, but the field itself is not. | |
| 65 * | |
| 66 * A tool may report if no declaration of an annotated member is inherited by | |
| 67 * the class from either a superclass or an interface. | |
| 68 * | |
| 69 * The intent of the "override" notation is to catch situations where a | |
| 70 * superclass renames a member, and an independent subclass which used to | |
| 71 * override the member, could silently continue working using the | |
| 72 * superclass implementation. | |
| 73 */ | |
| 74 const override = const _Override(); | |
|
ahe
2013/10/23 14:32:55
This is not OK. You need explicit approval from th
| |
| OLD | NEW |