The world is more complex than you think.
Here is the situation we faced with Sniff+ the table export symbol was
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
> - 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
methods are packaged outside the model, such methods should be marked
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
then this is a bug of the importer.
> I suggest that you define another property for encoding what you
> 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.
> On Aug 8, 2008, at 6:21 PM, Hani ABDEEN wrote:
>> new version of Moose Development
>> "a fAMIXMethod is stub if it is declared as stub or if it belongs
>> a stub class"
>> ^super isStub or: [self belongsTo isStub].
>> Moose-dev mailing list
> Moose-dev mailing list
Moose-dev mailing list