Hi hani
I was checking your code. I do not think that this is correct. Did you read the email we sent about the topic before summer holidays on this topic?
AbstractStructuralEntiy>>isStub
"a FAMIXStructuralEntity is stub if its declared as stub or if it belongs to a stub famix element, or if we do not know really it belongs to which famix entity (self belongsTo isSymbol -> istrue)"
^super isStub or: [self belongsTo notNil and: [self belongsTo isSymbol or: [self belongsTo isStub]]]
FAMIXInvocation>>isStub "a FAMIXInvocation is stub if all its candidate -invoked- methodes, are stub, or if the invocation is done by a stub method, or if the invocation has no candidate" ^self candidateList isNil or: [self candidateList isEmpty or: [(self candidateList allSatisfy: [:mtd| mtd isStub]) or: [self invokedBy isNil or: [self invokedBy isStub]]]]
Stubbyness is an import property and it is not transitive. You can have an attribute that is imported and its class is a stub because the importer leaked. Now of course this situation does not make sense but this is the state of the import (we would all prefer that this imported did not leak but it is in C++ and we do not control it).
Now you need to compute a new property called for example completelyImported. So we prefer that you introduce an extra property (related to stubbyness) and that thes methods are dealing with this.
So I will remove these two methods from Moose and invite you to define a completelyImported property and its computation. If you follow our suggesting we will integrate them in Moose if there are tests.
Stef and Doru
Hi!
Stubbyness is an import property and it is not transitive. You can have an attribute that is imported and its class is a stub because the importer leaked. Now of course this situation does not make sense but this is the state of the import (we would all prefer that this imported did not leak but it is in C++ and we do not control it).
What do you mean by "leak"? I understand that a leaking importer is a bugged one. Am i right?
Cheers, Alexandre
leaking was meaning that may be sniff+ is losing information so when you uery it you do not get a wonderful complete model but a model with holes.
Stef
On Oct 31, 2008, at 12:02 AM, Alexandre Bergel wrote:
Hi!
Stubbyness is an import property and it is not transitive. You can have an attribute that is imported and its class is a stub because the importer leaked. Now of course this situation does not make sense but this is the state of the import (we would all prefer that this imported did not leak but it is in C++ and we do not control it).
What do you mean by "leak"? I understand that a leaking importer is a bugged one. Am i right?
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
ok you can remove these methods from Moose. actually i will re-integrate them in Cook and later i will see which name i should give to this property.
What about:
FAMIXInheritanceDefinition>>isStub ? FAMIXAccess>>isStub ? FAMIXAttribute>>isStub ? FAMIXNamespace>>isStub ? FAMIXPackage>>isStub ?
I suggest that you think the same thing and you will remove these methods from Moose, no?
Hani
On Oct 30, 2008, at 11:46 AM, Stéphane Ducasse wrote:
Hi hani
I was checking your code. I do not think that this is correct. Did you read the email we sent about the topic before summer holidays on this topic?
AbstractStructuralEntiy>>isStub
"a FAMIXStructuralEntity is stub if its declared as stub or if it belongs to a stub famix element, or if we do not know really it belongs to which famix entity (self belongsTo isSymbol -> istrue)"
^super isStub or: [self belongsTo notNil and: [self belongsTo isSymbol or: [self belongsTo isStub]]]
FAMIXInvocation>>isStub "a FAMIXInvocation is stub if all its candidate -invoked- methodes, are stub, or if the invocation is done by a stub method, or if the invocation has no candidate" ^self candidateList isNil or: [self candidateList isEmpty or: [(self candidateList allSatisfy: [:mtd| mtd isStub]) or: [self invokedBy isNil or: [self invokedBy isStub]]]]
Stubbyness is an import property and it is not transitive. You can have an attribute that is imported and its class is a stub because the importer leaked. Now of course this situation does not make sense but this is the state of the import (we would all prefer that this imported did not leak but it is in C++ and we do not control it).
Now you need to compute a new property called for example completelyImported. So we prefer that you introduce an extra property (related to stubbyness) and that thes methods are dealing with this.
So I will remove these two methods from Moose and invite you to define a completelyImported property and its computation. If you follow our suggesting we will integrate them in Moose if there are tests.
Stef and Doru
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Oct 31, 2008, at 6:02 PM, Hani ABDEEN wrote:
ok you can remove these methods from Moose. actually i will re-integrate them in Cook and later i will see which name i should give to this property.
rename it now this is one click call it completelyImported and we add it directly to moose.
What about:
FAMIXInheritanceDefinition>>isStub ? FAMIXAccess>>isStub ? FAMIXAttribute>>isStub ? FAMIXNamespace>>isStub ? FAMIXPackage>>isStub ?
I suggest that you think the same thing and you will remove these methods from Moose, no?
Arg I missed these ones. The UI of stroe is not that good.
Hani
On Oct 30, 2008, at 11:46 AM, Stéphane Ducasse wrote:
Hi hani
I was checking your code. I do not think that this is correct. Did you read the email we sent about the topic before summer holidays on this topic?
AbstractStructuralEntiy>>isStub
"a FAMIXStructuralEntity is stub if its declared as stub or if it belongs to a stub famix element, or if we do not know really it belongs to which famix entity (self belongsTo isSymbol -> istrue)"
^super isStub or: [self belongsTo notNil and: [self belongsTo isSymbol or: [self belongsTo isStub]]]
FAMIXInvocation>>isStub "a FAMIXInvocation is stub if all its candidate -invoked- methodes, are stub, or if the invocation is done by a stub method, or if the invocation has no candidate" ^self candidateList isNil or: [self candidateList isEmpty or: [(self candidateList allSatisfy: [:mtd| mtd isStub]) or: [self invokedBy isNil or: [self invokedBy isStub]]]]
Stubbyness is an import property and it is not transitive. You can have an attribute that is imported and its class is a stub because the importer leaked. Now of course this situation does not make sense but this is the state of the import (we would all prefer that this imported did not leak but it is in C++ and we do not control it).
Now you need to compute a new property called for example completelyImported. So we prefer that you introduce an extra property (related to stubbyness) and that thes methods are dealing with this.
So I will remove these two methods from Moose and invite you to define a completelyImported property and its computation. If you follow our suggesting we will integrate them in Moose if there are tests.
Stef and Doru
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
ok, you can rename them in Moose. I prefer that you do that yourself: this way you can fix the code as you want.
anyway, I do not think that the name #completelyImported is a good name for all these methods,
what moose developers think?
hani
On Nov 1, 2008, at 09:56 AM, stéphane ducasse wrote:
On Oct 31, 2008, at 6:02 PM, Hani ABDEEN wrote:
ok you can remove these methods from Moose. actually i will re-integrate them in Cook and later i will see which name i should give to this property.
rename it now this is one click call it completelyImported and we add it directly to moose.
What about:
FAMIXInheritanceDefinition>>isStub ? FAMIXAccess>>isStub ? FAMIXAttribute>>isStub ? FAMIXNamespace>>isStub ? FAMIXPackage>>isStub ?
I suggest that you think the same thing and you will remove these methods from Moose, no?
Arg I missed these ones. The UI of stroe is not that good.
Hani
On Oct 30, 2008, at 11:46 AM, Stéphane Ducasse wrote:
Hi hani
I was checking your code. I do not think that this is correct. Did you read the email we sent about the topic before summer holidays on this topic?
AbstractStructuralEntiy>>isStub
"a FAMIXStructuralEntity is stub if its declared as stub or if it belongs to a stub famix element, or if we do not know really it belongs to which famix entity (self belongsTo isSymbol -> istrue)"
^super isStub or: [self belongsTo notNil and: [self belongsTo isSymbol or: [self belongsTo isStub]]]
FAMIXInvocation>>isStub "a FAMIXInvocation is stub if all its candidate -invoked- methodes, are stub, or if the invocation is done by a stub method, or if the invocation has no candidate" ^self candidateList isNil or: [self candidateList isEmpty or: [(self candidateList allSatisfy: [:mtd| mtd isStub]) or: [self invokedBy isNil or: [self invokedBy isStub]]]]
Stubbyness is an import property and it is not transitive. You can have an attribute that is imported and its class is a stub because the importer leaked. Now of course this situation does not make sense but this is the state of the import (we would all prefer that this imported did not leak but it is in C++ and we do not control it).
Now you need to compute a new property called for example completelyImported. So we prefer that you introduce an extra property (related to stubbyness) and that thes methods are dealing with this.
So I will remove these two methods from Moose and invite you to define a completelyImported property and its computation. If you follow our suggesting we will integrate them in Moose if there are tests.
Stef and Doru
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
On Nov 3, 2008, at 10:48 AM, Hani ABDEEN wrote:
ok, you can rename them in Moose. I prefer that you do that yourself: this way you can fix the code as you want.
I will see may be this is the best solution
anyway, I do not think that the name #completelyImported is a good name for all these methods,
so what is a good name? you could be a bit more constructive in your remarks.
Stef
what moose developers think?
hani
On Nov 1, 2008, at 09:56 AM, stéphane ducasse wrote:
On Oct 31, 2008, at 6:02 PM, Hani ABDEEN wrote:
ok you can remove these methods from Moose. actually i will re-integrate them in Cook and later i will see which name i should give to this property.
rename it now this is one click call it completelyImported and we add it directly to moose.
What about:
FAMIXInheritanceDefinition>>isStub ? FAMIXAccess>>isStub ? FAMIXAttribute>>isStub ? FAMIXNamespace>>isStub ? FAMIXPackage>>isStub ?
I suggest that you think the same thing and you will remove these methods from Moose, no?
Arg I missed these ones. The UI of stroe is not that good.
Hani
On Oct 30, 2008, at 11:46 AM, Stéphane Ducasse wrote:
Hi hani
I was checking your code. I do not think that this is correct. Did you read the email we sent about the topic before summer holidays on this topic?
AbstractStructuralEntiy>>isStub
"a FAMIXStructuralEntity is stub if its declared as stub or if it belongs to a stub famix element, or if we do not know really it belongs to which famix entity (self belongsTo isSymbol -> istrue)"
^super isStub or: [self belongsTo notNil and: [self belongsTo isSymbol or: [self belongsTo isStub]]]
FAMIXInvocation>>isStub "a FAMIXInvocation is stub if all its candidate -invoked- methodes, are stub, or if the invocation is done by a stub method, or if the invocation has no candidate" ^self candidateList isNil or: [self candidateList isEmpty or: [(self candidateList allSatisfy: [:mtd| mtd isStub]) or: [self invokedBy isNil or: [self invokedBy isStub]]]]
Stubbyness is an import property and it is not transitive. You can have an attribute that is imported and its class is a stub because the importer leaked. Now of course this situation does not make sense but this is the state of the import (we would all prefer that this imported did not leak but it is in C++ and we do not control it).
Now you need to compute a new property called for example completelyImported. So we prefer that you introduce an extra property (related to stubbyness) and that thes methods are dealing with this.
So I will remove these two methods from Moose and invite you to define a completelyImported property and its computation. If you follow our suggesting we will integrate them in Moose if there are tests.
Stef and Doru
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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Nov 3, 2008, at 20:45 PM, Stéphane Ducasse wrote:
On Nov 3, 2008, at 10:48 AM, Hani ABDEEN wrote:
ok, you can rename them in Moose. I prefer that you do that yourself: this way you can fix the code as you want.
I will see may be this is the best solution
anyway, I do not think that the name #completelyImported is a good name for all these methods,
so what is a good name? you could be a bit more constructive in your remarks.
I think that I already said that the name for me such methods should be #isStub but you said that it is not good
I wish that I am more constructive now.
hani
Stef
what moose developers think?
hani
On Nov 1, 2008, at 09:56 AM, stéphane ducasse wrote:
On Oct 31, 2008, at 6:02 PM, Hani ABDEEN wrote:
ok you can remove these methods from Moose. actually i will re-integrate them in Cook and later i will see which name i should give to this property.
rename it now this is one click call it completelyImported and we add it directly to moose.
What about:
FAMIXInheritanceDefinition>>isStub ? FAMIXAccess>>isStub ? FAMIXAttribute>>isStub ? FAMIXNamespace>>isStub ? FAMIXPackage>>isStub ?
I suggest that you think the same thing and you will remove these methods from Moose, no?
Arg I missed these ones. The UI of stroe is not that good.
Hani
On Oct 30, 2008, at 11:46 AM, Stéphane Ducasse wrote:
Hi hani
I was checking your code. I do not think that this is correct. Did you read the email we sent about the topic before summer holidays on this topic?
AbstractStructuralEntiy>>isStub
"a FAMIXStructuralEntity is stub if its declared as stub or if it belongs to a stub famix element, or if we do not know really it belongs to which famix entity (self belongsTo isSymbol -> istrue)"
^super isStub or: [self belongsTo notNil and: [self belongsTo isSymbol or: [self belongsTo isStub]]]
FAMIXInvocation>>isStub "a FAMIXInvocation is stub if all its candidate -invoked- methodes, are stub, or if the invocation is done by a stub method, or if the invocation has no candidate" ^self candidateList isNil or: [self candidateList isEmpty or: [(self candidateList allSatisfy: [:mtd| mtd isStub]) or: [self invokedBy isNil or: [self invokedBy isStub]]]]
Stubbyness is an import property and it is not transitive. You can have an attribute that is imported and its class is a stub because the importer leaked. Now of course this situation does not make sense but this is the state of the import (we would all prefer that this imported did not leak but it is in C++ and we do not control it).
Now you need to compute a new property called for example completelyImported. So we prefer that you introduce an extra property (related to stubbyness) and that thes methods are dealing with this.
So I will remove these two methods from Moose and invite you to define a completelyImported property and its computation. If you follow our suggesting we will integrate them in Moose if there are tests.
Stef and Doru
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
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
ok, you can rename them in Moose. I prefer that you do that yourself: this way you can fix the code as you want.
I will see may be this is the best solution
anyway, I do not think that the name #completelyImported is a good name for all these methods,
so what is a good name? you could be a bit more constructive in your remarks.
I think that I already said that the name for me such methods should be #isStub but you said that it is not good
you look kind of funny to me and not trying to make progress. So I summarized once more
- isStub IS NOT WHAT YOU THINK IT IS. I think that I already spent a lot of time explaining why on this list since this summer.
- logical implication isStub will not be what you suggest.
I wish that I am more constructive now.
Not at all, but I imagine that you do not really understand that your behavior is weird. But this is your life not mine.
So I will rename the method isCompletelyImported and add a property and the discussion is close. Thanks for your great suggestion.
Stef
hani
Stef
what moose developers think?
hani
On Nov 1, 2008, at 09:56 AM, stéphane ducasse wrote:
On Oct 31, 2008, at 6:02 PM, Hani ABDEEN wrote:
ok you can remove these methods from Moose. actually i will re-integrate them in Cook and later i will see which name i should give to this property.
rename it now this is one click call it completelyImported and we add it directly to moose.
What about:
FAMIXInheritanceDefinition>>isStub ? FAMIXAccess>>isStub ? FAMIXAttribute>>isStub ? FAMIXNamespace>>isStub ? FAMIXPackage>>isStub ?
I suggest that you think the same thing and you will remove these methods from Moose, no?
Arg I missed these ones. The UI of stroe is not that good.
Hani
On Oct 30, 2008, at 11:46 AM, Stéphane Ducasse wrote:
Hi hani
I was checking your code. I do not think that this is correct. Did you read the email we sent about the topic before summer holidays on this topic?
AbstractStructuralEntiy>>isStub
"a FAMIXStructuralEntity is stub if its declared as stub or if it belongs to a stub famix element, or if we do not know really it belongs to which famix entity (self belongsTo isSymbol -> istrue)"
^super isStub or: [self belongsTo notNil and: [self belongsTo isSymbol or: [self belongsTo isStub]]]
FAMIXInvocation>>isStub "a FAMIXInvocation is stub if all its candidate -invoked- methodes, are stub, or if the invocation is done by a stub method, or if the invocation has no candidate" ^self candidateList isNil or: [self candidateList isEmpty or: [(self candidateList allSatisfy: [:mtd| mtd isStub]) or: [self invokedBy isNil or: [self invokedBy isStub]]]]
Stubbyness is an import property and it is not transitive. You can have an attribute that is imported and its class is a stub because the importer leaked. Now of course this situation does not make sense but this is the state of the import (we would all prefer that this imported did not leak but it is in C++ and we do not control it).
Now you need to compute a new property called for example completelyImported. So we prefer that you introduce an extra property (related to stubbyness) and that thes methods are dealing with this.
So I will remove these two methods from Moose and invite you to define a completelyImported property and its computation. If you follow our suggesting we will integrate them in Moose if there are tests.
Stef and Doru
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
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
I think that i did error when I integrated some methods in moose and spent my time on something that do not concerne me.
So I PRESENT ALL MY EXCUSES TO MOOSE COMMUNITY AND I SWEAR THAT SUCH A THING WILL NEVER BE REPEATED.
Stephan, One thing else, if I look to you as a kind of funny and I do not trying to make progress, I suggest that you remove these methods from moose and consider that they had never been implemented. I am sure that you do not need my code and surely you can do better.
On Nov 4, 2008, at 21:14 PM, Stéphane Ducasse wrote:
ok, you can rename them in Moose. I prefer that you do that yourself: this way you can fix the code as you want.
I will see may be this is the best solution
anyway, I do not think that the name #completelyImported is a good name for all these methods,
so what is a good name? you could be a bit more constructive in your remarks.
I think that I already said that the name for me such methods should be #isStub but you said that it is not good
you look kind of funny to me and not trying to make progress. So I summarized once more
- isStub IS NOT WHAT YOU THINK IT IS. I think that I already
spent a lot of time explaining why on this list since this summer.
- logical implication isStub will not be what you suggest.
I wish that I am more constructive now.
Not at all, but I imagine that you do not really understand that your behavior is weird. But this is your life not mine.
So I will rename the method isCompletelyImported and add a property and the discussion is close. Thanks for your great suggestion.
Stef
hani
Stef
what moose developers think?
hani
On Nov 1, 2008, at 09:56 AM, stéphane ducasse wrote:
On Oct 31, 2008, at 6:02 PM, Hani ABDEEN wrote:
ok you can remove these methods from Moose. actually i will re-integrate them in Cook and later i will see which name i should give to this property.
rename it now this is one click call it completelyImported and we add it directly to moose.
What about:
FAMIXInheritanceDefinition>>isStub ? FAMIXAccess>>isStub ? FAMIXAttribute>>isStub ? FAMIXNamespace>>isStub ? FAMIXPackage>>isStub ?
I suggest that you think the same thing and you will remove these methods from Moose, no?
Arg I missed these ones. The UI of stroe is not that good.
Hani
On Oct 30, 2008, at 11:46 AM, Stéphane Ducasse wrote:
> Hi hani > > I was checking your code. I do not think that this is correct. > Did you read the email we sent about the topic before summer > holidays > on this topic? > > AbstractStructuralEntiy>>isStub > > "a FAMIXStructuralEntity is stub if its declared as stub or if > it > belongs to a stub famix element, or if we do not know really it > belongs to which famix entity (self belongsTo isSymbol -> > istrue)" > > ^super isStub or: [self belongsTo notNil and: [self belongsTo > isSymbol or: [self belongsTo isStub]]] > > FAMIXInvocation>>isStub > "a FAMIXInvocation is stub if all its candidate -invoked- > methodes, > are stub, or if the invocation is done by a stub method, or if > the > invocation has no candidate" > ^self candidateList isNil > or: [self candidateList isEmpty > or: [(self candidateList allSatisfy: [:mtd| mtd isStub]) > or: [self invokedBy isNil or: [self invokedBy isStub]]]] > > Stubbyness is an import property and it is not transitive. > You can have an attribute that is imported and its class is a > stub > because the importer leaked. > Now of course this situation does not make sense but this is the > state > of the import (we would all prefer that this > imported did not leak but it is in C++ and we do not control > it). > > Now you need to compute a new property called for example > completelyImported. > So we prefer that you introduce an extra property (related to > stubbyness) > and that thes methods are dealing with this. > > So I will remove these two methods from Moose and invite you to > define > a completelyImported property and its computation. > If you follow our suggesting we will integrate them in Moose if > there > are tests. > > Stef and Doru > > > > _______________________________________________ > 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
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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I think that i did error when I integrated some methods in moose and spent my time on something that do not concerne me.
So I PRESENT ALL MY EXCUSES TO MOOSE COMMUNITY AND I SWEAR THAT SUCH A THING WILL NEVER BE REPEATED.
This is not the problem we can fix that there is no problem per se. I think that if we rename your method and fix isStub (which was broken by doru before). then this will be fixed and moose will get better. So this is positive.
Stephan, One thing else, if I look to you as a kind of funny and I do not trying to make progress, I suggest that you remove these methods from moose and consider that they had never been implemented. I am sure that you do not need my code and surely you can do better.
This is not the point. Read my mail! I asked for a better name for the new method not to get back isStub
Now you can try to understand anything wrong if you want. I'm not the guy that will let you play a victim of me :)
So I will merge a bit everything, rename what should be renamed and check isStub implementation, as soon as I have some time. Stef
-
Alexandre Bergel -
Hani ABDEEN -
stéphane ducasse -
Stéphane Ducasse -
Stéphane Ducasse