I'm learning java and I'm told this package is provided by default, to every class, because its methods are so common. I thought I would try to import it, any way to see what would happen. I know its not practical and probably expensive but I'm curious as to why it's doesn't work from a technical point of view.
import javax.lang.*;//why doesn't this work.
javax.lang contains only a single package: model
https://docs.oracle.com/javase/7/docs/api/index.html?javax/lang/model/package-summary.html
you're not doing anything by importing this package. Maybe you're confusing it with java.lang ?
You don't need to import java.lang.*
There is one exception to the import rule. All classes in the java.lang package are imported by default. Thus you do not need to import java.lang.*; to use them without fully qualified names.
Consider the System.out.println() method we've been using since the first day of class.
System is really the java.lang.System class. This class has a public static field called out which is an instance of the java.io.PrintStream class. So when you write System.out.println(), you're really calling the println() method of the out field of the java.lang.System class.
Related
I'm still a newbie to swift and I can't get a clear answer on a couple things.
So far I've just been using a single file in playgrounds.
If I want to use more files, how can I access data (variables and functions) from classes created there in my main file that controls the view?
From what I understand having multiple files would just be for convenience so I don't have could to write it again.
(Also on the side) what does it mean when a function has private, public or just 'func'?
I'm using swift 3 playgrounds
Thanks
Making things public will make them importable from other modules. Making it private will make it only accessible by methods within its containing scope (encapsulation). For code that lives at the top level, this scope is the entire .swift file it lives in. Without either access modifier (just bare “func”), your thing will default to internal, which means it is accessible from any other code within the same module, but not by code in a different module.
A special case is the fileprivate modifier which restricts access to the .swift file the code lives in. For code that does not live in a class or struct, this does the exact same thing as private. Some Swift designers discourage use of this modifier, and it may be removed in future versions of Swift.
There is a fifth access modifier in Swift, open, which does the exact same thing as public, except it also allows subclassing, and only applies to classes. This one is rarely used, but useful for certain library interfaces.
To import all the public symbols in a module, use
import Module
To import a single public symbol, use
import var Module.variable
import func Module.function
import struct Module.structure
import class Module.class
...
Is it possible to import just one class from a Swift module? I used
import struct Foundation.Date
but now, NSString and other Foundation classes/structs are available too, at the top level!
All I really want is the Date class, to avoid polluting the namespace.
This answer is originally made for objective-c but the behaviour is the same: Why does a simple program import <Foundation/Foundation.h> instead of individual header files?
You don't have to worry about that, I think your compiler do this job perfectly ! :)
I subclassed org.scalatest.FlatSpec to add practical tooling to FlatTest. But anywhere I use this subclass, I have to import scala.language.reflectiveClass otherwise I get
reflective access of structural type member method test should be enabled
by making the implicit value scala.language.reflectiveCalls visible.
The method test in question is the equivalent to should in standard FlatSpec:
it should "do some stuff" in { ...}
Why is it not necessary to import reflectiveCalls to use flatSpec should but is necessary for my test method, and how can I avoid that?
The reason why you are getting this warning is that you have structural type reference or new {...} call somewhere in your test method.
Unfortunately there is no way to turn off that warning other than by explicit scala.language.reflectiveClass import or rewriting your code.
Say I have an app, MyApp which is built in an Xcode workspace. Inside this workspace I have the primary app target and two nested Xcode projects for my frameworks, Foo and Bar.
Inside my app I import Foo and Bar and dependency inject an object in Foo into an object in Bar. Say, however, I don't need all of Foo, just a couple of classes. How could I create a submodule within foo and import that. E.g. import Foo.Models.Animals.Dog
While you can do something like
import struct MyModule.MyStruct
import func Darwin.glob
I'm not sure if you can get much deeper than that. Here's a relevant quote from the (free) Swift book
“Providing more detail limits which symbols are imported—you can specify a specific submodule or a specific declaration within a module or submodule. When this detailed form is used, only the imported symbol (and not the module that declares it) is made available in the current scope.”
It goes on to explain that you can import any of typealias, struct, class, enum, protocol, var, or func
It looks as though Swift has some type of support for submodules (they're mentioned offhand a few places), but I'm not sure we have the ability to actually compile those just yet.
I would like to define an implicit conversion from Iterator[T] to a class that I have defined: ProactiveIterator[A].
The question isn't really how to do it but how to do it properly, i.e. where to place the method, so that it is as transparent and unobtrusive as possible. Ideally it should be as the implicit conversion from String to StringOps in scala.Predef If the conversion was from a class in the library to some other class, then it could be defined inside that class, but AFAIK that's not possible here.
So far I have considered to add an object containing these conversions, similarly to JavaConversions, but better options may be possible.
You don't really have much of a choice. All implicits must be contained within some sort of object, and imported with a wildcard import (you could import them individually, but I doubt you want that).
So you'll have some sort of implicits object:
package foo.bar
object Implicits {
implicit class ProactiveIterator[A](i: Iterator[A]) {
...
}
}
Then you must explicitly import it wherever you use it:
import foo.bar.Implicits._
In my opinion, this is a good thing. Someone reading the code might not understand where your pimped methods are coming from, so the explicit import is very helpful.
You can similarly place your implicits within a package object. You would have to import them the same way into other namespaces, but they would be available to classes within the same package.
For example, using the following, anything within foo.bar will have this implicit class available:
package foo
package object bar {
implicit class ProactiveIterator[A](i: Iterator[A]) {
...
}
}
Elsewhere you would import foo.bar._ (which may or may not be as clean, depending on what's in bar).