Edited this question to be more clear, see comments below for explanation.
So this seems kinda obvious to me, but it doesn't seem like it works that way, but if I have a scala package object and it's in the top level of my packages. Say like com.company and it's something simple like below
package com
package object company{
val something = "Hello world."
}
Now it would seem to me that this variable would trickle down and be accessible from it's child packages, but they aren't.
// 2 Layers down instead of the direct child
package com.company.app
import com.company._
object Model extends App {
println(something)
}
This seems to only work with the import, which is fine, but I was hoping with the package object I could define top level things for the entire package and have it trickle down, but is that not the case? Is there a way for this to work? I appreciate any insight into this.
The code posted in your question works as it is without an import. If you want the definitions of all packet objects above your current package to trickle down, you will have to modify the package statement of the classes in subpackages
Package object
package com
package object company {
val something = "Hello world."
}
Class in a subpackage com.company.model
package com
package company
package model
// package com.company.model would not work here!
object Model extends App {
println(something)
}
This technique is used frequently in the scala library itself. See for example the package statement in s.c.i.HashSet:
package scala
package collection
package immutable
Related
I am developing a package for Flutter Apps
There are methods and classes that are useful only for the package itself, and not for the programmer who will import my package, is possible to hide this methods and classes for further implementation?
Example:
DataService.dart
export class DataService{
//Must be visible only for my library
static notifyDataChanged(InternalEvent internalEvent){ ... }
//Must be visible for anyone
static addCallbackOnDataChange(onDataChangeCallback) { ... }
}
InternalEvent.dart
//Must be visible only for my library as well
export class InternalEvent {
...
}
The usual approach to having package-only declarations is to put them in a library in the lib/src/ directory, and not export that library. The other libraries in the package can import the package-only library, but users outside the package are discouraged from importing libraries in lib/src/ directly. (It's not impossible, just something that's discouraged because the package is free to change those libraries without warning).
If the package-only features require access to library private parts of public classes, then they need to be in the same library. The traditional way is then to declare both in a library in lib/src/ and export only the parts of that library which needs to be public:
library myPackage;
export "src/allDeclarations.dart" hide Private, Declarations;
// or, preferably,
export "src/allDeclarations.dart" show Public, Things;
Generally you should only put exported and non-exported declarations in the same library if absolutely necessary. Otherwise the hide/show lists become too cumbersome and it's to easy to forget a declaration in a hide list.
You have a few possibilities:
Making a method/variable private, by prefixing it with _:
class _InternalEvent {}
Use the hide/show directives:
// lib/src/event.dart
class InternalEvent {}
class VisibleEvent {}
// lib/my_package.dart
export 'src/event.dart' hide InternalEvent;
OR
export 'src/event.dart' show VisibleEvent;
For package-private members exists an annotation, #internal.
Using #internal the analyzer emit a warning when:
you export the annotated element (from a file under lib)
a consumer of your package imports the annotated element
Anyway, Dart seems to me to make things really complicated. The need to have members who are neither completely public nor inaccessible from outside the file is elementary, yet no solution provides certainties.
Note that:
the doc says to keep the package-private elements in files under lib/src, yet the consumers of your package will still be able to import them, without even the analyzer producing a warning; it's just a convection;
using the #internal annotation, the analyzer (ie the ide, which rely on the analyzer) produces a warning, but nothing prevents you from compiling the code anyway. The situation improves a little if you increase the severity level of the warning produced by the analyzer when the annotation is not respected. To do this, you need to create an analysis_options.dart file like the following:
analyzer:
errors:
invalid_use_of_internal_member: error #possible values: ignore, info, warning, error
Note that the #internal annotation, like other similar ones (#visibleForTesting, #protected) is part of the meta package, which is included in the Flutter Sdk, but which must be included as a dependency in pure-dart packages.
its so simple
suppose i have a below code in src folder of your lib,
class myClass1 {}
class myClass2 {}
class myClass3 {}
below export statement will make all 3 classes visible/accesible
export 'src/mylib_base.dart' ;
below export statement will make myClass3 visible/accessible and remaining not accessible
export 'src/mylib_base.dart' show myClass3 ;
below export statement will make myClass3 not visible/accessible and remaining accessible
export 'src/mylib_base.dart' hide myClass3 ;
So simply
with hide classes/function ,hide those that you mention and remaining will be shown to end user
with show classes/function ,show those that you mention and remaining will be hide to end user
I want to make a helper class at the root of my core project using play-json from typesafe, something like
package com.company
import play.api.libs.json.JsValue
object Helper {
implicit class RichJson(json: JsValue) {
def doStuff() //...
}
}
The problem is that I have somewhere else in the project a package com.company.play
package com.company.play
class Foo() { //...
}
In IntelliJ IDEA 2018.2.4 CE, the line import play.api.libs.json.JsValue is in error with telling me "cannot resolve symbol api" and when Ctrl+Click on the play it goes to the folder containing my Foo.scala file
If I compile the solution with sbt outside of IDEA, there is no problem.
If I put the Helper object in a subpackage (eg com.company.common) there is no error (which also means the dependency is correct in my build.sbt)
I don't understand why IDEA miss this, com.company.play isn't even in the dependencies of the core project. I already tried to invalidate cache, and it doesn't help.
The problem is that Intellij gives precedence to the package play into your project, instead of the package coming from the framework, when resolving the import of JsValue inside com.company scope.
If you really want to keep that name for com.company.play, there is a simple workaround using a fully-qualified import, just prefix like this:
import _root_.play.api.libs.json.JsValue
For example, I have two files called file1.swift and file2.swift.
file1.swift:
import UIKit
class A: B {
}
file2.swift:
import UIKit
class C: A{
}
I am reading that public class can not subclassed outside of module. Here I have subclass C. I am trying to understand what does module mean here. I imported to same module UIKit for both file. So the both files are of same module? So that I can subclassed. Or both files have different module even I import the same UIKit?
Can anybody explain what is module?
Source:
Classes with public access, or any more restrictive access level, can be subclassed only within the module where they’re defined.
Class members with public access, or any more restrictive access level, can be overridden by subclasses only within the module where they’re defined.
A module is a single unit of code distribution—a framework or application that is built and shipped as a single unit and that can be imported by another module with Swift’s import keyword.
Each build target (such as an app bundle or framework) in Xcode is treated as a separate module in Swift. If you group together aspects of your app’s code as a stand-alone framework—perhaps to encapsulate and reuse that code across multiple applications—then everything you define within that framework will be part of a separate module when it’s imported and used within an app, or when it’s used within another framework.
As the docs indicate, the module is an application or a framework (library). If you create a project with classes A and B, they are part of the same module. Any other class in the same project can inherit from those classes. If you however import that project to another project, classes from that another project won't be able to subclass A nor B. For that you would have to add open indicator before their declarations.
Basically, if you work on a single app then you are working in one single module and unless declared as private or fileprivate, the classes can subclass each other.
EDIT
Let us have following class in module (project) Module1:
class A {
}
Since this class is not open, it can be subclassed only within the same module. That means that following class:
class B: A {
}
Can be written only in the same project, in Module1.
If you add Module1 as a dependency to project Module2, and try to do this:
import Module1
class C: A {
}
It will not compile. That's because class A is not open (in other words it has access public or less) and it does not belong to the same module as C. A belongs to Module1, C belongs to Module2.
Note
import keyword imports a dependency module to your current module. If you write import UIKit in your project, you are telling the compiler that you want to use module UIKit in your module. import does not define current module. Current module is the current project.
Adding import UIKit at the beginning of the file does not change nor define to which module the file belongs. It just tells the compiler that in that file you want to use code from UIKit module.
Swift module(.swiftmodule)
History:
[#include -> #import] -> [Precompiled Headers .pch] -> [#import Module(ObjC);] -> import Module(Swift)
There are two type of Module - folder and file
.swiftmodule folder. Folder contains all .swiftmodule files for architectures and other meta information like:
.swiftmodule file. It is binary file format which contains Abstract Syntax Tree(AST) or Swift Intermediate Language(SIL) of framework's public API.
.swiftdoc - attached docs which can be revived by consumer
.swiftinterface - Module stability
[.swiftinterface or Swift Module Interfaces] is a next step of improving closed source compatibility
When you Jump to Definition of imported module actually you reviewing public interface of .modulemap
Binary(library, framework) can contains several modules, each module can contains a kind of submodule(from Objective-C world) thought.
import struct SomeModule.SomeStruct
These modules can have dependencies between each others.
Module is a set of source files which solves the same problem that is why they can be grouped under the same model name.
Module helps to group sources to reuse them
Module helps Xcode to minimize build time(open source)(If module was not changed it should not been recompiled)
Also Module is a kind of scope which can help compiler to figure out which exactly class to use. If two modules use the same name you get
Ambiguous use of 'foo()'
It can be solved by:
import ModuleName1
import ModuleName2
func someFunc() {
ModuleName1.SomeClass.foo()
ModuleName2.SomeClass.foo()
}
I have a course project that is a refactor of Game of Life in Scala. It's a
simple pure Scala + SBT project. One of my tasks is to extract the game logic
from GameEngine class and make easier to add new rules, as Conway, Highlife or
anything like that. I turned GameEngine into an abstract class and made all
classes that inherit from it implement methods to decide when cells should die or
reborn. When my game is starting, I have this code:
def addGameMode(gameMode:GameEngine) {
modes += gameMode
}
addGameMode(ConwayEngine)
addGameMode(EasyMode)
addGameMode(HighLife)
addGameMode(Seeds)
And my classes that depends on the GameEngine rule receives it as a
construct parameter. When I need to change the game rule, I use an setter method, like
the code below:
class GameView( var gameEngine: GameEngine, modes: MutableList[GameEngine] ) extends JFXApp {
...
def setGameEngine(g: GameEngine) {
gameEngine = g
}
...
}
I don't know if this approach is correct but, from what I learned, the dependency
injection is correct. But, for my teacher, it isn't. And there my problems began.
According to him, the dependency should be declared in a .xml file and treated by
an external lib. He recommended Spring but I don't know how I should implement
the dependency injection in simple Scala + SBT project using a web framework.
Hopefully, I can ignore this recommendation to use Spring and use another lib.
I found MacWire but I don't know how to use it
to solve this problem. Can someone help me?
Enumeration code looks like the following
package com.mydomain
object Market extends Enumeration {
type Market = Value
val ASX, LSE = Value
}
I try to use as follows
import com.mydomain.Market._
.
.
.
if (Market.ASX == currentMarket) {
...
}
This was working when everything was in the same package. When I moved to a new package I now get
not found: value Market
If you import Market, you have ASX and LSE directly available to you. You don't have Market.ASX available--that would be if you had object Market available, which is what would happen if you did import com.mydomain._.
Being inside package com.mydomain causes com.mydomain._ to be loaded just like you imported it, so that's why you can say Market.ASX when you're in the same package.
When you write code in a different package, you need to either import com.mydomain._ and then use Market.ASX, or import com.mydomain.Market._ and then use ASX.