I´m Implementing "The Clean Architecture" in my Project.
I´m Using scala as my langauge.
Now I´m dealing with following question:
Should my "Core" ( Use Cases / Entities ) be library Independent, so just plain ( In my case Scala ) code or would you say, that I could, if I wantet use librarys for example the effect library "ZIO"?
Or would It depend on the library?
In Clean Architecture the "core" should be as independent from external libraries as possible.
Some libraries cannot be avoided (you want to use collections and other types from the "base libraries" of your development platform) but every library you use in the "core" you effectively "marry" which means it will be super hard or even impossible to get rid of it or replace it later on in the lifetime of your project.
So it has to be a careful and conscious decision to use a library in the "core" of your application.
Related
VPP provides the I/S for developing custom plugins that can be hooked into a graph of nodes. I've only seen examples for such plugins written in the C language, and was wondering whether other language, Go for instance, can also be used to write such plugins.
I have no idea what "VPP" is but nonetheless the answer is: "maybe"; here's why:
Go code is able to interface with C libraries via its facility known as cgo.
cgo is a multiple-faceted thing: it allows you to "export" certain Go functions in a certain way so that they can be called from the C side, and it allows you to call functions from the C side. It also allows you to write bits of inline C code to provide glue for the C side, when necessary.
Since some time Go building toolset (at least its "reference" implementation) provides for compiling Go code into a static or dynamic library with C-compatible API.
See this.
With these things in mind, in theory, it should be possible to do what you're after.
Note some possible obstacles:
Most of the time, if a "platform" allows you to write a "plugin" in C, it presupposes your plugin will make extensive use of the platform's own API.
This usually means your plugin is supposed to include certain header files provided by the platform.
The platform might also require your plugin to link against some platform-provided library (usually shared), or libraries.
cgo can do all of the above, but you will need to scrutinize the API provided by the platform and maybe write Go helpers to make its usage more natural for the Go code.
Building/linking issues (usually the locations of the header files and the libs) may also be a thing to solve.
In VHDL, I am getting an error that library "work" does not contain primary unit "clock_div".Library being used is "use work.clock_div.all;".
Have you compiled "clock_div" into the working library?
N.B "Work" should not be a real library, it refers to the library you're compiling the current module into.
So if you're working on an entity that you're compiling into a library called "components", and "clk_div" is already in that library, then use work.clock_div.all; and use cmoponents.clk_div.all; are equivalent.
However when you later build the top level design, without specifying a library, use work.clock_div.all; won't find "clk_div" because you're not working in the components library, while use components.clk_div.all; will.
Are there any drawbacks of splitting up a Swift project into several frameworks? In my current application I don't need to do this but it would logically separate the different parts of my code so I intended to put the code into multiple frameworks (embedded binaries). However, I don't know if Swift's apparently awesome feature 'Whole Module Optimization' is affected by creating several modules.
Furthermore, are there any other drawbacks of using frameworks or performance upsides?
Thanks for your clarifications ;)
One thing I know is that with framework, you can reduce compiling time. Because you can compile your stable framework and reuse it. Then xcode only compile your main project.
The drawback (in my opinion) is that you have to import framework whenever you use it.
I am trying creating a library of components that I can use in Vivado(2014.2). I have many .vhd files and I would like to add more in the future, and so I'd prefer not to have to condense them
all into a single .vhd.
I may need to use a package...
ie.
--File name: my_library_file
package my_lib_package is
--All component declarations...
end package my_lib_package;
But would all the entities and architectures also need to be in this file?
Then I could use a "use" statement to reference these elements.
ie. use my_lib.
But would the my_library_file need to be located in the same project?
I would like to be able to make this library once and be able to reference in
any project with a call.
Ideally it could be called like an IEEE library but with many vhd files being referenced.
I would prefer not to explicitly add/include these individual source files to the project, but would instead prefer to just be able to use the “use” clause with library and/or package…if possible.
Hayden - your approach to making your own package of components sounds fine. We use the same approach with a single package file of "comps". It is written as a package and has the component instance as well as the entity and architecture of each component. Look at any of the Xilinx or Altera library source files as a guide.
You can compile it into it's own library and call it just like you do with the Xilinx libraries in Vivado.
I understand for non-iOS targets, using shared libraries can lead to lower memory usage, and also that some companies distribute a library and headers (like Superpin) and a static library allows them to not distribute the source of their product. But outside of those, what are the reasons you'd want to use a static library? I use git for all of my projects, and I usually add external libraries (open source ones) as a submodule. This means they take up disk space locally, but they do not clutter up the repo. Also since iOS doesn't support shared libraries, the benefits of building libraries to promote code reuse seems diminished.
Basically, is there any reason outside of selling closed source libraries that it makes sense to build/use static libraries for iOS?
organization, reuse, and easy integration into other programs.
if you have a library which is used by multiple apps or targets multiple platforms, then you will have to maintain the build for each app. with a library, you let the library maintainer set up the build correctly, then you just link to the result (if it's developed internally, then you'll want to add it as a dependency too).
it's like DRY, but for projects.
libraries become more useful as projects become more complex. you should try to identify what programs (functions, class hierarchies, etc) are reusable outside of your app's context, and put it in a library for easy reuse - like pattern recognition.
once your codebase has hundreds or thousands of files, you will want to minimize what you use, and you will not want to maintain the dependencies manually for each project.
Also since iOS doesn't support shared
libraries, the benefits of building
libraries to promote code reuse seems
diminished.
There's no reason you can't build your own static library to use across multiple projects.
Other than for that purpose and the ones you mentioned I don't think there's much else.
Static libraries allow you to have truly standalone executables. Since all library code is actually, physically present in the executable, you don't have to worry about the exec failing to run because there's a too-old version of some library, or a too-new one, or it's completely missing, etc. And you don't have to worry about your app suddenly breaking because some library got replaced. It cuts down on dependencies and lets your app be more encapsulated.