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:
------------------------------------

TL;DR 
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 {
  private:
    static int ID;
  public:
    int myId;
    int myManagersId;
    Employee ()
      {
        this->myId = ID++;
        joinRelation(this->myId);
        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 {
  public:
    int mySubordinatesId;
    Manager ()
      {
        acceptRelation(this->myId);
        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();
  Joe.Manager();
  Jane.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;
        joinRelation(this->myId);
        std::cout << "Employee: " << this->myId << "\n";
      }

and a naive Manager constructor like:

    Manager (int a) : Employee ( a )
      {
        acceptRelation(this->myId);
        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]