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