I don't like the fact that in scala its not obvious what some of my imports are doing - imports for implicits so i'm trying to come up with good naming conventions for them so when i see in my import statements something like:
import com.mycomp.example.RectangleImplicits
or
import com.mycomp.example.RectanglePimper
I know i cant remove that import because its being used for pimping.
My problem with the above names is that sometimes I actually do an adapter, in that case
import com.mycomp.example.RectangleAdapter
does not say anyting about the fact that its actually a pimper however i don't want to name it RectangleAdapterPimp because the name becomes to combersome...
is there a golden bullet naming convention for that?
thanks
In std Scala library such classes are prefixed with Rich, like RichString, RichInt, etc... So why not to use RichRectangleAdapter
Related
I am a novice high school Java programmer and I am having an internal conflict as to which of the following methods is more efficient in Java. If you are importing a single class in Java, is it more efficient to import it as per usual, e.g., import java.util.Scanner; or to use that import statement as part of the Scanner's declaration, as in java.util.Scanner scan = new java.util.Scanner(System.in);.
I know the first is more common and looks nicer, but what if you only need one scanner object? I am sorry if this question is a duplicate; I did not know how to properly word this question in my searches to see if it already existed.
import statements create a compiler-time alias to the symbol imported. That is, it's just a shortcut for typing the full name out - it has no effect on the program while it's running. The compiled code is identical in both cases.
There is no added expense to importing a class, so it makes sense to put all of your imports in the header where anyone looking at your code can easily see what classes are utilized in the program. If you decide later that you want to have more than one scanner object or more than one class from java.util you can use import java.util.* as well.
Pick the more readable of the two. There is no difference in performance, at the end of the day they both get compiled to exactly the same bytecode.
The efficiency lies in how often you might need to write out the package/class/symbol path to the type. If you are certain that you will use it only once, not using an import would work.
But, that is the only upside. There are multiple downsides to avoiding an import statement, including readability, ease of seeing which classes are used in this code file, and extra typing if adding more references becomes necessary. The compiler is completely neutral in all of it, as source either way will compile to the same JVM code.
When you declare an import like this:
import com.microsoft.azure.storage.*;
Does that include everything in its subpackages too? For example, does it include this?
import com.microsoft.azure.storage.blob.*
If not, why not? (Edit: the "why" question is basically off topic. ignoring that bit when considering a correct answer.)
No it does not. It only imports everything in the package (i.e. the directory itself). Sub-directories are considered to be different packages, so you would need to:
import com.microsoft.azure.storage.*
import com.microsoft.azure.storage.blob.*
As to why the language designers chose to go this route, one can only guess, but the system that they decided to go with does allow for a more fine-grained approach.
yes you can import all the classes from an import but it does not make it possible to import multiple packages with similar names. For example import java.util*; does not also import java.util.prefs or .jar you have to import these all separately. I don't know if that answers your question, and to the why I am not really sure it just makes sense to do it this way. If you were to import similar packages that had the same static variables, but you only need two or three of the packages then you would get errors or code that does not run properly.
There's a name for these - type import on demand.
A type-import-on-demand declaration allows all accessible types of a named package or type to be imported as needed.
They're only also importing the package itself, and not any subpackages, as clarified by the example, emphasis mine:
import java.util.*;
causes the simple names of all public types declared in the package java.util to be available within the class and interface declarations of the compilation unit. Thus, the simple name Vector refers to the type Vector in the package java.util in all places in the compilation unit where that type declaration is not shadowed (§6.4.1) or obscured (§6.4.2).
does that include everything in / subdirectories too? including
something like this?
* stands for all the compilation units inside the package com.microsoft.azure.storage where sub packages are actually not compilation units and thus not fetched when you write myPack.*. Compilation unit includes class, interface, enum etc.
I'm talking about the import statements at the top.
Eg:
import java.util.Scanner;
import javax.swing.JFrame;
So, can I just say that:
Anything that starts with a lower-case letter (java, util, javax and swing here) is always a package and everything that begins with an uppercase is always a Class (which may be followed by an Inner class in some cases).
That's not necessarily true, as you can create classes starting with lowercase letters and packages starting with uppercase letters, but it is generally good practice to follow the Java coding conventions.
These dictate that what you said should be true.
If you look up Java naming conventions on the Oracle site, you will see that package names should, by convention, start with a lower-case letter and class names, method names, interface names, and others, should, by convention, start with an upper-case letter. This allows you and anyone who reads your code later to know what statements are imports of packages (although the import keyword makes it obvious) and where you have classes and methods. It also makes your code appear neater aiding readability. You could say that it allows your one's brain to compile what it is reading faster. For example, seeing a constant value in all caps like static final int MIN_WIDTH = 4; makes it much easier to understand what is going on.
I would like to point out that the information is relatively easy to find via google and there are other questions on Stackoverflow that would have the answer to your question. Please do your research in the future.
If the naming conventions have been followed and we are not talking about static imports, then what you say is true.
With static imports you can import constants and methods as well.
import static java.lang.Math.PI;
import static java.lang.Math.cos;
Tried to implement the example but I got the error in the title http://math.nist.gov/javanumerics/jama/doc/Jama/Matrix.html
I'm just wondering how do I write the import for it. I haven't found anything online. Thanks
In every Javadoc page, at the top, you have the name of the class, including its full path, which is what you should import.
For example, let's look at the well-known ArrayList class from the Java standard library. If you look at its Javadoc, you'll see:
java.lang.Object
java.util.AbstractCollection<E>
java.util.AbstractList<E>
java.util.ArrayList<E>
By looking at the last line, you know you have to import java.util.ArrayList (generic type designators are not included in the import).
So now look at the Javadoc you gave us. It's a bit confusing, because ironically, the National Institute of Standards and Technology is not using the proper language conventions (the name of the package should have been gov.nist.jama or something like that, certainly not something that begins with a capital letter).
Nevertheless, the Javadoc states:
java.lang.Object
└╴Jama.Matrix
So your import should be Jama.Matrix.
My question is very basic. I wanted to use the randomX in my java code.
jgap.sourceforge.net/javadoc/3.01/org/jgap/util/randomLEcuyer.html
sample code from here:
https://code.google.com/p/fractalproject/source/browse/FractalProject/src/org/dla/model/DlaModel.java?spec=svn40&r=40
I am already using another package, lets say MyProj, with other files of my current code.
I used the following lines,
package MyProj;
import org.jgap.util.randomLEcuyer
But eclipse does not recognize the randomLEcuyer. I appreciate if you help me.
First of all, you have two package declarations in your code:
package MyProj;
package org.dla.model;
This is invalid. Second, the class you want to use, as the javadoc you linked to indicates, is org.jgap.util.randomLEcuyer, and not org.rda.dice.randomx.randomLEcuyer.
Finally, I would be careful in using a class that doesn't even respect the basic Java naming conventions: classes should start with an upper-case letter.