Hani
The world is more complex than you think. Here is the situation we faced with Sniff+ the table export symbol was corrupted and we got accesses to variables that were not in the model. So the accesses were in methods inside the model, but we could not be sure that the variables were in because Sniff+ was plain corrupted.
Roel faced the same problem with CDT.
- If there is an inheritance definition to a class that is not in the
model, the inheritance definition is not a stub since it is in the model and may be one class is not.
if a such inheritance definition (invocation, access, etc.) is considered inside the imported model i think thus that mathematically is very stupide to consider the inherited class (the invoked methode, the accessed class/attribute, etc) outside the model.
We do not consider it. The importer does it and stub means that the entity was not found by the importer.
Just think and see the software/model as a graph and you will understand what i want to say. However, this is what i think.
This is not that we do not understand what you say. This is that we explained to you the semantics of stub and that you want another one.
- You can get a method that is not imported but referenced and it
is a stub because of the same problem. A method is not a stub because it is in a stub class. A method is a stub because at the end of the import phase it was not imported but referenced.
I do not see how you can import a method without importing its class.
Because you work in VW and that the importer is doing a good job but this is not always the case.
So if a method is inside the imported model but its class is defined outside the model (this happens only in smalltalk models) the both should not be stub.
No. Because stub means that we did not find the method when importing. No more!
Now, when a class is defined inside the imported model but some of its methods are packaged outside the model, such methods should be marked as stubs.
I do not know what you mean by packaged outside. Either they are class extensions or they were not found by the importer and in such a case they should be marked as stub and if tis is not the case then this is a bug of the importer.
I suggest that you define another property for encoding what you want: called it impactedByStub or inContactOfStub.
I do not see the same thing, but what i see clearly that moose is already very complicated with a lot of properties and what is inutile, so i think that reducing such things is better to do.
Sorry but you should not change the semantics of stub.
whatever we can talk about that after my vacation.
hani
Stef
On Aug 8, 2008, at 6:21 PM, Hani ABDEEN wrote:
new version of Moose Development
FAMIXMethod>>isStub
isStub "a fAMIXMethod is stub if it is declared as stub or if it belongs to a stub class"
^super isStub or: [self belongsTo isStub]. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev