Basically I want a module that can use functions that are outside its scope.
I need this because my work will only provide a framework where the user will be able to put its own code in. Something like this
Simulation.jl
abstract AbstractType
function startSimulation(unknown::AbstractType)
doStuff(unknown)
end
MyModule.jl
module MyModule
include("Simulation.jl")
export AbstractType, startSimulation
end
SomeImplementation.jl
type ConcreteType <: AbstractType
variable::Int64
end
doStuff(me::ConcreteType)
me.variable
end
and finally Main.jl
# push!(LOAD_PATH, pwd()) # for local usage
using MyModule
include("SomeImplementation.jl")
startSimulation(ConcreteType(5))
Where Simulation.jl and MyModule.jl are written by me and SomeImplementation.jl and Main.jl are written by the user.
Now the above example does not work, because modules have their own namespace and even tho SomeImplementation.jl is imported in main at line 3, the interpreter will not see it in line 4 of Simulation.jl.
I can not import anything in MyModule.jl, because I can not know how the user will name his stuff or what extra libs he might even need.
Is there are way to do this with modules? Otherwise I will just not use modules.
The answer here is to create stubs for all the functions you want to call within MyModule as a required interface for the custom subtypes of AbstractType. That is, within MyModule, you'd have:
abstract AbstractType
doStuff(::AbstractType) = error("custom AbstractType objects must define a `doStuff` method)
function startSimulation(unknown::AbstractType)
doStuff(unknown)
end
Then the concrete implementations just need to specifically add their doStuff method to the function in MyModule by importing it or qualifying it:
MyModule.doStuff(me::ConcreteType)
me.variable
end
Related
I am having a "weird" situation of my VB.Net modules, as per my understanding, Module in VB.Net means static class so I have implemented a couple of helper modules with couple of functions each, let's have some examples for better explanation (free hand code, may contains syntax problem):
Namespace Helpers
Module HelperA
Public Function FunctionA() As Boolean
Return True
End Function
End Module
End Namespace
Namespace Helpers
Module HelperB
Public Function FunctionB() As Integer
Return 1
End Function
End Module
End Namespace
When I start coding in Visual Studio and type Helpers., both FunctionA() and FunctionB() are show up in the recommended auto-complete dialog which I have not type HelperA or HelperB yet, I have some C#.Net projects with static class and I found such behavior does not apply to C#.Net static class.
It is weird to me and inconvenience since I am now having 50-ish functions under a single namespace, have done some Google but nothing could be find, could anyone suggest a solution (besides change Module to Class) or any keywords to search with?
Any help will be appreciate!
Module doesn't technically mean static class. Static in VB.net (with regard to functions) is Shared, and there is no Shared Class. What I think you want is a sealed/abstract/not-inheritable class with static/shared functions (you'll be able to call the functions without an instance of the parent class, but you'll still have to reference the parent class when calling the function). If that's the case, then do something similar to the following:
Public NotInheritable Class HelperA
Public Shared Function FunctionA() as Boolean
Return True
End Function
End Class
Having said that, the only difference I've found—at least for practical purposes—between a shared function and a module function is that module functions can be called without referencing the module.
I have few module namespace xquery files which were used in multiple files. I want to have the namespaces in one common xquery file and import that file whereever I want to use.
Say for example,
I have process-lib.xqy, util-lib.xqy and query-lib.xqy.
I used to import these in multiple files like following,
import module namespace util = "util" at "util-lib.xqy";
import module namespace process = "process" at "process-lib.xqy";
import module namespace query = "query" at "query-lib.xqy";
Now I tried to use them in one common file named as common-import.xqy and import this file in multiple files.
when I tried this approach,
import module namespace common-import= "common-import" at "common-import.xqy";
It throws exception as prefix util has no namespace binding.
How to achieve this?
This is not possible, at least not in the way you want to do it and rightfully so. The XQuery spec doesn't allow this:
Module imports are not transitive—that is, importing a module provides access only to function and variable declarations contained directly in the imported module. For example, if module A imports module B, and module B imports module C, module A does not have access to the functions and variables declared in module C.
This is a deliberate design decision. If you want to have access in this way you could write a wrapper function for each function you want to access, e.g. in your common-import.xqy file you could have:
declare function common-import:test() {
util:test()
};
But of course this can require a tremendous amount of wrapper functions. I would recommend you stick simply to inserting all required libraries. I see no benefit in doing otherwise.
I have a trivially small PHPUnit test that looks like this:
<?php
namespace VNN\PressboxBundle\Tests\Entity;
namespace VNN\PressboxBundle\Entity;
use VNN\PressboxBundle\Entity\User;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
use Phactory\Sql\Phactory;
class UserTest extends EntityTest
{
public function testCreate()
{
Phactory::reset();
}
}
When I try to run it, I get this:
There was 1 error:
1) VNN\PressboxBundle\Entity\UserTest::testCreate
ErrorException: Runtime Notice: Non-static method Phactory\Sql\Phactory::reset() should not be called statically, assuming $this from incompatible context in /Users/jason/Web/pressbox/src/VNN/PressboxBundle/Tests/Entity/UserTest.php line 13
What's up with that? All the docs call it statically.
I'm doing this on Symfony 2.0, if that makes a difference.
The documentation says you should be using the top-level Phactory class directly under lib/--not the individual implementations such as Phactory/Sql/Phactory which get instantiated based on the PDO object you pass to setConnection. Change
use Phactory\Sql\Phactory;
to
require_once 'Phactory/lib/Phactory.php';
The main class is in the global namespace and doesn't require a use statement.
https://github.com/chriskite/phactory/issues/30
From the code, setConnection, define and create are not static functions but the README and website guide do not reflect that.
e.g. test code
https://github.com/chriskite/phactory/blob/next/tests/Phactory/Sql/PhactoryTest.php
use Phactory\Sql\Phactory;
...
$this->pdo = new \PDO("sqlite:test.db");
$this->phactory = new Phactory($this->pdo);
$this->phactory->define('user');
$this->phactory->reset();
I don't know when it has been changed.
Too late anyways...
The current version, 0.3.2, is not backward compatible with the static method structure that is documented.
Here is the breaking commit: https://github.com/chriskite/phactory/commit/d3b60eeedea955ab7b5803ec29446d19888d3849
Unfortunately, the documentation has not been updated on http://phactory.org and the pearhub repo is no longer available.
I would look to the tests for examples: https://github.com/chriskite/phactory/blob/next/tests/Phactory/Sql/PhactoryTest.php
Currently, if I have different classes containing functions etc, I would structure them all in the 1 VB file titled whatever the main Class is. For example:
MainClass.vb:
Class MainClass
Function FunctionA() as String
...
End Function
Class SubClass
Function SubFunction() as String
....
End Function
Class SubSubClass
......
End Class
End Class
End Class
However, the problem with this is the file can become 1000s of lines long making hard to find portions of code.
Is there a way I can store SubClass in a file such as MainClass.SubClass.vb so that its easier to locate classes? Or is there a better, more standard, way of doing this?
At least C# understands "partial classes" where you can spread the code over multiple files (within the same assembly)
EDIT
I expected VB to have partial classes also (I only work in C# myself), but as noted in the comments, it does have them.
In C# I could code something like this:
File MainClass.cs:
public partial class MainClass // note the "partial" keyword
{
// some method declarations etc.
}
File MainClass.SubClass.cs:
public partial class MainClass // have to repeat this to hook up correctly
// but an "Implements" or "Extends" could be different
{
// maybe some other methods
private class SubClass
{
// etc.
}
}
But the real question is: do those subclasses really need to be inner classes of that "MainClass", or could they be top-level classes themselves?
Instead of packaging all classes into 1 class you should use multiple classes and Namespaces to store and use your code. Especially with larger Projects this can help you organize your code.
Note: The name of a Namespace may not be the same as one of class. But you can use the same Namespace for multiple classes.
i.e.
Create a "MainClass.vb"
Create a "SubClass.vb"
Code "SubClass.vb"
Namespace Main
Public Class SubClass
Function SubFunction() as String
....
End Function
End Class
End Namespace
So you can access the Class SubClass by "Main.SubClass"
If you have a lot of classes and files you could i.e. create for each Namespace a SubFolder
Main
|-- SubMain
|---|-- SubSubMain
|-- AnotherSubMain
|---|-- SubAnotherSubMain
with the Namespaces
"Main"
"Main.SubMain"
"Main.SubMain.SubSubMain"
"Main.AnotherSubMain"
etc.
To store general functions which are often or commonly used you could also create a library project.
Yes, partial classes in vb.net will allow you to do exactly what you request.
MainClass.vb
Partial Class MainClass
Function FunctionA() as String
...
End Function
End Class
MainClass.SubClass.vb
Partial Class MainClass
Class SubClass
Function SubFunction() as String
....
End Function
End Class
End Class
Leaving aside questions of re-architecting and re-factoring, which is not the question you asked, with a very large class file, described as 1000s of lines long, there may be some additional quick-fix benefits in using even more partial class files to enact a separation of concerns. Use Partial to split the unwieldy class file into logically related bundles of code across multiple smaller .vb files.
How advisable, how effective, or how dirty, this action is is obviously debatable, but the facility does exist, and it would therefore be up to you to take a view on how beneficial/problematic this partitioning option may or may not prove to be.
http://en.wikipedia.org/wiki/Partial_class
I have a bunch of different forms that I would like to create a base MustInherit class for. One function I would like them all to contain is a shared function called GetForms(). I know that you can't declare a shared function MustOverride so I did the following in my abstract class:
Public Shared Function GetForms() As List(Of OrderForm)
'to be overridden in child class'
Return Nothing
End Function
And this in my child class:
Public Overloads Shared Function GetForms() As List(Of OrderForm)
'do stuff'
End Function
Will this cause problems down the line, or is this an acceptable workaround? It has a smell to it, but it will enforce that all my forms include a shared GetForms function.
EDIT I realize that if this were possible with interfaces, I would use one, but you can't declare shared functions in interfaces and I would like to make sure that this is a SHARED function.
This has a smell because it creates a false expectation of the behavior of the code.
You mention that your reason for doing this is that 'it will enforce that all my forms include a shared GetForms function'. This is only partly true. Yes, they will all have the GetForms function, but you're not actually forcing the derived classes to implement their own version of it. If you forget to implement the function on one of them, you'll be calling the base version, and you won't get any sort of warning about it from the compiler.
That is the smell: it can't actually enforce the behavior that you want, but it creates an impression, at first glance, that it can. This will lead to headaches 6 months from now when you're adding a new Form type and you've forgotten the convention. You'll get no warning that something's wrong until you start getting bad results during testing.
If you want to enforce behavior, you have to do it using instance members; using MustOverride (abstract) functions or an interface.
You can have static (Shared) methods like that, but you can't enforce the implementation of them.
Each static method is local to it's class, you can't overload it in a child class or make it abstract (MustInherit). You have to use an instance method (non-static) to get the object oriented aspects that you want.
Yes, that does smell!
Looks like you should be using an interface instead.
Here is a vb.net article: http://www.developer.com/lang/other/article.php/939411
Why wouldn't you simply declare it as:
Public MustOverride Function GetForms() As List(Of OrderForm)?
Static methods aren't inherited, so the expectation of overriding is not something we want to encourage. In other words, I think you might be barking up the wrong tree here.