« Dual methods in concept-oriented programming vs. capturing and bubbling in JavaScriptWhat if references are active elements of the program? »

7 comments

  1. § Mark Lee Smith Email said on :
    In C# value-type objects imply structs, while reference-types imply classes. This doesn't make C# concept-oriented. Seriously, what's with the false dichotomy you're creating here?
  2. § savinov® Email said on :
    You are right, having value-types (structs) and reference-type is not enough for concept-orientation. To convert C# into a concept-oriented language at least the following steps need to be performed: uniting structs and classes into one programming construct -- concept, and implementing concept inclusion instead of inheritance.

    Note that COP does not belong to OOP and I described only one (of many) their distinguishing feature rather than a dichotomy of OO programming languages. In particular, it is important to understand the symmetry (duality) between values and objects which is absent in OOP but very important in COP.
  3. § Mark Lee Smith Email said on :
    savinov:

    OOP doesn't specify whether objects are passed by value or reference. That's an artifact of the language, rather than the object model. You're obviously quite happy to push the idea that this distinguishes OOP and COP, but there are many OO languages that support passing objects by value or by reference.

    It would be perfectly possible to reify references using structs in C#, in the same way that your concepts reify them in COP. Merging structs and classes into a single form would be a largely syntactic enhancement.

    You also use inheritance to refer strictly to single hierarchical inheritance. This is to strict. There are many many different approaches to inheritance and not all of them emply a hiearchy. Some people would consider inclusion as a form of inheritance.

    I'd be very interested to know what other features COP offers, because having skimmed a few of the papers linked to on this site I haven't noticed any game changers.
  4. § Mark Lee Smith Email said on :
    I should also add that OOP doesn't imply classes; there are classless approaches to OOP like prototype-based programming and object-based programming.

    You may not consider COP to be a fork of OOP, but it adds no more or less than Subject-oriented programming, Context-oriented programming or Ambient-oriented programming etc. They all change certain things about OOP; add certain features etc. But they're all OOP at heart.

    Maybe I'm missing something?
  5. § savinov® Email said on :
    Mark Lee Smith:

    "OOP doesn't specify whether objects are passed by value or reference. That's an artifact of the language, rather than the object model."

    Strictly speaking you are right, but it is because OOP does not make big difference between values and objects and, as a consequence, the way they are passed is already a minor issue which can be implemented in different ways in different languages.

    "You're obviously quite happy to push the idea that this distinguishes OOP and COP, but there are many OO languages that support passing objects by value or by reference. "

    In COP, values and objects are opposed and to say "an object is passed by-value" is non-sense. In COP, an object is defined to be passed only by-reference -- otherwise it is not an object.

    "It would be perfectly possible to reify references using structs in C#, in the same way that your concepts reify them in COP. Merging structs and classes into a single form would be a largely syntactic enhancement."

    If we talk about values and objects then you are right -- it is not very difficult. But the main concern in COP is how objects are represented and how they are accessed, i.e., COP is about references (which are values). In this case coupling structs and classes is not a syntactic sugar because it changes how a program is viewed, how it functions and how it is written.

    "I'd be very interested to know what other features COP offers, because having skimmed a few of the papers linked to on this site I haven't noticed any game changers."

    For example, a great deal of the program complexity is not in objects (in classes) -- some functions are concentrated in references which are active elements of the program (and modularize its cross-cutting concerns). Another example, we need an additional keyword 'sub' which is opposed to the conventional 'super'. The third change is that each concept has two methods which need to be coordinated. The third important feature is that there are two (dual) overriding strategy: base methods can override extensions and (as usual) extensions can override base methods.

    "You also use inheritance to refer strictly to single hierarchical inheritance. This is to strict. There are many many different approaches to inheritance and not all of them emply a hiearchy. Some people would consider inclusion as a form of inheritance."

    Inclusion turns into inheritance under certain simplifying conditions (as well as COP turns into OOP under these conditions). But the opposite is not true.
  6. § Mark Lee Smith Email said on :
    "Strictly speaking you are right, but it is because OOP does not make big difference between values and objects and, as a consequence, the way they are passed is already a minor issue which can be implemented in different ways in different languages."

    So you're moving something usually left to the language into the paradigm; that's reasonable, but you're not adding anything that wasn't there before.

    "In COP, values and objects are opposed and to say "an object is passed by-value" is non-sense. In COP, an object is defined to be passed only by-reference -- otherwise it is not an object."

    Now we're arguing about terminology – you can define object to mean whatever you want, it doesn't change the fact that many languages allow objects to be passed by value... meaning that you can implement concepts, as you call them.

    And as far as I call tell, there's nothing stopping an OO language from providing inclusion in-place of standard hierarchical inheritance. (It's been a while but) I'm pretty sure Beta provided an inheritance mechanism with similar capabilities (as well as the ability to pass objects by value or reference).

    I'm just not seeing the big deal here. It seems like all of the things you've described fit well into existing OOP. Which is why I describe COP as a fork – another false dichotomy.
  7. § savinov® Email said on :
    "...it doesn't change the fact that many languages allow objects to be passed by value... meaning that you can implement concepts, as you call them."

    Unfortunately, most contemporary OO languages do [b]not[/b] suppport passing objects by-value -- and that is absolutely correct from the point of view of the OO paradigm (I would also do so if I had to implement an OO language).

    "And as far as I call tell, there's nothing stopping an OO language from providing inclusion in-place of standard hierarchical inheritance. (It's been a while but) I'm pretty sure Beta provided an inheritance mechanism with similar capabilities (as well as the ability to pass objects by value or reference)."

    Here is a very short comparison of inheritance vs. inclusion:

    Inheritance: all objects exist in one flat space; one base has one extension; all segments have one platform-specific reference (identity) provided by the compiler

    Inclusion: all objects exist in a hierarchy (as a tree); one base has many extensions; all segments have their own application-specific references (identities) provided by the programmer

    Beta provides reverse overriding strategy (where base methods override the methods of the extensions) via so called inner methods, which is a very important and underestimated feature. The same reverse overriding strategy exists in COP but is implemented differently via reference methods of concepts (one method has two definition: one in reference class and one in object class). So in Beta, objects still are normal objects living in one flat space without a hierarchy but with the addition of the mechanism of inner methods.

    So I do not see how inheritance (even with the Beta inner methods) can be converted to inclusion.

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)
This is a captcha-picture. It is used to prevent mass-access by robots.
Please enter the characters from the image above. (case insensitive)
Contact. ©2014 by Alexandr Savinov. blog software / web hosting / monetize.
Design & icons by N.Design Studio. Skin by Tender Feelings / Evo Factory.