Does dart have some sort of alias for naming conflicts like this?
library flutterfly;
import 'dart:ui';
class Color {
Color._();
// Color should be the class from dart:ui instead of itself.
static Color white() {
return Color(#FFFFFFFF);
}
}
Import the library with a namespace/prefix:
import 'dart:ui' as ui;
class Color {
Color._();
static ui.Color white() {
return ui.Color(0xFFFFFFFF);
}
}
That said, because whoever imports your flutterfly library can choose whatever library prefix they want (if any), adding your own Color class to use as a namespace isn't very useful, and its presence likely would cause conflicts for anything that uses it. Effective Dart recommends against classes that contain only static members. For this example, you could use top-level functions instead.
Related
I often see people use the keyword using in their Haxe code. It seem to go after the import statements.
For example, I found this is a code snippet:
import haxe.macro.Context;
import haxe.macro.Expr;
import haxe.macro.Type;
using haxe.macro.Tools;
using Lambda;
What does it do and how does it work?
The "using" mixin feature of Haxe is also referred as "static extension". It's a great syntactic sugar feature of Haxe; they can have a positive effect on code readability.
A static extension allows pseudo-extending existing types without modifying their source. In Haxe this is achieved by declaring a static method with a first argument of the extending type and then bringing the defining class into context through the using keyword.
Take a look at this example:
using Test.StringUtil;
class Test {
static public function main() {
// now possible with because of the `using`
trace("Haxe is great".getWordCount());
// otherwise you had to type
// trace(StringUtil.getWordCount("Haxe is great"));
}
}
class StringUtil {
public static inline function getWordCount(value:String) {
return value.split(" ").length;
}
}
Run this example here: http://try.haxe.org/#C96B7
More in the Haxe Documentation:
Haxe static extensions in the Haxe Manual
Haxe static extensions tagged articles in the Haxe Code Cookbook
I'm trying to learn how to implement logging using the examples/tutorial in:
http://blog.dartwatch.com/2013/05/campaign-to-use-real-logging-instead-of.html#comment-form
But having imported the libraries this line in main will not compile because the class 'PrintHandler' is not recognized and Google has not been a help in this case. My server application consists of a main and three classes. I'm new at Dart. Below I've extracted the logging code that I added.
In what library is 'PrintHandler'? Is this a class I need to write?
library server;
import 'package:logging_handlers/logging_handlers_shared.dart';
import 'package:logging/logging.dart';
final _serverLogger = new Logger("server"); // top level logger
void main() {
Logger.root.onRecord.listen(new PrintHandler()); // default PrintHandler
_serverLogger.fine("Server created");
}
class A {
}
class B {
}
class C {
}
It looks like the class was changed to LogPrintHandler but the tutorial and documentation were not updated.
The documentation only mentions nested types, but it's not clear if they can be used as namespaces. I haven't found any explicit mentioning of namespaces.
I would describe Swift's namespacing as aspirational; it's been given a lot of advertising that doesn't correspond to any meaningful reality on the ground.
For example, the WWDC videos state that if a framework you're importing has a class MyClass and your code has a class MyClass, those names do not conflict because "name mangling" gives them different internal names. In reality, however, they do conflict, in the sense that your own code's MyClass wins, and you can't specify "No no, I mean the MyClass in the framework" — saying TheFramework.MyClass doesn't work (the compiler knows what you mean, but it says it can't find such a class in the framework).
My experience is that Swift therefore is not namespaced in the slightest. In turning one of my apps from Objective-C to Swift, I created an embedded framework because it was so easy and cool to do. Importing the framework, however, imports all the Swift stuff in the framework - so presto, once again there is just one namespace and it's global. And there are no Swift headers so you can't hide any names.
EDIT: In seed 3, this feature is now starting to come online, in the following sense: if your main code contains MyClass and your framework MyFramework contains MyClass, the former overshadows the latter by default, but you can reach the one in the framework by using the syntax MyFramework.MyClass. Thus we do in fact have the rudiments of a distinct namespace!
EDIT 2: In seed 4, we now have access controls! Plus, in one of my apps I have an embedded framework and sure enough, everything was hidden by default and I had to expose all the bits of the public API explicitly. This is a big improvement.
Answered by SevenTenEleven in the Apple dev forum:
Namespaces are not per-file; they're per-target (based on the
"Product Module Name" build setting). So you'd end up with something
like this:
import FrameworkA
import FrameworkB
FrameworkA.foo()
All Swift declarations are considered to be part of
some module, so even when you say "NSLog" (yes, it still exists)
you're getting what Swift thinks of as "Foundation.NSLog".
Also Chris Lattner tweeted about namespacing.
Namespacing is implicit in Swift, all classes (etc) are implicitly
scoped by the module (Xcode target) they are in. no class prefixes
needed
Seems to be very different what I have been thinking.
While doing some experimentation with this I ended up creating these "namespaced" classes in their own files by extending the root "package". Not sure if this is against best practices or if it has any implications I'm mot aware of(?)
AppDelegate.swift
var n1 = PackageOne.Class(name: "Package 1 class")
var n2 = PackageTwo.Class(name: "Package 2 class")
println("Name 1: \(n1.name)")
println("Name 2: \(n2.name)")
PackageOne.swift
import Foundation
struct PackageOne {
}
PackageTwo.swift
import Foundation
struct PackageTwo {
}
PackageOneClass.swift
extension PackageOne {
class Class {
var name: String
init(name:String) {
self.name = name
}
}
}
PackageTwoClass.swift
extension PackageTwo {
class Class {
var name: String
init(name:String) {
self.name = name
}
}
}
Edit:
Just found out that creating "subpackages" in above code wont work if using separate files. Maybe someone can hint on why that would be the case?
Adding following files to the above:
PackageOneSubPackage.swift
import Foundation
extension PackageOne {
struct SubPackage {
}
}
PackageOneSubPackageClass.swift
extension PackageOne.SubPackage {
class Class {
var name: String
init(name:String) {
self.name = name
}
}
}
Its throwing a compiler error:
'SubPackage' is not a member type of 'PackageOne'
If I move the code from PackageOneSubPackageClass.swift to PackageOneSubPackage.swift it works. Anyone?
Edit 2:
Fiddling around with this still and found out (in Xcode 6.1 beta 2) that by defining the packages in one file they can be extended in separate files:
public struct Package {
public struct SubPackage {
public struct SubPackageOne {
}
public struct SubPackageTwo {
}
}
}
Here are my files in a gist:
https://gist.github.com/mikajauhonen/d4b3e517122ad6a132b8
I believe this is achieved using:
struct Foo
{
class Bar
{
}
}
Then it can be accessed using:
var dds = Foo.Bar();
Namespaces are useful when you need to define class with the same name as class in existing framework.
Suppose your app has MyApp name, and you need to declare your custom UICollectionViewController.
You don't need to prefix and subclass like this:
class MAUICollectionViewController: UICollectionViewController {}
Do it like this:
class UICollectionViewController {} //no error "invalid redeclaration o..."
Why?. Because what you've declared is declared in current module, which is your current target. And UICollectionViewController from UIKit is declared in UIKit module.
How to use it within current module?
var customController = UICollectionViewController() //your custom class
var uikitController = UIKit.UICollectionViewController() //class from UIKit
How to distinguish them from another module?
var customController = MyApp.UICollectionViewController() //your custom class
var uikitController = UIKit.UICollectionViewController() //class from UIKit
Swift uses modules much like in python (see here and here) and as #Kevin Sylvestre suggested you can also use the nested types as namespaces.
And to extend the answer from #Daniel A. White, in WWDC they were talking about the modules in swift.
Also here is explained:
Inferred types make code cleaner and less prone to mistakes, while
modules eliminate headers and provide namespaces.
You can use extension to use the mentioned structs approach for namespacing without having to indent all of your code towards the right. I've been toying with this a bit and I'm not sure I'd go as far as creating Controllers and Views namespaces like in the example below, but it does illustrate how far it can go:
Profiles.swift:
// Define the namespaces
struct Profiles {
struct Views {}
struct ViewControllers {}
}
Profiles/ViewControllers/Edit.swift
// Define your new class within its namespace
extension Profiles.ViewControllers {
class Edit: UIViewController {}
}
// Extend your new class to avoid the extra whitespace on the left
extension Profiles.ViewControllers.Edit {
override func viewDidLoad() {
// Do some stuff
}
}
Profiles/Views/Edit.swift
extension Profiles.Views {
class Edit: UIView {}
}
extension Profiles.Views.Edit {
override func drawRect(rect: CGRect) {
// Do some stuff
}
}
I haven't used this in an app since I haven't needed this level of separation yet but I think it's an interesting idea. This removes the need for even class suffixes such as the ubiquitous *ViewController suffix which is annoyingly long.
However, it doesn't shorten anything when it's referenced such as in method parameters like this:
class MyClass {
func doSomethingWith(viewController: Profiles.ViewControllers.Edit) {
// secret sauce
}
}
Even though it is possible to implement namespaces using Framework and Libraries but the best solution is to use local packages using Swift Package Manager. Besides having access modifiers, this approach has some other benefits. As in Swift Package Manager, the files are managed based on the directory system, not their target member ship, you won't have to struggle with merge conflicts that arise frequently in teamworks. Furthermore, there is no need to set file memberships.
To check how to use local Swift packages refer to the following link:
Organizing Your Code with Local Packages
In case anyone was curious, as of June 10th 2014, this is a known bug in Swift:
From SevenTenEleven
"Known bug, sorry! rdar://problem/17127940 Qualifying Swift types by their module name doesn't work."
What is the difference between show and as in an import statement?
For example, what's the difference between
import 'dart:convert' show JSON;
and
import 'package:google_maps/google_maps.dart' as GoogleMap;
When do I use show and when should I use as?
If I switch to show GoogleMap all references to GoogleMap (e.g. GoogleMap.LatLng) objects are reported as undefined.
as and show are two different concepts.
With as you are giving the imported library a name. It's usually done to prevent a library from polluting your namespace if it has a lot of global functions. If you use as you can access all functions and classes of said library by accessing them the way you did in your example: GoogleMap.LatLng.
With show (and hide) you can pick specific classes you want to be visible in your application. For your example it would be:
import 'package:google_maps/google_maps.dart' show LatLng;
With this you would be able to access LatLng but nothing else from that library. The opposite of this is:
import 'package:google_maps/google_maps.dart' hide LatLng;
With this you would be able to access everything from that library except for LatLng.
If you want to use multiple classes with the same name you'd need to use as. You also can combine both approaches:
import 'package:google_maps/google_maps.dart' as GoogleMap show LatLng;
show case:
import 'dart:async' show Stream;
This way you only import Stream class from dart:async, so if you try to use another class from dart:async other than Stream it will throw an error.
void main() {
List data = [1, 2, 3];
Stream stream = new Stream.fromIterable(data); // doable
StreamController controller = new StreamController(); // not doable
// because you only show Stream
}
as case:
import 'dart:async' as async;
This way you import all class from dart:async and namespaced it with async keyword.
void main() {
async.StreamController controller = new async.StreamController(); // doable
List data = [1, 2, 3];
Stream stream = new Stream.fromIterable(data); // not doable
// because you namespaced it with 'async'
}
as is usually used when there are conflicting classes in your imported library, for example if you have a library 'my_library.dart' that contains a class named Stream and you also want to use Stream class from dart:async and then:
import 'dart:async';
import 'my_library.dart';
void main() {
Stream stream = new Stream.fromIterable([1, 2]);
}
This way, we don't know whether this Stream class is from async library or your own library. We have to use as :
import 'dart:async';
import 'my_library.dart' as myLib;
void main() {
Stream stream = new Stream.fromIterable([1, 2]); // from async
myLib.Stream myCustomStream = new myLib.Stream(); // from your library
}
For show, I guess this is used when we know we only need a specific class. Also can be used when there are conflicting classes in your imported library. Let's say in your own library you have a class named CustomStream and Stream and you also want to use dart:async, but in this case you only need CustomStream from your own library.
import 'dart:async';
import 'my_library.dart';
void main() {
Stream stream = new Stream.fromIterable([1, 2]); // not doable
// we don't know whether Stream
// is from async lib ir your own
CustomStream customStream = new CustomStream();// doable
}
Some workaround:
import 'dart:async';
import 'my_library.dart' show CustomStream;
void main() {
Stream stream = new Stream.fromIterable([1, 2]); // doable, since we only import Stream
// async lib
CustomStream customStream = new CustomStream();// doable
}
as and show keywords used with library import statement. These two keywords are optional with import keyword, But using these keywords you can provide convenience and additional information about your library importing.
show
show give restrictions to access only specific class of that library.
import 'dart:convert' show JSON;
Above dart:convert library contains more than 5 types of converters. (ascii,Base64,Latin1,Utf8 & json are some of them).
But with using show keyword you will give your application source file to access only that JSON converter class only.
warning !! :- if you try to access any other converters like ascii, Base64 or Latin1, you will get an exception.
Because using show keyword you give an restriction for only access Json class in that library api.
So if your source file want to access all the class in that library, you cannot define show keyword for that library importing.
as
Provide additional namespace for library members.
This as keyword is mostly used when a library that contains lot of global functions.
You will access static members of a library by Using the class name and . (dot operator).
eg:- ClassName.staticFun()
And also you will access instance methods and variables by using object name and . (dot operator) eg:- obj.instanceFunc()
And also library source file can have global functions. and we will access them by their name without any parental membership. eg:- func()
So when we access global functions of a different library inside our source file, we didnt have a way to seperatly identified that global function as seperate function of a different library.
But using as keyword, we can add namespace before accessing global functions of that library.
See below example to understanding real benefit of as keyword. 👇
import 'package:http/http.dart' as http;
http library contains lot of global functions. Below shows list of global functions in http library.
Accessing above http library global functions without http namespace.( import 'package:http/http.dart'; )
eg:-
1. get("url")
2. post("url")
Accessing above http library global functions with http namespace. ( import 'package:http/http.dart'as http; )
eg:-
1. http.get("url")
2. http.post("url")
So using as keyword , makes it easy to identify global functions of a different library separated from our source files' global functions.
I prefer the dart document, it's described in Libraries and visibility section.
import as: Specifying a library prefix, for example when import two libraries which has the same function name, then we can give them a prefix to specify the library.
import show: This is used to import part of the library, show only import one name of the library.
import hide: This is another one which is the opposite of the show, hide import all names except the name specified in the hide.
Is there a way to do something akin to import <BLAH> as in actionscript? I've got some classes that I don't want to type the full class name out for every time I use them. That's why I'm trying to find an import as, or var C = ImportedClassThatIDontWantToTypeEveryTime. I've tried a few different ways, such as:
package com.mysite.blah {
// doesn't work
import com.mysite.ImportedClassThatIDontWantToTypeEveryTime as C;
// also doesn't work
import com.mysite.ImportedClassThatIDontWantToTypeEveryTime;
var C:Class = ImportedClassThatIDontWantToTypeEveryTime;
// ????
public class SomeOtherClass {
public function blah():void {
C.doSomething();
}
}
}
I know there is a way to do this - I've done it before years ago. However, I can't remember how to do it. Help?
What IDE are you using? I ask this because I haven't had to type out a class-path in full in years. The auto-complete features of both FlashDevelop and FlashBuilder will allow you to type the first couple of letters of the class you want in place, select it from a list, and it will automatically add the appropriate import statement to the top of your class.