If I have a package hierarchy in Scala like this:
package toplevel {
package a {
// some interesting stuff
}
package b {
// more interesting stuff
}
package utility {
// stuff that should not be accessible from the outside
// and is not logically related to the project,
// basically some helper objects
}
}
how can I forbid the users of package toplevel to see or import package utility?
I tried with private[toplevel] package utility { ... but got this error: expected start of definition.
I've searched for this and was overwhelmed by false positives: everything I got was about making things package-private and this is not my question.
You can't: packages don't have access levels.
Or rather, you can, by using OSGi and not exporting them, but this is a very heavy-weight solution if you don't need it for some other reason as well.
To reach the same goal as private packages in Java you can use augmented access modifiers. Inside your package utility you restrict access with private[utility]. This way the package member is available only inside the package utility itself.
Hope that helps.
You can only define the enclosing package, within which the code is defined
Answered here.
Related
#import "whatever.h"
...wasn't perfect, but it was very handy for diagnosing circular dependencies, not to mention enforcing modularity.
You could be certain which classes knew about other classes--with the flick of a finger.
If you had to, you could comment out all the import statements, and add them back one at a time, in order to diagnose a dependency issue. It wasn't necessarily fast but it was dead simple.
And if a class didn't import anything other than the obligatory headers, Son, that's one modular class you had there!
If your project had ten classes that didn't import anything, then you knew that they were ten modular classes--you didn't have to package each class into its own Framework or anything like that. Easy.
But now, with Swift's policy of "everybody knows about everything all the time", it seems like it's just down to personal vigilance to sustain modularity. Personal vigilance is the worst kind!
Am I missing something? Is there a way to do these things easily in Swift?
If you want to modularize your Swift code, you should be using modules!
Creating a new module is pretty simple.
Add a new target to your project by clicking the plus sign here:
Select "Framework & Library" for the appropriate platform (iOS/OS X):
Choose "Cocoa Framework" (or Cocoa Touch, platform dependent) and click Next:
Give your module a name and change the language to Swift (or leave it as Objective-C, it doesn't matter, you can use both).
Add a Swift file to your module:
Add some code to your Swift file. Note, the default access level for Swift is internal which means it can be accessed from anywhere within the module but not from outside the module. Any code which we want to use outside the module must be given the public access level.
public class ModularSwift {
public init(){}
public var foo: Int = 0
}
Be sure to build your module (Cmd+B):
Go back to your original target, import the module and start using its code:
import MyModularSwiftCode
let foo = ModularSwift()
Xcode is perfectly happy:
Now, comment out the import statement and notice the errors:
You define the packages your package is dependent on in the smart.json for example like this:
{
[...],
"packages": {
"package1": {},
"package2": {}
}
}
This means my package is dependent on package1 AND package2. Is it possible to declare my package dependent on package1 OR package2?
No, I would be highly suprised if there were such a way to include packages. If you really want to be dependent on one of two packages you are going to have to implement that in your package code (you would be dependant on both packages and your logic would have to choose which package to use).
The next best thing I can think of is editing the package.js file which allows you to create a weak dependency:
It is possible to create weak dependencies between packages. If
package A has a weak dependency on package B, it means that including
A in an app does not force B to be included too — but, if B is
included, say by the app developer or by another package, then B will
load before A. You can use this to make packages that optionally
integrate with or enhance other packages if those packages are
present. To create a weak dependency, pass {weak: true} as the third
argument to api.use. When you weakly depend on a package you don't see
its exports. You can detect if the possibly-present weakly-depended-on
package is there by seeing if Package.foo exists, and get its exports
from the same place.
Maybe there is an alternative soulution, care to elaborate why you want your package dependecies to be like this?
I have the same problem with one of packages I have developed. what I did was simply NOT indicating any dependancy in the smart.json file and let the user decide which package he/she wants to use, and I have mentioned it clearly on package's getting started guide.
in my case it is a bootstrap3 package I wanted
So I understand that the special UNIVERSAL class is to be considered the base class from which all other objects are created. So if a specific method is not found after Perl traverses the inheritance hierarchy, it will look in the UNIVERSAL class to see if the method can be found there. However, when you create a distribution, no UNIVERSAL.pm package is created. Also, the UNIVERSAL methods 'DOES' and 'can' already exist without a UNIVERSAL.pm... As such, I am not sure if I should be writing UNIVERSAL methods into random packages like so:
sub UNIVERSAL::nicemethod{
launch_teh_missles();
}
Or should I be creating a separate UNIVERSAL package and .pm file? What is considered best practice?
You can add new methods to UNIVERSAL the same way as to any other package:
package
UNIVERSAL; # Line break to fool CPAN indexer
sub nice_method {
...
}
I'd like to import package com.example.abc from com.example.iop in similar manner to bash expression ../abc.
Is this possible in Scala? I've read couple of articles but they say nothing about my case.
Update: I've discovered code suitable for simple uses (I've seen it in some project while ago):
package com.example
package com.example.abc
import iop
Your updated package structure has a hint of the solution, but isn't quite right. You can live in multiple packages, including a broad parent package defined by the first package statement – subsequent statements refine the tree.
package com.foo // we're in: com.foo
package bar // we're also in: com.foo.bar
package wibble // we're also in: com.foo.bar.wibble
import frobble._ // this could be com.foo.frobble or com.foo.bar.frobble or com.foo.bar.wibble.frobble
Obviously, things can get confusing if you have multiple packages with the same name, but the compiler asks you politely to sort that out.
That is simply not possible -- same as in Java.
If a user imports:
com.my.package
Is it possible for me to do something in my package, so that another package gets imported as well? For example, I'd like to have java.io be automatically imported.
No, it is not possible. However, you can create a package object and put type definitions in it, so that you'll get aliases for classes you think are relevant.