What is the difference between Class Module(.cls) and . Module(.bas) in Visual Basic ?
A Module(.bas) has methods and variables that can be used globally in your program and there is only a single instance of the data (similar to a Static method or field in C#). A Class Module(.cls) has properties and methods that usually can only be accessed when the object is instantiated, but can have multiple copies, each with differing data.
From MSDN: Visual Basic Concepts:
Classes differ from standard modules in the way their data is stored.
There is never more than one copy of a standard module’s data. This
means that when one part of your program changes a public variable in
a standard module, and another part of your program subsequently reads
that variable, it will get the same value.
Class module data, on the other hand, exists separately for each
instance of the class.
And from Devx.com: Class Module(.cls) vs. Module(.bas):
Deciding between a standard module and a class module is not a
decision based on performance, but one of design. The main difference
between the two is in the way that they handle data. A standard module
stores only one copy of the data. A class module encapsulates the data
within each instance of the class. That is, for each instance of the
class, the data exists separately.
The other main difference is the scope of variables and procedures
within the module. In general, any variables and procedures declared
as Public within a standard module are visible anywhere in the project
or external programs if the standard module is in a component.
Variables and procedures declared as Public within a class module can
only be seen through a reference to an instance of the class module.
The lifetime of data and procedures stored within a module is affected
by which type of module is used. The lifetime of the data and
procedures in a class module is defined by the lifetime of the object.
So data and procedures are available only if a reference to the object
exists. Data and procedures declared within standard modules are
available for the lifetime of the program.
Therefore, to answer your question, if you are writing a function that
you want available throughout the lifetime of the program and visible
to all code in the application, then place the function within a
standard module.
If the code is needed for lifetime of the program and is visible to all code in the application, then place the function within a standard module.
A standard module stores only one copy of the data. A class module encapsulates the data within each instance of the class. That is, for each instance of the class, the data exists separately.
In general, any variables and procedures declared as Public within a standard module are visible anywhere in the project.
Variables and procedures declared as Public within a class module can only be seen through a reference to an instance of the class module.
The lifetime of data and procedures stored within a module is affected by which type of module is used. The lifetime of the data and procedures in a class module is defined by the lifetime of the object. So data and procedures are available only if a reference to the object exists. Data and procedures declared within standard modules are available for the lifetime of the program.
Related
It seems like there are two styles for writing NEAR smart contracts in assembly script
Bag of functions like Meme Museum
Singleton style like Lottery.
I was wondering under what circumstance one style is recommended over the other.
When should you use one over the other? What are the advantages/disadvantages of each style?
The big differences is in initialization of the contract.
Bag of Functions (BoF)
For the first style, usually a persistent collection is declared at the top level. All top level code in each file is placed into a function and one start function calls each. The Wasm binary format allows to specify the start function so that anytime the binary is instantiated (e.i. loaded by a runtime) that function is called before any exported functions can be called.
For persistent collections this means allocating the objects, but no data is required from storage, until something is read, including the length or size of the collection.
Singleton
A top level instance of the contract is declared. Then storage is checked for the "STATE" key, which contains the state of the instance. If it is present storage is read and the instance is deserialized from storage. Then each "method" of the contract is an exported function that uses the global instance, e.g. instance.method(...), passing the arguments to the method. If the method is decorated with #mutateState then the instance is written back to storage after the method call.
Which To Use
Singleton's provide a nice interface for the contract and is generally easier to understand. However, since you are reading from storage at every method call, it can be more expensive.
The other advantage of the BoF is it's easier to extend as you can export more functions from a dependency.
However, it's also possible to use a combination of both as well.
So really it's whatever makes sense to you.
Is lib a special keyword for Frogatto Formula Language (FFL)? That seems to be the way of invoking class methods. For example:
where frog = lib.citadel.create_creature('Giant Frog')
Also, I am interested to know where can I find a list of all the available lib.**** library objects and how to list of all their available functions.
I wouldn't call it a keyword as such, more a symbol that appears in the standard namespace. As such it is functionally fairly close to a keyword.
When you create a class by adding a file e.g. data/classes/blah.cfg then a singleton instance of this class will be available using lib.blah. This is a convenient way of effectively creating your own namespace of functions -- create a class, add functions to it, then your functions can be accessed using lib.classname.functionname()
I'd like to access attributes that are inside instances of defined types from other classes/instances.
This is very similar to a question asked on SO before - In Puppet, how can I access a variable/attribute inside a defined type?, however from what I understood the answer was specifically related to accessing parameters as opposed to arbitrary variables.
For example, given the following defined type:
define server (
$server_name = 'my_server'
){
$server_history = 'A long story'
}
I can successfully use getparam(...) to fetch server_name but I cannot do the same for server_history.
Also, if server was a class as opposed to to a defined type, accessing this variable is straightforward using something like server::serverhistory
Does anyone have any ideas on how to expose these variables? Or am I approaching this completely the wrong way?
Edit: For some higher level context on what I'm trying to do my server type gets instantiated by 3 other classes. A variable in the server type builds out some directory paths based on parameters provided to it by these classes (which naturally, are specific to those classes). There are some other classes that would like to use the directory path variable to place files there.
You ask
I'd like to access attributes that are inside instances of defined types from other classes/instances.
and you go on to clarify that you're after
arbitrary variables.
In fact, ordinary variables in the body of a defined type are not attributes of that type, nor of any instance thereof. They are not part of the accessible persistent state of instances of such types at all.
More generally, Puppet treats defined types just like native types in almost every observable way, but by the same token, it does not provide any features that serve to distinguish defined types as a special case. You are looking for such a feature, and it does not exist.
Since your design idea will not work, you'll need to think of an alternative. You say
my server type gets instantiated by 3 other classes. A variable in the server type builds out some directory paths based on parameters provided to it by these classes (which naturally, are specific to those classes). There are some other classes that would like to use the directory path variable to place files there.
Since the paths you're after are characteristic of specific classes, it makes sense for them to be accessible directly via those classes. It seems odd to me that you would even want to access them indirectly via resources declared by those classes.
I am having a problem with a circular dependency. Similar question have been asked and I have read a lot of answers. Most deal with a work-around but I would like to refactor so what I have it correct and I would like some input on where I have gone wrong. I can change what I am doing but not the entire project architecture.
I am using VB.Net in Visual Studio 2012.
I have two class libraries:
DataLayer for accessing the database.
DataObject which contains classes that represents my business objects.
My Presentation Layer calls methods in the DataLayer which returns objects from the DataObject class library.
(I have simplified somewhat – I actually have a controller layer but it needs references to the two class libraries above. This is an existing architecture that is from before my time.)
In the DataObject class library I have an abstract class that represents a file. It has properties such as filename, userID, etc. It also has a method, GetFile(), that I code in the derived classes because there are different ways of getting the file. A DataLayer method returns a collection of these file objects, but I don't want to get the actual file until it's needed.
So far, I have a derived class that calls a webService (using properties from the baseClass) and a derived class that accesses the fileSystem. Both return a byte array representing the file. The calling class does not need to know how the file is retrieved.
Now I have a new requirement to build the file on the fly using data from the database. I can get all the data I need using the properties in the base class.
My issue is that my GetFile() method will need to access my DataLayer class library to pull data from the database which causes a circular dependency. The DataLayer class library has a reference to DataObject since that is what it returns. But now I need to call the DataLayer from a class in DataObjects.
I could call the DataLayer from presentation and pass the result to
my DataObject’s GetFile() method, but then my presentation layer
needs to do something special for this derived class. My goal is
that the derived class handles GetFile without presentation knowing
about the implementation.
I could create a new class library for this DataLayer code but I
don't like a special case.
I could access the DB directly in the DataObject class but that
circumvents the layered architecture.
I can’t change our architecture, but I can change my approach.
Any opinions?
I think I have the answer.
In my concrete class, when I am loading the data initially (in the DataLayer), I will get all the data I need to create the file. I'll store it in a new property in my concrete class which my GetFile() method will use to build the file.
This has a little more overhead - I make DB calls and put all this data in memory when it may not be needed. I'll give it a try and see how performance is.
Any critiques of this approach?
when should I go for a module and when for a class?
when module and class are loaded onto memory?
Can I unload the module and class already loaded?
A static (BAS) module loads and stays resident for the duration of the run. A class (CLS) module provides for more dynamic allocation of both code and data.
Classes also offer better encapsulation, can have multiple instances created, can be persisted, and have many other advantages over static allocation.
There is a whole section in the manual named "Programming With Objects" you might want to read and study. All legitimate VB6 Editions above the Learning Edition should have this material and more in the MSDN CDs that ship with them. The hardcopy books can also still be found from some new and used sources.
For each BAS module, all module level variables are allocated when the application starts up. You cannot deallocate these variables (although you can set object references to Nothing, the actual variable will still exist).
A CLS module's module level variables are only allocated when the class is instantiated. All memory allocated for an instance of the class is deallocated when the class is destroyed. You can create as many instances of the CLS module as you want, and each has its own private set of module-level variables.
In BAS modules, the scope of variables declared Public is global to the application. However, in CLS modules, you can only access a Public variable if you have a reference to an instance of that class (behind the scenes that variable becomes a Public Property).
In general, all variables and routines that you want to be accessed from any module should be put into a BAS module.