[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]