I have a few objects which implement dbus interface. Is it possible to call a method of that interface on all objects which implement it?
For example:
org.freedesktop.DBus.Properties has method GetAll. Is it possible to call GetAll method on all the objects that implement this interface?
P.S. Don't know how to tag this question properly, the answer may be in python, c/c++ languages, or even dbus-send, just give an idea.
There is no way to do this directly: you need to enumerate all objects exposed by all connections on the bus, then enumerate all their interfaces to find the ones which implement the interface you care about, then call the methods on those objects one-by-one.
Related
Is there a way to query what methods are offered by a given NEAR contract? (So that one could do autodiscovery of some standard interface, for instance.) Or do you have to just know the method signatures already before you can interact with a contract?
No not yet. Currently all contract methods have the same signature. () -> () No arguments and nothing is returned. Each method has a wrapper function that deserializes the input bytes from a host; calls the method; and serializes the return value and passes the bytes back to the host.
This is done with input and value_return. See input..
There are plans to include the actual signatures of the methods in the binary in a special section, which would solve this issue.
NEP-351 was recently approved, which provides a mechanism for contracts to expose all standards they implement. However, it is up to contract developers to follow this NEP. When integrated into the main SDK, I presume most will.
Alternatively, there is a proposal to create a global registry as a smart contract that provides this information.
Currently, there is not.
You will need to know what contract methods are available in order to interact with a smart contract deployed on NEAR. Hopefully, the ability to query available methods will be added in the near future.
I suppose you can just include a method in your own contracts that returns the other method signatures in some useful format: json or whatever
you would have to make sure that it stays current by maybe writing some unit tests that use this method to exercise all others
I suppose this interface (method and unit tests) can be standardized as an NEP in the short term until our interface becomes discoverable. any contracts that adhere to this NEP must include this "tested reflection method" or "documentation method" or whatever it would be called
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
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.
Do Hacklang Collections have higher order functions such as Reduce, Some, All or an easy way to implement such methods. The Collection I am most focused on is the Vector. It seems to only have Map and Filter. The others would help in writing more clean looking functional code.
Full information on the different Hack collections is best seen on the API docs for Vector (and other classes).
I also only see ->map and ->filter, though writing a utility function to do reduce yourself isn't particularly difficult, of course.
In our project we use dbus for Inter Process communication. We have one interface where all the methods that need to be exposed to other process are tied together. That is only one interface for all the methods . Is it good idea ? Is it better to group the methods in to different interface ? We have around 50 methods. I am not familiar with Object oriented languages. But I feel it is better to group them in to different interfaces.
What will be the advantage of splitting the methods under different interfaces ? I need some justification for grouping methods under different interfaces.
Note that dbus has auto code generator which generates the necessary class and methods when xml is given as input.
From a object-oriented perspective it's better to group messages in different interfaces according to their meaning. For a instant messaging software like pidgin you could have:
MyIPCInterface:
accountCreate(...)
accountList(...)
accountRemove(...)
messageSend(...)
messageReceived(...) * signal
statusChange(....)
statusChanged(...) * signal
but a better choice would be to separate this into different interfaces according to their meaning:
AccountManagerInterface
create(...)
list(...)
remove(...)
AccountInterface
sendMessage(...)
messageReceived(...) * signal
statusChange(...)
statusChanged(...) * signal
Of course, there are many other ways to design this but the main point is that when you receive the "messageReceived" signal for an AccountInterface object, you know what account "object" received the signal, better than that you are separating the concerns of who should manage accounts from who should manage the account objects.
There's much more to say about that but I hope this may help to clarify...