I have a set of Swift Packages that I'm writing (ex: CUIExpandableButton), that I'd like to roll up into another Swift Package called CrystalUI. The overall goal is to write a set of packages that get bundled into a single package. However, I want to make it so people can just have one import
import CrystalUI
instead of a series of import statements
import CrystalUI
import CUIExpandableButton
import PreviewKit
...
Is it possible to re-expose an existing library as part of the parent library?
Looks like #_exported Is what I was looking for. Found this article that explains it. It's an unsupported method but it's also used in Alamofire so I think it's safe.
Related
Instead of writing :
import 'package:flutter_platform_widgets/flutter_platform_widgets.dart';
which exports a dozen of files, I would like to write :
import 'package:flutter_platform_widgets/flutter_platform_widgets.dart'
show
PlatformAlertDialog,
PlatformCircularProgressIndicator,
PlatformDialogAction,
PlatformText,
showPlatformDialog;
because I'm only using these components. However this is quite tidious (reminds me of Typescript's endless imports) and goes against Dart's principle of briefness.
Imports snippets in VSCode uses the first solution, but is there any notable difference, for example in terms of performance? Is there some kind of good practice? I cannot find anything in official guidelines.
There is no impact on performance. The reason of using show is to reduce chances of confusion when importing classes from different packages.
For instance: Let's say
abc.dart has 2 classes
class One {}
class Two {}
And xyz.dart also has 2 classes:
class One {}
class Three {}
And you are importing both package in your file
import 'abc.dart';
import 'xyz.dart';
Say, you only want to use class One from abc.dart, so when you use One it could be from abc.dart or xyz.dart. So to prevent One coming from xyz.dart you'd use:
import `xyz.dart` show Three // which means only `Three` class can be used in your current file from xyz.dart package
When you use the keyword show basically what you are saying that I only want to use this specific class from this package in your dart file, from the docs:
Importing only part of a library
If you want to use only part of a library, you can selectively import the library. For example:
// Import only foo.
import 'package:lib1/lib1.dart' show foo;
// Import all names EXCEPT foo.
import 'package:lib2/lib2.dart' hide foo;
Now if you try to use anything from this package other than foo you will get an error because you specified that you only want to use foo.
I'm about to try implementing some IoC/DI framework in our application (thinking of Inversify, if there are any other recommendations) but we still have the problem of having to include the files for their Types. How do we get around this? We're using the latest version of TypeScript (2.3 as of writing this).
We have a lot of imports for various types, for example:
// Components
import {GuideTime} from '../components/guide-time/guide-time.component';
import {GuideNetwork} from '../components/guide-network/guide-network.component';
import {GuideDetail} from '../components/guide-detail/guide-detail.component';
import {Player} from '../components/player/player.component';
// Services
import {Keys, KeyService} from '../core/services/key.service';
import {GuideService} from '../core/services/guide/guide.service';
import {afterCSSUpdate} from '../core/services/utility.service';
import {DataService} from '../core/services/data/data.service';
Or just to get the type of something:
import {ITitle} from '../../models/title.interface';
import {IGuide} from '../../models/guide.interface';
Is there a way to consolidate these (preferably automatically, or globally)? I realize I can probably make a mytypes.ts file somewhere and then just import and export all the types from our application so there's a single, central file to import, but that introduces other problems (and a lot of work).
Thanks!
To make all of these global you would need to import them all to a single interface, and then import that interface wherever you need access to every type. Something similar to
import * as mainInterface from 'MainInterface'
Additionally, you could try importing for side effects only (which would give you access to the types), although this is not recommended in practice.
From the documentation:
Though not recommended practice, some modules set up some global state that can be used by other modules. These modules may not have any exports, or the consumer is not interested in any of their exports. To import these modules, use: import "./my-module.js";
EDIT Additionally, similar to the above single interface solution, you can put each of the types into the same namespace. You can spread a namespace across multiple files using this approach, which means you can just wrap each type in a main namespace.
namespace MainNamespace {
export class GuideTime {
...
}
...
}
Probably a basic mistake, but the cause is eluding me. I am trying to import a package, but I get an error saying it cannot be found or imported.
First I set the current directory to the parent directory of the package, and this does not work.
Second, the docs say that the parent folder of the package must be added to the matlab path. I tried this, and still no luck.
It is not due to using plot as the package name as I get the same error when trying to import analysis.
What I can do is to import using: import plot.* or import analyse.* and then go on to use the functions in the packages, but I want to use the namespaces (i.e. not use .*).
Edit
I'm having this problem on both versions I have installed: 2015b and 2016a.
The answer is that, somewhat counterintuitively, you don't need to call import at all. The docs state that
The parent of the top-level package folder must be on the MATLAB path.
Which is what your addpath(pwd) does and then state that (emphasis is mine):
All references to packages, functions, and classes in the package must
use the package name prefix, unless you import the package.
Meaning at this stage you should be able to call
analyse.testFunc
If you were to import analyse.testFunc you would then be able to call testFunc without prefacing it with the namespace but since you want to retain the namespace the answer is to not call import at all.
I have a class uses the following lines, it works fine in a Google App Engine project:
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
But when I included this class in another project, it cause error :
package javax.jdo.annotations does not exist
What should I do to find javax.jdo.* ?
Add the JDO jar file to the class path.
The star notation for imports isn't working the way you think it does.
It's not recursive - it only applies the child classes in javax.jdo, not the child packages.
If you want all the classes in javax.jdo.annotations, you'll need to import javax.jdo.annotations.*, too.
I'd recommend not using the star notation. Better to type out the imports for every class individually. Use an IDE to help you. It's clearer for you and other programmers who come after you where those classes came from.
I want to import the entire weka.classifiers.functions package but dont want to import RBFNetwork class.
(ns com.wekatest
(:import (weka.classifiers Classifier Evaluation)
(weka.classifiers.functions)
(weka.core Attribute FastVector Instance Instances)))
Edit: (weka.classifiers.functions) doesn't import the entire package. How do I do that?
Clojure does not provide a way to import every class in a Java package without specifying each class explicitly. See here for Rich Hickey's response to essentially the same question: http://groups.google.com/group/clojure/browse_thread/thread/fa00a0ff4c264f9a
This does not preclude you from writing code that would add this functionality, but Rich also mentions why this could be difficult (Java packages are not enumerable, so you would have to walk the classpath to know what classes are inside each package).