Here is sample in Dart language:
patch class List<E> {
}
This is not patch file because it has extension .dart and contains regular source code written in Dart language except for patch keyword.
Will be this keyword standardized in future in TC52 - Dart - Ecma International?
patch classes are a VM/compiler feature that are not accessible to normal developers. It is used to share code between the VM and dart2js implementation.
There is no need to standardize the keyword in TC52.
Related
I'd like to get the names of all of the Dart classes in a file. How can I do that?
In my dart project projectxyz, I have a dart class declared in in myclass.dart. In main.dart, Android Studio gives two ways, both work, but I did not understand what are the pros and cons of each method:
import 'myclass.dart';
or:
import 'package:projectxyz/myclass.dart';
What is the difference in these two approaches?
That depends on how the main file itself is invoked (and where it's located).
I'll assume the main.dart library is inside the lib/ directory, because otherwise you wouldn't have the two options for importing myclass.dart.
If you invoke the main file with a file: URI, then the relative import of myclass.dart will also be imported with a file: URI. Since Dart uses the import URI to distinguish different libraries, if someone else imports myclass.dart using a package: URI, then it will be treated as two different libraries introducing different classes with the same name.
It used to be that running dart lib/main.dart would treat that as a file: URI. The Dart parser has gotten smarter about that, and now it recognizes that an entry point library in a lib/ directory should have been a package: URI, and replaces the entry point URI with package:projectxyz/main.dart.
After that, it makes no difference whether you use myclass.dart or package:projectxyz/myclass.dart.
Really, there is no difference between the two. Saying import 'myclass.dart' is high-level sugar for import 'package:projectxyz/myclass.dart';.
On the other hand, import 'myclass.dart' is easier to read and understand, and generally looks better. It also decreases confusion as to where exactly your code is being imported from, as anybody who reads this statement knows to look for the file elsewhere in your project. Because of this, you should try to use this form wherever possible.
I'm currently playing with the Dart version of Angular 2.
I have seen that the library is using a lot of Metadata as #Component for example.
I would like to know how are those directives working?
I went on http://www.darlang.org. They explain how to define an annotation but not how to use it to construct an object as it is done in angular.io.
Could someone explain how the magic is working?
In Dart annotations by itself don't do anything than exist beside the code element where they are added.
At runtime:
You can use dart:mirrors to query the imported libraries for elements like fields, functions, classes, parameters, ... for these annotations.
dart:mirrors is discouraged for browser applications. In this case you can use the reflectable package with quite similar capabilities.
See also:
https://www.dartlang.org/articles/reflection-with-mirrors/
https://api.dartlang.org/1.14.1/dart-mirrors/dart-mirrors-library.html
https://stackoverflow.com/search?q=%5Bdart-mirrors%5D+annotations
At buildtime
You can create a transformer and register it in pubspec.yaml to be run by pub serve and pub build.
In this case the Dart analyzer can be utilized to query the source files for annotations and, like Angular does, modify the source code in a build step to add/replace/remove arbitrary code.
For more details about transformers
- https://www.dartlang.org/tools/pub/assets-and-transformers.html
- https://www.dartlang.org/tools/pub/transformers/
- https://www.dartlang.org/tools/pub/transformers/examples/
- https://www.dartlang.org/tools/pub/transformers/aggregate.html
- https://pub.dartlang.org/packages/code_transformers
I decided to implement the functional underscore.js library in Dart.
I wrote the functions in 'underscore.dart' with some example functions shown below:
library underscore;
List _filter (ff, List s) => return s..retainWhere(ff);
List _dropWhile(ff,List s) => s.skipWhile(ff).toList();
In my main Dart program, I then added the import statement
import 'underscore.dart';
However, I got the persistent error on that line of 'Unused Import', and so none of the functions were recognised.
It did work, though, when I redefined 'underscore.dart' as 'part of mainProg' and made 'mainProg' a library in its own right.
Further testing shows that it is the underscores on the function names that is causing the problem.
Any ideas?
A prepending underscore means that the function is library private. That is, you can't use it in an other library. See Libraries and Visibility.
Libraries not only provide APIs, but are a unit of privacy: identifiers that start with an underscore (_) are visible only inside the library.
Create a sample web application using the Web UI (web_ui) library, e.g., mylib
open mylib.dart, make it a library:
library mylib;
import 'dart:html';
import 'package:web_ui/web_ui.dart';
part 'xclickcounter.dart';
...
open xclickcounter.dart, remove imports and insert:
part of mylib;
web/out/mylib.dart and web/out/xclickcounter.dart get messed up:
The included part ''xclickcounter.dart'' must have a part-of directive
Classes can only mixin other classes
Mixin can only be applied to class
... more errors follow
What am I doing wrong? Please help :(
Edit: if I don't edit generated sample code, wdc will generate code that falls into separate libraries:
web/out/xclickcounter.dart => x_click_counter
web/out/mylib.dart => mylib_html
Does it mean that if we use web_ui we should not create our own libraries and wdc will do this for us automatically?
Update: if I don't use any library name, similar to what generated sample code does, and only rely on the library names generated by xdc in web/out/... files, I still run into trouble when importing my two components into a 3rd file. Dart Editor will produce the following warning:
The imported libraries 'compa.dart' and 'compb.dart'
should not have the same name
The workaround is to name your libraries based on what xdc produces in web/out/... files, that is:
compa.dart => x-comp-a
compb.dart => x-comp-b
After explicitly placing components into libraries like these the Dart Editor warning disappears.