Property, method and field relationships with the class

Jan 27, 2012 at 7:10 PM
Edited Jan 27, 2012 at 7:18 PM

Hi - thanks to kostata review issue, I found out that I assumed that the method, property and field cannot exist without the class and that's how this is implemented right now (i.e. a method cannot be displayed without a class id set, because the class element, not the method element, contains a file name and a file path).

I don't know which other languages we are going to support, but maybe my assumptions are wrong in general?

Maybe I should store a file name and a path for all these program elements, instead of a class id?

Jan 27, 2012 at 7:27 PM
My understanding was that supporting C/C++ was in the long term plan. That's sort of the reason we ended up with SrcML as our parser.

On Jan 27, 2012, at 2:10 PM, lordlothar wrote:

From: lordlothar

Hi - thanks to kostata review issue, I found out that I assumed that the method, property and field cannot exist without the class and that's how this is implemented right now (i.e. a method cannot be displayed without a class id set, because the class element not the method element, contains a file name and a file path).

I don't know which other languages we are going to support, but maybe my assumptions are wrong in general?

Maybe I should store a file name and a path for all these program elements, instead of a class id?


Jan 27, 2012 at 7:38 PM
kostata wrote:
  My understanding was that supporting C/C++ was in the long term plan. That's sort of the reason we ended up with SrcML as our parser.

Ok - by does it mean my assumptions were invalid? I don't know what is the current C++ standard, but as I remember, the method definitions are outside the class (.cpp file) - are we planning to store file path and file name for method declaration and other file name and file path for method definition, for the C++language?

Should I delete the class id field and make the method (property and field) an independent element with its own file informations?

Jan 27, 2012 at 7:48 PM
I would think we don't care about the method prototype, if we have it's implementation. So we store only the file name of where the method is implemented, which could be the .h or .cpp file.

I'm wondering if keeping a file name for all program elements, as part of the base class may be overkill. It could be useful if we are doing the delete to update approach that you mentioned in your other post.

On Jan 27, 2012, at 2:38 PM, lordlothar wrote:

From: lordlothar

kostata wrote:
My understanding was that supporting C/C++ was in the long term plan. That's sort of the reason we ended up with SrcML as our parser.

Ok - by does it mean my assumptions were invalid? I don't know what is the current C++ standard, but as I remember, the method definitions are outside the class (.cpp file) - are we planning to store file path and file name for method declaration and other file name and file path for method definition, for the C++language?

Should I delete the class id field and make the method (property and field) an independent element with its own file informations?


Jan 27, 2012 at 8:01 PM

I think I'll live the class relationship as we can benefit from having the base class id, but I'm going to add the path related fields for all the elements - the delete operation will be much faster because we will be able to eliminate the class subquery.

Thanks for help!

Jan 28, 2012 at 1:01 AM

Just to follow up... you guys are absolutely right.  I thought we could do C/C++ after doing C#, since its one of the other more popular languages used in Visual Studio.