12 Aug
2008
12 Aug
'08
3:35 p.m.
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.
We do not consider it. The importer does it and stub means that
the entity was not found by the importer.
Because you work in VW and that the importer is doing a good job
but this is not always the case.
Sorry but you should not change the semantics of 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.
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. 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.
whatever we can talk about that after my vacation.
hani
Stef
On Aug 8, 2008, at 6:21 PM, Hani ABDEEN wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev