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].
Hello hani,
I was discussing with roel and we came up with the conclusion that we are losing information with your approach. You are changing the meaning of what a stub is. Been a stub means that you are a reference outside of the model.
Note that been stub was introduced to support fragile importer (some tools like Sniff+ lost information and you get a class without an attribute and accesses to it but no attribute, so the attribute is a stub).
- 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.
- 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 suggest that you define another property for encoding what you want: called it impactedByStub or inContactOfStub.
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
On Aug 9, 2008, at 08:56 AM, Stéphane Ducasse wrote:
Hello hani,
I was discussing with roel and we came up with the conclusion that we are losing information with your approach. You are changing the meaning of what a stub is. Been a stub means that you are a reference outside of the model.
Note that been stub was introduced to support fragile importer (some tools like Sniff+ lost information and you get a class without an attribute and accesses to it but no attribute, so the attribute is a stub).
- 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. 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.
- 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. 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. 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 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.
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
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
just a few meta thoughts
correct me if I'm wrong...
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.
I imagine that you are meaning that in a perfect world, we would be "very stupide" but that in reality we are quite smart in fact. It should be certainly that.
Just think and see the software/model as a graph and you will understand what i want to say.
This is not that we do not understand. Axiom 1: we are smart Axiom 2: we are open to improvement and suggestions :)
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.
Can you elaborate because for now there are certainly features that you do not use but this is not clear if there are "inutile" (but we know we are very stupide) :)
Stef
-
Hani ABDEEN -
Stéphane Ducasse