In Java I used to put classes inside packages with long informative names by template domain.company.project.module.ets and used to names like:
ch.qos.logback.classic.net
org.hibernate.cache
com.google.common.collect
But in the sources of akka and sbt projects there are a lot of classes inside packages with simple names:
akka.actor
sbt
And that's not all. There are many classes inside classes. And by classes I also mean objects and traits in all possible combinations. There are object inside traits, traits inside classes, etc. But the level of nesting is always 1 (or should I say 2?).
Obviously, there is another approach to class organization. I wonder if you can give me a tip of how to name packages in scala and when to put classes inside each other?
Hi I will reccomend you to read chater seven of scala for the imatient is free available here: http://typesafe.com/resources/free-books.
As a summary the keypoints, as sayed in the book:
- Packages nest just like inner classes.
- Package paths are not absolute.
- A chain x.y.z in a package clause leaves the intermediate packages x and x.y invisible.
- Package statements without braces at the top of the file extend to the entire file.
- A package object can hold functions and variables.
- Import statements can import packages, classes, and objects.
- Import statements can be anywhere.
- Import statements can rename and hide members.
- java.lang, scala, and Predef are always imported.
Related
Usually I create a "Scala Object" that keeps all my global constants.
I have been told that it is better to use "package object" in order to keep constants.
I have never used "package object" previously so my questions are:
What are the best practices to hold constants in Scala and why?
Why do I need "package object"?
You dont need a package object.
However it allows you to make code available at the package level without declaring another class or object.
It's a convenience.
package foo.bar
package object dem {
// things here will be available in `foo.bar` package and all subpackages
// without the need of an import statement.
}
The only convention specified for constants are regarding casing. Constants should be PascalCased
Keep in mind that declaring constants in the package object might make them available in places where you don't want them to be available.
I leave you the naming convention for package objects:
The standard naming convention is to place the definition above in a file named package.scala that's located in the directory corresponding to package pp.
We have a third party less file in our project - say foo.less. foo.less will be compiled to foo.css.
foo.less
foo.css
-- team1.less
-- team1.css
-- team2.less
-- team2.css
team1.less and team2.less both import foo.less.
Team1 has a reference to foo.css and team1.css
on their web pages while
Team2 has a reference to foo.css and team2.css.
How can I get team1.css and team2.css to exclude foo.css in their respective compiled output? What is occurring right now is team1.css and team2.css both have foo.css in them (repetition of css code).
Edit:
team1.less and team2.less imports foo.less to take advantage of a lot of variables and mixins.
Now Available in LESS 1.5
You can import foo.less as a reference, like so:
#import (reference) "foo.less";
The code will be available for referencing variables, mixins, etc., but will not compile to css output.
My question to you is, why are you importing foo.less if you do not want it to be included? If it's because you are using variables or mixins from foo.less, than you could separate those out into a separate less file, and import that instead. That way there would not be any duplicate css. This is good practice in general, that way you can reuse any variables/mixins without importing a bunch of css.
I'm a relative newbie to SystemVerilog.
I have a package with class A defined in it. This class uses a virtual interface, since
it's a driver (BFM) in a testbench. I'm using a package so I can use the same BFM in
other designs.
In my testbench, I import the A class and pass to it an instance of the virtual interface.
However, when a task in the class tries to assign a value to a signal in the interface, I'm getting a compilation error.
What am I doing wrong?
How can one package a BFM with a virtual interface?
Thanks,
Ran
SystemVerilog packages cannot include interfaces within the actual package. So your interface needs to be compiled along with you package source. The classes you define will reside in the package while the interface definition resides in the global scope where modules live.
Classes within packages can make references to virtual interfaces, but you need to make sure the interface is compiled and visible, apart from the package source.
Strictly according to the spec, I don't think this is possible since it adds an implicit external dependency:
Items within packages are generally type definitions, tasks, and
functions. Items within packages shall not have hierarchical
references to identifiers except those created within the package or
made visible by import of another package. A package shall not refer
to items defined in the compilation unit scope.
It doesn't say anything about the design element namespace, which is where interface declarations live, but accessing any member of an interface requires a hierarchical reference.
You should consider packages to be completely self-contained, other than pre-processor directives and import.
Generally the class declaration not present before its usage is resolved with the help of systemverilog typedef definition. For example "Class A uses Class B" and "Class B uses class A" then typedef is used to resolve the stalemate.
Now when you bring in the package with the above scenario then one needs to ensure both Class A and Class B have to be in same package. If they are not then the compile wont go through.
The reason being the SystemVerilog parser will need the definition of the classes indicated with the typedef at the end of the package parsing. This fails.
This issue needs to watched out that "typedef does not apply across package".
I have some code for solving a puzzle game called nurikabe, recently I've been rewriting it to OOP (still learning) and have the following structure:
# CNurikabe.py
from includes import Board, Validation, Heuristics
class CNurikabe(object):
...
# CValidation.py
from includes import Board, Heuristics
class CValidation(object):
...
# CHeuristics.py
from includes import Board
class CHeuristics(object):
...
# CBoard.py
class CBoard(object):
def __init__(self, filename):
# Vars shared by every class
self.x, self.y, self.z, self.t = self.parseData(filename)
# run.py
from CNurikabe import CNurikabe
nurikabe = CNurikabe()
nurikabe.solve('output')
# includes.py
from CBoard import CBoard
Board = CBoard('data.dat')
from CHeuristics import CHeuristics
Heuristics = CHeuristics()
from CValidation import CValidation
Validation = CValidation()
CBoard class has info which has to be shared among all the other classes (such as board dimensions, number coordinates, etc), also I want it to be instantiated once, if possible preventing dependency injection (unnecessarily passing the filename to each class init method, for example)
The classes are needed to access the following:
CValidation class use: CBoard and CHeuristics
CHeuristics class use: CBoard
CNurikabe class use: CBoard, CValidation and CHeuristics
The code I have, works just as expected. I can call other class' methods within the other classes just the way I want it, for example:
# CNurikabe.py:
class CNurikabe(object):
def someFunc(self):
for i in range(Board.dimensionx):
Heuristics.doSomeStuff()
Validation.doSomeMore()
But I've read maybe too much about how globals are evil. Also the code inside includes.py is a bit hackish, because if I change the order of the imports the program won't run, complaining about being unable to import some names.
I also tried another way, only instantiating globally the CBoard class and then, for the other classes, creating an instance of the classes I need. But I felt that was kinda repetitive, creating an unique global instance of CHeuristics inside each class, for example, and that still wouldn't solve the CBoard global problem.
I also thought about creating an instance inside each class's init, but then the code would be very verbose, having to call for example: self.Heuristics.doSomeStuff()
So my question is what would be a better approach to structure this? I've read about singleton patterns (which may be overkill, since it's a small project), and endless ways of doing it for multiple languages like C++ and PHP. Actually The way I'm doing it resembles that of the "extern Class instance;" way of doing it in C++, long time ago I was working on a C++ project that had that style and I liked it, didn't see any problems with it, although the class instances were global.
Globals are evil. However, you probably need a singleton pattern that encapsulate some things together. My experience from C++ and Python is that you can nicely use the hybrid character of the language and use a module in the role of singleton. (If you think more about it, module variables play the role of a singleton member variables, plain functions in the module resemble methods of a singleton.)
This way I suggest to put the board functionality into board.py heuristic functionality into heuristic.py,..., convert the methods to functions, self.variable to variable and use:
import board
import heuristic
import validation
...
class CNurikabe: # the explicit (object) base class is not needed in Python 3
def someFunc(self):
for i in range(board.dimensionx):
heuristics.doSomeStuff()
validation.doSomeMore()
Think about the import board as about getting the reference to the singleton instance -- which actually is, because there is a single instance of the module object. And it will be syntactically the same as your older code -- except getting the instance (the module) will be easier.
Update: Once you need more instances, you should think in classes again. However, passing objects is very cheap operation in Python -- you only copy reference values (technically the address, i.e. 4 or 8 bytes). Once you get the reference value, you can easily assign it to a local variable. (Every assignment in Python means copying the reference value, hence sharing the access to the assigned object. This way, there is actually no need for global variables, and no excuse to use global variables.
Using local variables, the syntax again remains the same.
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.