Is it possible to extend (or even override) standard library modules. I'd like to be able to do something like
-- eggs.lua
table.spam = function(tab)
return tab[1]
end
and then
-- ham.lua
require('eggs')
table.spam({2,7,1,3})
Yes, it's possible, although the recommendation would be not to modify the standard library namespace, but use tablex instead as some libraries do.
Related
I'm very new to elixir so this is probably basic but couldn't see much online
if I have the following code
defmodule A do
def my_first_function do
# does stuff
end
end
defmodule B do
#my_module_attribute A.my_first_function()
end
then how do I mock module A in my tests so I can just tell the tests what I want it to return?
also is it possible to just mock #my_module_attribute instead? would be good to have an answer to both approaches (and then what is considered the better pattern)
I think perhaps you are wanting to use module attributes for more than what they are useful for, and perhaps there is some confusion over the exact definition of "mock".
Avoid thinking of module attributes as "class variables" -- even though they look like they might serve the same purpose and they are in the same place, their behavior is different. Be especially careful when a module attribute relies on a function call. One common pitfall is to use module attributes to store values read from configuration, e.g. using Application.fetch_env!/2. The problem is that the module attributes are evaluated at compile time (not at run time), so you can easily end up with an unexpected value. (The compiler now warns about this gotcha explicitly and there is now the Application.compile_env!/2 provided to better communicate that particular use case).
I usually reserve module attributes for raising the visibility of simple constants and I tend to avoid using them for storing the result of any function execution.
When it comes back down to "mocking", you still have to think about the fact that Elixir is compiled -- it's not Javascript. Someone geekier than me can explain the mechanics, but the module attributes don't exist the same way at runtime as they do at compile time.
"Mocking" during tests usually means substituting one module or function for another, and this swap is often easier to do at runtime. One common pattern looks a bit like Dependency Injection (but purists may object to the comparison).
Consider a function like this that relies on some OtherModule to do its work:
def my_function(input, opts \\ []) do
other_module = Keyword.get(opts, :service, OtherModule)
other_module.get_thing(input)
# do more stuff...
end
Instead of hard-coding the OtherModule inside of my_function, its name is read out of the optional opts. This provides a useful way to override the output of that OtherModule when you need to test it.
In your test, you can do something like this:
test "example mock" do
assert something = MyApp.MyMod.my_function("foo", service: MockService)
end
When the test provides MockService as the :service module, the get_thing function will be called on the MockService module and not on the OtherModule. If the provided module does not define a get_thing function, the code will fail to execute. This is where having a behaviour comes in handy because it helps guarantee that your module has implemented the needed functions. The Mox testing library, for example, relies on the behaviour contracts, but from the example above you can see premise.
If you squint, you can see that this "injection" approach is somewhat similar to how Javascript often accepts a callback function as an argument, but in Elixir it is more common to pass around module names instead of captured functions.
I'm new to CMake and trying to learn to use it for a simple project. If I have a CMakeLists.txt file that looks like this:
add_executable(alpha alpha.cpp)
add_executable(beta beta.cpp)
add_library(one STATIC one.cpp)
add_library(two STATIC two.cpp)
target_link_libraries(alpha one)
target_link_libraries(alpha two)
target_link_libraries(beta one)
target_link_libraries(beta two)
Is there a way to simplify this sort of pattern? What I would like is to define something like all_libraries that contains both one and two, and then only have to do one linking per binary. Is there a way to do it?
You can use interface libraries:
add_library(all_libraries INTERFACE)
target_link_libraries(all_libraries
INTERFACE
one
two
)
... then later ...
target_link_libaries(alpha PUBLIC all_libraries)
You can use variable:
set(all_libraries one two)
.. then later ..
target_link_libraries(alpha PUBLIC ${all_libraries})
Notes:
I would advise to always explicit specify the the PUBLIC, PRIVATE and INTERFACE keywords.
I would go with interface libraries. It's nice to have a big project, expose different mix of libraries as a single interface library, than you only link another big project against that interface. Gives nice control and look of it.
In Node.js, I could get an array of the objects in foo with
Object.keys(require("foo"));
Is there any way I could do the same thing in Rust?
mod foo;
getobjs(foo);
No, there is no way to do this. This level of introspection of compile-time information simply doesn't exist at runtime. The concept of a module doesn't even exist.
If you are interested in compile-time information, you can do such things as build and view the docs (cargo doc --open) to see all the public items of the entire crate. You can probably also view the crate's documentation online before you use it.
There are also tools like the Rust Language Server which provide this type of information (and more) to editors and IDEs.
Is it possible to use a constant defined by the compiler in code like below?
#If DEALER_DEBUG = "ID12345" Then
If(Dealer.ID = DEALER_DEBUG) Then
'Do something
End If
#End If
I'm running batch processes and I'm experiencing problems with one of my customer's data. I want to add special code for only that customer, but I want to keep the code there so I can easily switch the customer ID in the future should i need to debug a different customer.
The source-code of the compiled dll will then look like this:
If(Dealer.ID = "ID12345") Then
'Do something
End If
No. Compiler directives are just that, directives to the compiler. They are not included in the generated IL code, and so cannot be accessed at runtime.
You can use it in the compile time #If, but you can't use it in the runtime If
You can define your custom compiler constants in the project properties under Compile->Advanced Compile Options->Custom Constants, or alternately by using a #Const directive.
There are many better ways to do this. I don't know much about what exactly you are attempting to accomplish, but you might want to consider some sort of factory pattern + plugins + config that allows you to provide a plugin assembly to that client which can allow for extra functionality. It is arguably a lot more work to create an extensible app, but if you find yourself needing to do these kinds of things, its much better to write it to be extensible from the start than have to go back and refactor later.
I am wondering why Qt uses Q before every class name rather than putting everything in a namespace. Is there any particular reason, such as making the names easy to search for, or is it just about brand names?
I believe it is historical. Namespaces were introduced into C++ around 1995. Qt development started in 1991 so namespaces could not be used, obviously.
It may be a portability issue. Namespaces weren't / aren't supported by every compiler, so the naming convention helps to cut down on naming clashes.
The documentation for Qt refers to namespaces, although I didn't check the code to see if they are truly c++ namespaces or a hack with public declarations inside a class. I would guess that the rest is trying to avoid causing everybody to need to rename everything, although they could provide a migration path if they wanted to, like so:
namespace Qt
{
class Object { ... };
}
#ifndef NO_OLD_DECLS
typedef Qt::Object QObject;
#endif
Qt is very conservative on the C++ language features it uses. No namespaces, exceptions or RTTI. See also this article detailing why templates are not used in signal/slot handling.
Seeing as there's not a single C++ compiler left that doesn't implement namespaces, nowadays there's only one reason: Branding :)
Qt uses a Q prefix as part of their coding style. It usually serves the purpose of making it easier to read the code and spot what is what.
An identifier that:
is prefixed with "Q" and suffixed with "Private" is a private class used for implementation details and is not part of the API (e.g. QPainterPrivate)
is prefixed with "Q" and not suffixed with "Private" is a public class (e.g. QWidget)
is prefixed with "q" (lowercase) is a public global function (e.g. qRgb)
Adopting a coding style and using it uniformly makes it much easier for other people to understand code they didn't write.
Ref.: Qt Coding Style