Hi!
I would like to discuss about MooseModel class>>ownerOf: I understand the implementation. But this leads to a strange behavior. For example, the following fails time to time: element := MooseEntity new. self assert: (element mooseModel isNil). It fails since I have written tests about the id generation. And the element may have a mooseID of a previous object. What should we do? I can remove the tests about the ID generation, but removing tests is never good. Would it be possible to use the privateState to store the mooseModel? Are the hypothesis why we have changed the reference of the mooseModel still valid? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi Alex,
On 23 Mar 2011, at 03:00, Alexandre Bergel wrote: > Hi! > > I would like to discuss about MooseModel class>>ownerOf: > I understand the implementation. But this leads to a strange behavior. > > For example, the following fails time to time: > element := MooseEntity new. > self assert: (element mooseModel isNil). > > It fails since I have written tests about the id generation. And the element may have a mooseID of a previous object. I cannot see how this would happen. I tried the following and it never halted: (1 to: 10000) do: [:x | MooseEntity new mooseModel isNil ifFalse: [self halt] ] > What should we do? I can remove the tests about the ID generation, but removing tests is never good. Unless the test does not test the right thing :). > Would it be possible to use the privateState to store the mooseModel? Are the hypothesis why we have changed the reference of the mooseModel still valid? If you look closely in MooseEntity, the implementation goes like this: MooseEntity>>mooseModel ^ self privateState model MooseEntityState>>model ^self attributeAt: #privateModel ifAbsent: [MooseModel ownerOf: self entity] So for most important cases mooseModel is stored in EntityState. The exception are the entities with MinimalState. The idea of MinimalState was to offer an entity the possibility of having no slots allocated so to not consume memory. This was specifically interesting for associations which do not really have properties on their own. However, in Pharo it looks like this behavior was removed so everything works with DefaultState. We should re-add this logic because it saves a bit of space. In any case, for those entities that do not have a model, it is looked up by the ID. It is slower, but it is also very unlikely that this behavior will happen. So, all in all, the behavior of ownerOf: is still of interest. Cheers, Doru > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
>> It fails since I have written tests about the id generation. And the element may have a mooseID of a previous object.
> > I cannot see how this would happen. > > I tried the following and it never halted: > > (1 to: 10000) do: [:x | > MooseEntity new mooseModel isNil ifFalse: [self halt] ] Doit the following: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | model | model := MooseModel new. MooseElement resetIDGeneration. model add: MooseElement new. MooseElement resetIDGeneration. self assert: [MooseElement new mooseModel isNil] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sorry, I should have made my previous email more explicit. >> What should we do? I can remove the tests about the ID generation, but removing tests is never good. > > Unless the test does not test the right thing :). > >> Would it be possible to use the privateState to store the mooseModel? Are the hypothesis why we have changed the reference of the mooseModel still valid? ... > So, all in all, the behavior of ownerOf: is still of interest. My tests are a bit less expressive then since "MooseEntity new mooseModel" is not always nil. But this is ok for now. Alexandre > >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |