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.
Related
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
Ok so i'v been starting to learn kotlin for a week now, and i love the language:p
Besides the great utility of extension function, i feel like they lack a proper way of creating namespaces like java utility classes (xxxUtil).
I have recently starting to use this aproach, which im not sure is the right one, and i would like some feedback from Kotlin experienced users.
Is this a valid and proper thing todo:
object RealmDb {
private val realmInstance by lazy{ Realm.getInstance(MainApplication.instance) }
private fun wrapInTransaction(code:() -> Unit){
realmInstance.beginTransaction();
code.invoke()
realmInstance.commitTransaction();
}
object NormaNote{
fun create(...) {...}
fun update(...) {...}
}
}
So, whenever i want to update some NormalNote value to a Realm Database, i do the following:
RealmDb.NormaNote.create(title.text.toString(), note.text.toString())
Is this a common thing to do? Are there better approaches? As i understood, this is singleton nesting, i don't think there's any problem with this, i just don't like to put this common things like DB operations inside classes that need to be instantiated. In old java i opted to static classes
The officially recommended way to create namespaces in Kotlin is to put properties and functions that don't need to be inside classes at the top level of the file, and to use the package statements to create a namespace hierarchy. We see the practice of creating utility classes in Java as a workaround for a deficiency in the language, and not as a good practice to be followed in other languages.
In your example, I would put all of the code in top-level functions and properties.
I don't know about the rest of the code, but I do know that you don't have to call .invoke () on code. The invoke method can always be shortened to a direct call, which in this case would be code ().
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 have read several answers on stackoverflow with this question in my mind, but my question is a little different.
what i want to know is for variables that are not dependent on other variables of the class, why can't i declare the variable public like we do in java and then access the variable directly?
i mean in objective c, if i have a variable which i have declared in the interface of a class, why can't i directly (without making its getters and setters) access with,
self.variable or instanceofclass.variable....?
this is what we usually do in java and other object oriented languages.
getters and setters have their own advantages, but when you are doing simple things,would it not be better if you access variables in the way i have mentioned above.
PS: i am very new to objective c, so if we can access the variables in the way that i am claiming we cannot , please excuse. i have tried doing so, but there was an error, hence i am asking, but it very well could have been due to something else. so again please excuse.
thank you in advance.
because it is fundamentally wrong. If you expose a member variable as public, you are exposing internal details of a storage strategy which is not supposed to be known to the client. This will make your life much harder if, in the future, you want to implement smart strategies like allocation on the fly, or even just putting a print statement every time the variable is accessed, for debug purposes. Accessing a public variable gives you much less freedom than calling a method, and you are bound to your choice because accessing a member var and calling a member function use different syntaxes, so you will have to go around and fix your code everywhere.
The only situation where this is not an issue is when you have a pure struct, a class whose members are purely to hold and carry around a bunch of data under a collective name, and the storage strategy is already exposed by the very nature of the bunch of data you are carrying around.
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.