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).
Related
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.
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 {
...
}
...
}
I want to clean my code structure and put class/object files in another directories in my gatling project.
If i put all simulation class and utils class in the same directory and same package i do not need an import statement and everything works fine.
Let's say my structure is as follow :
/user-files
----/simulations
--------MySimulation.scala
----/utils
--------Router.scala
I have tried several import or naming configuration to be able to use Router in my Simulation.
Follow package naming as directories structure
Put simulations and utils class in the same package
I have also tried different style of import
//using package
import packagename.Router
//another try
import packagename.Router._
//without package name
import Router._
My attempt to search a solution on scala docs or stack overflow didn't helped me.
This is the error given after executing gatling.bat
not found: value Router
You can't do that this way: there's one single source folder, which is by default /user-files/simulations.
If you want to use folders/packages (which is a good thing), you can have a structure such as:
/user-files
----/simulations
--------MySimulation.scala
--------/utils
------------Router.scala
Then, in Scala, packages and folder hierarchy are not related, BUT it's a good practice to use the same convention as in Java.
So, you would have:
package utils
object Router
then in MySimulation:
import utils.Router
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.