I have read lot of D-Bus documentation and understood various concepts such as:
1. Object
2. Interface
3. Method
4. Signal
5. Bus Connection
6. System vs Session Daemon
However while reading through ObjectManager::GetManagedObjects I came across this concept of "Object Tree". I know that I when I invoke the above method on a service object, it gives me all the interfaces in the tree with the service object as the root (Since the service object implements ObjectManager interface from D-Bus).
I would like someone to very clearly explain what does it mean exactly when one object comes "under" a root object in an "object tree"
Are children object just properties of parent object?
Do children object subclass the parent object (Just like OOP)
What is D-Bus Object Tree? Please!
The semantics of the object tree are determined by the particular service which is providing it. By convention, the location of objects in a tree is just determined by their object path. For example, /org/freedesktop/Accounts/User1000 is considered to be a ‘child object’ of /org/freedesktop/Accounts. However, there is no formal relationship beyond this.
To answer your specific questions:
Are children object just properties of parent object? No, they are separate objects with their own set of properties. The only thing they have in common with the parent is a prefix on their object path.
Do children object subclass the parent object (Just like OOP)? No. They may implement the same interfaces, different interfaces, or anything inbetween. Typically, they will implement a different interface — it’s quite common to have a parent object implement a ‘manager’ interface, and the child objects implement an ‘item’ interface, for describing collections of items.
Related
State diagrams in UML are always constructed for a specific class (that is, to describe the behavior of instances of that class). Thus, every state diagram is associated to a specific object for which it defines its behavior. What is the name of this object? the closest I could find in the UML standard is the term 'context object', as in here (section 14.2.3.1 in UML v2.5.1):
The event pool for a StateMachine execution belongs to either its context Classifier object or ...
But I could not find anyone that uses this term.
I use an answer to not have to cut the following in several comments.
State diagrams in UML are always constructed for a specific class
You have to speak about state machine, not about diagram, and in your case visibly you speak about behavior state machine (not about protocol state machine).
A diagram is just a picture showing a part of the model.
Thus, every state diagram is associated to a specific object for which it defines its behavior. What is the name of the object?
That depends, if your state machine defines the behavior of an operation then your object is that operation and its name is the name of the operation.
that is, to describe the behavior of instances of that class
If I well understand this is from where your error comes from. You are focused on instances of class, but a state machine does not define the behavior of instances of a class, so to try to know the 'name' of theses instance as no sense.
Perhaps someone who has worked on the still-unadopted Precise Semantics for State Machines specification at the OMG will correct me if I’m wrong, but I believe there are three possible execution contexts.
The first is that of an “active class”, where each instance runs in its own thread and you send signals to it. The second is that of a normal class, where you call operations on or send signals to a normal instance, in the usual way. The third is that of a BehavioredClassifier, where each instance starts a special classifierBehavior as soon as it is created.
§13.2.3.5 of the UML 2.5 spec says:
The receiving object becomes the context object for the execution of
any invoked methods.
NOTE. Methods of a Reception are always invoked asynchronously, while
the methods of an Operation may be invoked either synchronously or
asynchronously, depending on how the Operation is called.
A state machine is defined for one of those execution contexts to determine how an instance will respond to a particular event, given its current state.
Yes, every state machine (possibly depicted in a diagram) is associated with an object, but it is not some specific object with some special name. Rather, a state machine governs how every instance of a particular class will respond to events, given its current state. And the name of an instance is whatever variable happens to hold a reference to it.
I am learning about virtual function tables and their representation by analyzing a binary of a simple program written in Visual C++ (with some optimizations on).
A few days ago I asked this question while being stuck on virtual method table content with identical COMDAT folding on.
Now I'm stuck on something else: whenever I analyze a class, I need to find its Virtual Method Table. I can do this by finding either its RTTITypeDescriptor or _s_RTTIClassHierarchyDescriptor, finding a cross reference on it, which should lead me to the _RTTICompleteObjectLocator. When I find a cross reference to the Complete Object Locator, it is written just before the VMT (basically -1st entry of the VMT).
This approach works on some classes (their names start with C in my program). Then there are classes, that are named with I in the beginning and I am able to pair them with other classes starting with C -- for example there is class CClass and it inherits from IClass. These I-classes are probably serving as interfaces to the C-classes and thus they probably only contain abstract methods.
By searching a cross reference to Type Descriptor or Class Hierarchy Descriptor of any of the I-classes I cannot find anything -- there is no Complete Object Locator that would lead me to the VMT of the class (that should be full of references to pure_virtual call if I am correct about the all-abstract methods in the I-classes and if I understand correctly what VMT of abstract class looks like).
Why do the I-classes have no VMT? Did the compiler optimize it out because it would just be full of references to pure_virtual call and manages it in a different way?
These "interfaces" abstract classes probably have need no user written code in any their constructors and destructors (these either have an empty body and no ctor-init-list, or simply are never user defined); let's call these pure interface classes.
[Pure interface class: concept related but not identical to Java interfaces that are (were?) defined as having zero implementation code, in any member function. But be careful with analogies, as Java interfaces inheritance semantic isn't the same as C++ abstract classes inheritance semantic.]
It means that in practice no used object ever has pure interface class type: no expression ever refers to an object with pure interface type. Hence, no vtable is ever needed, so the vtable, which may have been generated during compilation, isn't included in linked code (the linker can see the symbol of the pure interface class vtable isn't used).
I recently read in "Professional C# 4 and .NET 4" that:
You can never instantiate an interface.
But periodically I see things like this:
IQuadrilateral myQuad;
What are the limitations in using interfaces directly (without having a class inherit from the interface)? How could I use such objects (if they can even be called objects)?
For example instead of using a Square class that derives from IQuadrilateral, to what extent could I get away with creating an interface like IQuadrilateral myQuad?
Since interfaces don't implement methods, I don't think I could use any methods with them. I thought interfaces didn't have fields to them (only properties), so I'm not sure how I could store data with them.
The answer is simple, you can't instantiate an interface.
The example you provided is not an example of instantiating an interface, you are just defining a local variable of the type IQuadrilateral
To instantiate the interface, you would have to do this:
IQuadrilateral myQuad = new IQuadrilateral();
And that isn't possible since IQuadrilateral does not have a constructor.
This is perfectly valid:
IQuadrilateral myQuad = new Square();
But you aren't initiating IQuadrilateral, you are initiating Square and assigning it to a variable with the type IQuadrilateral.
The methods available in myQuad would be the methods defined in the interface, but the implementation would be based on the implementation in Square. And any additional methods in Square that are not part of the IQuadrilateral interface would not be available unless you cast myQuad to a Square variable.
You can't create an instance of an interface.
The code you showed defines a variable of type IQuadrilateral. The actual instance this variable points to will always be of a concrete class implementing this interface.
Background Knowledge
Think of an interface as a contract. In a contract between two people, it defines what is capable, what is expected from the parties involved. In programming, it works the same way. The interface defines what to expect, what must exist for you to conform to that interface. Therefore, since it only defines what to expect, it itself, doesn't provide the implementation, the "code under the covers" so to speak, does.
A property behaves like a field, but allows you to intercept when someone assigns a value to it or reads the value. You can also deny reading or writing to it, your choice when you define the property. Interfaces work with properties instead of fields because of this. Since the "contract" is just defining what property should be there (name and type), and if it should allow a read or write capabilities, it leaves it up to the implementer to provide this.
Take for example the IEnumerator interface from the .NET framework. This interface was designed to allow iteration over a collection of objects. The purpose is not to change items, or randomly access them, it's just for getting object A and moving to the next, and the next, and the next, as many times as needed. Many collection type classes implement this: Queue, ArrayList, SortedList, Stack, etc. All these types of objects store many objects and now they all share the common "contract": the ability to iterate one-by-one over them.
However, you can see that the IEnumerator interface has a MoveNext() method declared. Why? This is because the items may not be served in the same manner. For example, people will generally access the ArrayList from the first item to the last. But a Stack was designed opposite, for people to access the last object down to the first.
Questions Answered
With all this knowledge, the limitation of declaring a variable as the interface type as opposed to the class type that implemented the interface is that you only get access to what the interface (the contract) says should be there. The benefit though is that you can assign to this variable any class type that implements the interface.
In COM, when you want to create an instance of some COM Server object, do you first need to get a pointer to it's IUnknown interface and only then create a class object using CoGetClassObject?
As far as I understand it, IUnknown is used to manage object lifetimes, so from my understanding, whatever object the client wants to create, one needs a pointer to it's IUnknown interface implementation first.
Sound correct? If not, can anyone tell me how it works?
IUnknown manages the lifespan of an existing COM object. Before the object is created, there is no IUnknown pointer to speak of.
CoGetClassObject is used to get the IUnknown interface for an object that is expected to create the objects of interest. I.e., it is an object factory, an usually implements IClassFactory, which declares the CreateInstance method that you use to create objects.
Instead of using class factories explicitly, it is often simpler to just call CoCreateInstance.
I have a base class object array into which I have typecasted many different child class objects and am passing it to a sub vi. Is there any way by which I can find out the original type of the object of each individual elements in the array?
Thanks ...
For posterity, this was crossposted to the LAVA forums. The user Aristos Queue, one of the developers of LabVIEW's native OO features, answered with the following:
Using a dynamic dispatch method in every class is the recommended way of handling this, although the recommendation is to create a method that does whatever it is you're trying to do. I'm guessing that you're thinking of a dynamic dispatch method that returns a name or ID of the object so you can say, "Is it equal to this? Ok, then it must be this class..." and then you do Action X if it is that class. If you write a dynamic dispatch method ActionX.vi and then override it appropriately, you'll save yourself on performance and have much easier time for code maintenance in the future.
You can also use the To More Specific node to test if a given object can be downcast to a given type -- this allows for inheritance testing as opposed to the name or ID comparison that only does type equivalence. If the To More Specific node returns an error then it is not of the destination type.
So your options are (in order of preference):
dynamic dispatch method that does the action
To More Specific node to do type testing
dynamic dispatch method that returns name/ID of the class of the object
Get Path of LabVIEW Object.vi (shipped in vi.lib in LabVIEW 8.5 but not added to the palettes until LabVIEW 8.6)
NI has a good overview of LVOOP that is a must-read, since OO is implemented in a unique way for LabVIEW.
Have you tried the 'to more generic class' and 'to more specific class' functions, on the application control palette?