OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Commented: (ODATA-364) Explicitly state that the restriction that a property MUST NOT have the same name as its containing type only applies to directly declared properties

    [ http://tools.oasis-open.org/issues/browse/ODATA-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33381#action_33381 ] 

Stefan Drees commented on ODATA-364:

the code is complete and standalone runable, if too long to read, just "goto :TLDR" below :-) 

Allthough in the slim examples we test, the derivation enables us to bear with name clashes (as long there is a level between) like in the runnable C++ code below:

#include <iostream>

class Employee {
    static int ID;
    int myId;
    int myManagersId;
    Employee ()
        this->myId = ID++;
        std::cout << "Employee: " << this->myId << "\n";
    void joinRelation (int a)
      { this->myManagersId = a; }
    void leaveRelation ()
      { this->myManagersId = this->myId; }
    void Manager ()
      { std::cout << "Manager( " << this->myId << " ) = " << this->myManagersId << "\n"; }

class Manager : public Employee {
    int mySubordinatesId;
    Manager ()
        std::cout << "Manager: " << this->myId  << "\n";
    void acceptRelation (int a)
      { this->mySubordinatesId = a; }
    void releaseRelation ()
      { this->mySubordinatesId = this->myId; }
    void Employee ()
      { std::cout << "Subordinate( " << this->myId << " ) = " << this->mySubordinatesId << "\n"; }

int Employee::ID = 1;

int main () {
  Manager Jane = Manager();
  Employee Joe = Employee();

  return 0;

Where the outcome should be:

Employee: 1
Manager: 1
Employee: 2
Manager( 2 ) = 2
Subordinate( 1 ) = 1

:TLDR // -------------------------------->

When I understand C++ correctly, than this works, as in C++ a derived class inherits every member of a base class except its constructor, destructor, operator=() members and friends. The default constructor and destructor of the base class are just "called" (by a secret name so to say) every time needed by derived class

But what if you need to call a non-default constructor from your base class in initialization.

Say in the above, if one might have an Employee ( int a ) constructor where one would eplicitly set an ID (jus tas an excuse for using a non-default constructor, bear with me please) how would you call that in the derived class, when there is a member function with that namer?

So you would add an Employee constructor like:

    Employee (int a)
        this->myId = a;
        std::cout << "Employee: " << this->myId << "\n";

and a naive Manager constructor like:

    Manager (int a) : Employee ( a )
        std::cout << "Manager: " << this->myId  << "\n";

but then, it won't compile, unless you play a renaming trick on the member method Employee () in the Manager class or 
state the chained initialization as:
    Manager (int a) : Employee::Employee ( a )
       // ...

that should work and still allow a member function inside Manager class with name Employee.

At least my compilers (gcc and clang) did accept that.

I am not using frameworks myself, so the possible inflexibility (as price for the many out-of-the-box features provided by frameworks) does not occur to me personally, but I am reluctant in stating in general that **this** is never problem in general C++

> Explicitly state that the restriction that a property MUST NOT have the same name as its containing type only applies to directly declared properties
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: ODATA-364
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-364
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData CSDL
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_CSD02
> Chapters 8 and 9 state that 
> - Properties MUST NOT have the same name as the declaring entity type.
> - Properties MUST NOT have the same name as the declaring complex type.
> This sometimes prevents using natural names for properties, e.g. 
> - EntityType Employee
> - EntityType Manager inherits from Employee
> - EntityType Employee has NavigationProperty that leads to the manager
> The natural name for the navigation property is Manager, but prevented by the above rule. So the navigation property has to be named "TheManager" or "manager" (using different case)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]