Hi Simon, A long time ago, we decided that isStub should reflect exactly the intention of an analyst of including that entity or not. So, the interpretation would be that if we choose to import an explicit package A, then all packages that extend the classes from A should be stub packages. If we choose the classes in A then all the packages that extend these classes will not be stub. If more semantics are wanted, we could have other properties, like isDerivedAsStub (bad name :)). Maybe an idea would be to add an option in the importing context to allow us to specify what kind of strategy we would want for isStub. Cheers, Doru On 14 Jan 2010, at 13:23, Simon Denier wrote: -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

On 15 janv. 2010, at 10:27, Tudor Girba wrote: Not sure I get the rationale for the second case. I know that there is this ambiguity between things such as isStub and isComplete. At one point, Stéphane started to do something about this but we never completely clarified nor finished. - isStub indicates that the entity is imported through reference by another entity, and not explicitely chosen by the analyst as you say - isComplete should indicate that all properties in this entity are not imported (for example, a class can be a non-stub yet not complete if we choose not to import method body) - isStub => not isComplete Anyway, in the case of packages and given the current importer, we are always in the first case : we explicitly chose packages to import. All other packages should be stub. -- Simon

yes pharo + project writing is sucking all my time. If we look in the archive I imagine I suggested something like uncomplete or something like that to hani.