14 Jan
2010
14 Jan
'10
1:23 p.m.
Hi there
I would like your opinion on Issue 287: allModelPackages does not retrieve pure extension
packages
One proposed solution is to set the isStub flag on package/namespace imported because of
stub classes (i.e., not specifically requested by the user).
For now, this is a smalltalk specific problem. However, it would be good if the semantic
is clearly agreed between the importers.
--
Simon
15 Jan
15 Jan
10:27 a.m.
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:
Hi there
I would like your opinion on Issue 287: allModelPackages does not
retrieve pure extension packages
One proposed solution is to set the isStub flag on package/namespace
imported because of stub classes (i.e., not specifically requested
by the user).
For now, this is a smalltalk specific problem. However, it would be
good if the semantic is clearly agreed between the importers.
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of
problem understanding."
10:53 a.m.
On Jan 15, 2010, at 10:27 AM, Tudor Girba wrote:
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.
I would not change the meaning of isStub.
And add a new property like I suggested to hani and doru :) to denote that the entity is
not completely imported.
Cheers,
Doru
On 14 Jan 2010, at 13:23, Simon Denier wrote:
Hi there
I would like your opinion on Issue 287: allModelPackages does not retrieve pure extension
packages
One proposed solution is to set the isStub flag on package/namespace imported because of
stub classes (i.e., not specifically requested by the user).
For now, this is a smalltalk specific problem. However, it would be good if the semantic
is clearly agreed between the importers.
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11 a.m.
On 15 janv. 2010, at 10:27, Tudor Girba wrote:
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.
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.
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:
--
Simon
Hi there
I would like your opinion on Issue 287: allModelPackages does not retrieve pure extension
packages
One proposed solution is to set the isStub flag on package/namespace imported because of
stub classes (i.e., not specifically requested by the user).
For now, this is a smalltalk specific problem. However, it would be good if the semantic
is clearly agreed between the importers.
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:11 a.m.
Hi Simon,
I actually meant that "if we explicitly choose directly classes (and
not packages) that happen to also be in A then all the packages that
extend these classes will not be stub "
--
www.tudorgirba.com
"One cannot do more than one can do."
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.
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
I do not like the implication of isComplete, because a model will not
be complete unless it contains all details of the subject.
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.
Yes.
Doru
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:
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi there
I would like your opinion on Issue 287: allModelPackages does not
retrieve pure extension packages
One proposed solution is to set the isStub flag on package/
namespace imported because of stub classes (i.e., not specifically
requested by the user).
For now, this is a smalltalk specific problem. However, it would
be good if the semantic is clearly agreed between the importers.
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of
problem understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:20 p.m.
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.
Not sure I get the rationale for the second case. - 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
I do not like the implication of isComplete, because a model will not be complete unless
it contains all details of the subject. 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.
Yes.
Doru
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:
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi there
I would like your opinion on Issue 287: allModelPackages does not retrieve pure extension
packages
One proposed solution is to set the isStub flag on package/namespace imported because of
stub classes (i.e., not specifically requested by the user).
For now, this is a smalltalk specific problem. However, it would be good if the semantic
is clearly agreed between the importers.
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5236
days inactive
5237
days old
5 comments
3 participants
participants (3)
-
Simon Denier -
Stéphane Ducasse -
Tudor Girba