I'm a newbie with glib and I'm still struggling to understand the difference between my_class_name_class_init() methods and my_class_name_init() methods.
I get that the latter is kinda equivalent to a C++ constructor and that goes per-instance of the object created but I don't quite understand the purpose of those my_class_name_class_init() methods. By reading the documentation I think class_init() methods are somewhat similar to a static constructor valid for all instances but I'm still not sure I got this right.
What's the purpose of class_init() methods?
class_init functions are executed once per class, before first instance is constructed - in that way they are similar to C# static constructors. In contrast, instance_init functions are called for every instance of object created and are responsible for initializing that instance.
Like static constructors, class_init are responsible for initializing any shared data all instances might need, but more importantly, in GObject they play vital role in setting up GObject object system. They are responsible for:
Setting up virtual function tables
Setting up GObject property system
Setting up signals
Related
When you create a control object (an HWND) in Windows API, you are not allowed to access the members of the control object directly, you can only access it through specific functions, which is a characteristic of OOP.
Also, Windows API supports Polymorphism, for example I can have the following function:
void setHwndText(HWND hwnd)
{
SendMessage(hwnd, WM_SETTEXT, 0, (LPARAM)"Hello World");
}
The above function can change the text of many types of objects and not just one type, for example it can change the title of a window, the text of an edit control, and the caption of a button control.
I don't know if Windows API supports Inheritance, but even if it didn't, I think the main purpose of Inheritance in OOP is to allow Polymorphism, which Windows API do support as I have showed.
Does that mean that Windows API can be considered an object-oriented framework?
File and window handles in Windows are similar to streams, file descriptors in Unix, FILE pointers in the C standard library, and so on. There’s a similarity between passing an opaque handle to library functions and calling member functions with an implicit this pointer.
Another example that gets closer are window classes that you register with RegisterClassEx(). This is transitional between a handle-style API and a framework like COM that everyone agrees is “object-oriented:” you register a structure containing a function pointer, which is much like the member function pointers in a virtual function table. What you don’t have is any kind of class hierarchy or a selection of interfaces to implement. You aren’t overriding a default implementation, or inheriting some methods while overriding others. You’re just passing a structure containing function pointers.
The distinction can get fuzzy. If you look at the family of languages designed by Nicholas Wirth, Pascal is a traditional structured, imperative language inspired by Algol, and Modula, Modula-2 and Oberon evolve experimentally in an object-oriented direction. At the time, these intermediate languages were called “object-based.” By the mid-’90s, languages such as Delphi and Object Pascal fit the object-oriented paradigm.
However, libraries similar to those of the late ’70s generally are not called “object-oriented.” In particular, they don’t have a class hierarchy with inheritance. Neither does the client application manage instances itself, with their creation and destruction automated to prevent memory leaks.
When the C API does do things similar to polymorphism and inheritance, such as being able to supply a pointer to a callback function, it does it in a different way. In a conventional object-oriented language, you would statically define a derived class of a window that overrides a virtual member function, not supply an arbitrary function pointer to call back (although there is some similarity to the object-oriented visitor pattern).
Things like the similarly-named “window classes” are just callbacks. Even though all implementations of polymorphic objects are built on top of structures containing function pointers, not all programs that use callback functions are object-oriented. An example closer to object-oriented programming is how Winsock 2 makes socket descriptors a special type of file descriptors that can be passed to the kernel file functions (with a cast). If we had an object-oriented API that renamed the member functions as global functions, made the implicit this pointer an explicit argument, then cast it to an opaque handle, it’d still be mostly object-oriented. The only things it would lose would be static type safety and encapsulation. Even more OOP-like, to the point where I would definitely call it OOP, is the Component Object Model and its successors, in which objects implement interfaces.
There have been several “object-oriented” APIs for Windows, including the Microsoft Foundation Classes, Borland’s Object Windows Library, Object Linking and Embedding, the newer Component Object Model and Common Language Runtime libraries, and the even newer Windows Runtime.
I am newbie in Elixir, coming from java background. I saw Elixir's function as static methods in java. So I wonder, is there any non-static method / function in Elixir?
Thank you
Nope - all functions belong to a module. Elixir is not an class-oriented language, so the concept of "instance methods vs. class methods" is not applicable.
Aside from typical named functions which belong to a module, there are anonymous functions, similar to lambdas in Java.
The accepted answer is correct and I upvoted it. The basic building blocks in OOP are objects. On the BEAM (Erlang VM), the basic building blocks are processes. So, the distinction between static/instance methods just doesn't make sense.
However, when thinking about what instance methods do in an object oriented language, there is something that does a similar thing in Elixir.
Instance methods, when contrasted with class methods, are the ones that work with internal object state. Elixir doesn't have classes or objects, but it does have processes. A GenServer process instance maintains state and passes it into each callback function. So, when you're looking for something that will have state and functions to modify it or return some piece of it, then you want to reach for a GenServer in Elixir.
All the functions will still belong to the Module. They aren't a unique type of function, but they do allow you to manipulate the state of a given instance of the process because the state gets passed in as a parameter and returned within the function's result.
In response to the comment by #ibgib, yes, when compared with an object oriented language like Java or C#, you can think of all modules and functions in Elixir/Erlang as being static. This is comparing apples to oranges, but if it helps when learning to think of them that way, I think that's OK. Just realize that there isn't any such thing as instance methods here.
In UVM Cookbook, it is written that class object instantiation is done at run time. But before run time, during compilation/elaboration also we may have all the details of class.
As depicted in the below image (Taken from UVM Cookbook), it is showed that Module and Interface instant creations are done in elaboration phase, but class object creation are done at run time.
Consider this sample example.
// Inside any .sv file
class A;
int a;
endclass
A x;
initial
x=new();
Now in this case there is no need of creating class at run time, as we have all the details of class available in compile/elaboration time like another module or interface details.
So why in Systemverilog, specifically only class instantiations are done at run time?
Even in C++ also object creation are not done at run time.
Note : In the question, I am talking about simple classes, not using inheritance, in which run time creation may become mandatory. By Creation I do not refer to memory allocation, as memory for all (module, interface, class) will be allocated during simulation only. I am just taking the context of the image.
All objects are created at run-time.
Maybe you are confusing run-time with run-phase? Run-phase is part of the phasing mechanism in uvm that allows for separation between different periods in a simulation. All uvm components can thus be synchronized by phase.
Object creation here is done in the build_phase, which is part of the run-time.
As #Tudor points out, all object instances are created at run time. They have to be because all objects have to execute their constructor. This is the same as C++.
I know that non static methods cannot be referenced from some static context, you have to make an instance of the class and call the method on that instance, or , you can make the method static. I also know the reason why. But I cannot decide what is the best practice to do this? Making the method/variable static or using instance of the class to call the method/variable, and why?
Object oriented languages work best when you use objects. If its anything more than the most basic of applications, create a class to house the functionality and instantiate it. You'll just end up refactoring into classes later anyway.
The reason is that objects, instances, etc all describe varying degrees of scope, allowing you to create complex programs from an amalgamation of encapsulated, fairly simple functionalities
i wonder if one should create a helper function in a class as a static function or just have it declared as a procedural function?
i tend to think that a static helper function is the right way to go cause then i can see what kind of helper function it is eg. Database::connect(), File::create().
what is best practice?
IMO it depends on what type of helper function it is. Statics / Singletons make things very difficult to test things in isolation, because they spread concrete dependencies around. So if the helper method is something I might want to fake out in a unit test (and your examples of creating files and connecting to databases definitely would fall in that category), then I would just create them as instance methods on a regular class. The user would instantiate the helper class as necessary to call the methods.
With that in place, it is easier to use Inversion of Control / Dependency Injection / Service Locator patterns to put fakes in when you want to test the code and you want to fake out database access, or filesystem access, etc.
This of course has the downside of there theoretically being multiple instances of the helper class, but this is not a real problem in most systems. The overhead of having these instances is minimal.
If the helper method was something very simple that I would never want to fake out for test, then I might consider using a static.
Singleton solves the confusion.
MyHelper.Instance.ExecuteMethod();
Instance will be a static property. Benefit is you get simple one line code in calling method and it reuses previously created instance which prevents overhead of instance creation on different memory locations and disposing them.