Considered multiple references?!

[Jupiter_gh]

In the proposed model, concepts are reference-object pairs, and the implementation of a reference, defines the mechanism by which the corresponding object is accessed. Is not it possible to access the same object or resource using two different mechanisms?!

For instance, if we want to send a message to a person, we can do that in two different ways: We can send him/her the message by post mail, or we can send an SMS to his/her mobile phone. So, a postal address and a mobile phone number both serve to identify or locate the person we need to communicate with.

[savinov]

In the proposed model, concepts are reference-object pairs, and the implementation of a reference, defines the mechanism by which the corresponding object is accessed. Is not it possible to access the same object or resource using two different mechanisms?!

For instance, if we want to send a message to a person, we can do that in two different ways: We can send him/her the message by post mail, or we can send an SMS to his/her mobile phone. So, a postal address and a mobile phone number both serve to identify or locate the person we need to communicate with.

This would mean that the object belongs to two different address spaces simultaniously where it has two references. It is quite typical situation in real world systems. This case could be modelled using multiple inclusion which is a concept-oriented analogue for multiple inheritance in OOP. If a concept is included in one parent concept then it lives in one external space. If it is included in two parent concepts then it will live in two spaces, environments or contexts.

For example, it could be described as follows:

Code: Select all

concept Mail
  reference {
    String mailAddress;
  }
  object { ... }

concept SMS
  reference {
    String smsAddress;
  }
  object { ... }

concept Person in Mail, SMS
  reference { ... }
  object { ... }


Notice that here concept Person inherits its identity from either Mail or SMS but not both.

Yet, it is quite difficult issue which has not been studied. In particular, the object life-cycle gets more complicated. It is necessary to understand how parent containers (say, Mail and SMS) share their responsibility over internal objects.

Above I assumed that each person is represented by only one reference among many possible. The person address is chosen initially and then the reference cannot be changed (but could be probably be converted to the equivalent format). Another case is where a person is represented by a kind of unique identifier and when the object is going to be accessed the resolution procedure chooses appropriate protocol. So there are more questions than answers here.

[Jupiter_gh]

Yet, it is quite difficult issue which has not been studied. In particular, the object life-cycle gets more complicated. It is necessary to understand how parent containers (say, Mail and SMS) share their responsibility over internal objects.

Above I assumed that each person is represented by only one reference among many possible. The person address is chosen initially and then the reference cannot be changed (but could be probably be converted to the equivalent format). Another case is where a person is represented by a kind of unique identifier and when the object is going to be accessed the resolution procedure chooses appropriate protocol. So there are more questions than answers here.

As you said, this topic may lead to even more questions, the thing that I hope would lead to a better understanding to this interesting new idea. Anyway, I did not study this idea thoroughly, and I doubt I could, but at times I just trust my intuition, and I wonder if my intuition is right regarding this topic.

What I see to it, is that this strong coupling between objects and references should be loosened a little, meaning that references should be declared independently, and they serve as formal means in concept-oriented languages to specify address spaces. When comparing with object-oriented languages, references correspond directly to proxies. This means that a reference should declare the interfaces it "proxies". Objects are declared to be identified by one or more references. In other words, they are declared to exist in one or more address spaces. And thus, they should implement the interfaces "proxied" by the identifying references. In short, a concept-oriented language would have three equally modeled elements: Interfaces, Objects and References.

When constructing objects, one may specify one or more addresses for this object. But at least one address should be specified at construction-time. Even more, it can be assigned a new address later (in other address spaces). What do you think?!

[savinov]

What I see to it, is that this strong coupling between objects and references should be loosened a little, meaning that references should be declared independently, and they serve as formal means in concept-oriented languages to specify address spaces. When comparing with object-oriented languages, references correspond directly to proxies. This means that a reference should declare the interfaces it "proxies". Objects are declared to be identified by one or more references. In other words, they are declared to exist in one or more address spaces. And thus, they should implement the interfaces "proxied" by the identifying references. In short, a concept-oriented language would have three equally modeled elements: Interfaces, Objects and References.

The initial version which is about 3-4 years old was very similar to what you describe. One of the main design goals initially was modelling address spaces (environments) via references with arbitrary structure and functions. So concept as a language construct was defined as a reference class (without object class). Concept inheritance allowed us to model nested spaces where elements are identified via multi-segment references. So in that old version references were decoupled from objects and we could define separately structure/behaviour of spaces and that of objects.

Then the question was how we can specify the address space for each concrete object. For this purpose inclusion relation was used, i.e., there was inheritance for building hierarchy of references and objects (separately) and inclusion for specifying reference type for each object type. For example, if we want to represent objects of class Account by references of class Remote then we make the following declaration: class Account in Remote. As far as I understand it is precisely what you mean when you say that "Objects are declared to be identified by one or more references" and "they are declared to exist in one or more address spaces".

In this approach, we had two kinds of classes and two kinds of relations and it looked relatively complex. After numerous attempts to reduce complexity and thorough analysis we came to a rather general conclusion that references cannot be modelled without objects and vice versa. In other words, we gradually came to understanding that reference and object are two sides of one thing and hence they should be modelled together. After that the main language construct was defined as a pair of two classes.

Of course, there are many examples where references are quite independent of objects they represent. And there are even more examples where objects are completely independent of their references (the whole OOP, actually). However, concept as a pair of two classes does not prevent us from focusing on only one side (reference or object) or even completely ignoring the other side.

If references and objects are used separately as you describe then we loose the fundamental assumption about their inseparable unity. In this case we need to model their connection manually using common interfaces or other means/patterns. Then references will play a role of proxies with all the consequences.

When constructing objects, one may specify one or more addresses for this object. But at least one address should be specified at construction-time. Even more, it can be assigned a new address later (in other address spaces). What do you think?!

There are two design alternatives about address assignment:

• [Static] At class definition time. In this case we specify type of the address for the whole object class and hence all instances of this class will be automatically assigned some address at run-time. When a new variable of this class is declared we do not need to specify its reference type. For example: class Account in Remote { ... }.
• [Dynamic] At variable declaration time. In this case each new variable needs to have two parameters: normal class name and additional reference type. Thus instances of one object class can be represented by different references. This approach is used, for example, by smart pointers in C++. For example, Account in Remote myVariable = new Account();

Currently, CoP follows the first approach, i.e., we bind references and objects at the time of concept definition. It can be viewed somewhat restricted because we cannot change the type of references at run-time however it is quite consistent because it does not claim that it can do more. In other words, in the current version of CoP we can model the structure of address space only statically.

The second approach is highly interesting and I have been thinking about possible mechanisms to allow for dynamic assignment of references but unfortunately I do not have a consistent solution for that case. (Of course, it is always possible just to add a new dedicated mechanism but the goal is to add new functions without adding significant complexity.) This is quite useful feature. For example, it would allow us to create one bank account object in different containers depending on our current needs. For example, one account object could be created as remote object (if it is supposed to be passed to some remote computer for further processing) while the second object could be created in local fast buffer (if it is needed for temporary purposes in the scope of this method only). I see some possible solutions but they are not complete and will definitely entail considerable changes in the whole approach by introducing new or generalizing existing principles (like the nature of computations etc.) So it is again more about future...

[kardang]

What about doing something completely different? (Or perhaps we are agreed, only I have not fully understood the role of dimensions in the CoP). The semantics of owning objects and the problem of shared ownership has a very important preassumption. That the existence of objects are absolute. This need not be the case.

Using dimensions, we could specify a contact_hierchary for the entire company. This could be a spatial dimension with company, department, employee. Using a similar contact_method we could make a dimension containing Phone, Mail, Electronic. A combination of these two would give the requested phone number. This require the phone number concept to have a coordinate in the contact_method dimension, and the coordinate for the phone number in the contact_hierarchy would be an employee.

The solution to the problem of the shared responsibility of the object is in my opinion as simple as the memory adress system in memory. What you delete is the memory adress pointer. The memory adress is freed by the garbage collector. If the compiler allowed us use more than one pointer to the same adress, we could have multiple pointers to the same adress. If we use the power of dimensions, a concept not present in OO, and postulate that there is either none ore one object reference (memory adress pointer) in each dimension, we could also say that as long as at least one dimension references this concept, it exists. Analogous to the memory adress system, we delete only pointers (references) and never actual objects.
Dimensions should be modelled in a way that the object could be manipulated within the context of the dimension, but never in such away that changes affect the validity of other dimensions. If one suddenly wanted to change the dimension, so that the phone number to the department manager was the only one visible, the other phone number might vanish from this dimension. They still exist however, as long as they have coordinates in other dimensions.
Deleting an object is thus given a new interpretation. It means to remove an object from a context. The object might still exist in other contexts (dimensions). An object is deleted when it is no longer acessible from any context, which means that it is effectively unreachable and can be collected by a garbage collector.

[savinov]

What about doing something completely different? (Or perhaps we are agreed, only I have not fully understood the role of dimensions in the CoP). The semantics of owning objects and the problem of shared ownership has a very important preassumption. That the existence of objects are absolute. This need not be the case.

In fact, CoP does not have and does not use the notion of dimension (as it is defined in CoM). CoP uses only inclusion relation which generalizes inheritance. Roughly, if we add dimensions to CoP then we will get CoM.

CoP uses normal fields which store references to other objects. CoM also uses fields which reference other elements but these fields get meaning (semantics) within CoM and hence we call them dimensions. The main difference between fields in CoP and dimensions in CoM is that the latter have well defined semantics in terms of ordered sets. Namely, the referenced element is interpreted as a super-element in the ordered set. Thus fields and dimensions are one and the same thing except that fields in CoP produce an arbitrary graph while dimensions in CoM produce an ordered set which can be then used for querying.

For example, we can define concept Person with a field of type Department

Code: Select all

concept Person
    identity { ... }
    entity {
        Department dept; // Field in CoP and dimension in CoM
    }


If it is defined in CoP then the field dept is simply a reference without any semantic interpretation and the only thing that we can do is to follow this link. If this concept is used in CoM then the dimension dept is a reference to a super-element and we can use this dimension for projection and de-projection.

I find using fields or dimensions for modelling references (identity modelling) difficult. It is inclusion relation that is intended to model how objects are represented and accessed. One property of inclusion relation is that it does not use references (fields, dimensions etc.) and hence it is precisely that can be used implement references. But any reference or address has some scope and this scope is modelled by the parent this element is included into. If we want to have many scopes for our addresses/references then we could use multiple-inclusion. However, here we still do not have any references/addresses. Or, if they are used then they have to be already implemented at some lower level of system organization.