|
| Re: Role migration - is it really needed? [message #507767 is a reply to message #507623] |
Thu, 14 January 2010 15:36   |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
| Eugene Hutorny wrote on Thu, 14 January 2010 01:46 | I noticed somewhere in your plans to support role migration.
|
Oh please, were did it say it's planned?
It's included since version 1.2.5 
(see http://www.objectteams.org/def/1.2/s6.html#s6.2.e )
| Quote: |
Do you have a good example to illustrate role migration?
One which I seen in the literature IMHO is just wrong modelling:
| Quote: |
Mary works for The System Enterprise and when she leaves the enterprise a newcomer should be able to continue her work at the state Mary has left it
|
|
My example would be similar: a Lecturer (role) owns a deck of slides.
As the Person falls ill, a substitute is called to act as "the same
Lecturer" with the same slides etc.
| Quote: |
It is modelled an Mary's role in The System Enterprise is transferred from one person to another. I think this model is missing one distinct entity - Established Post. With this entity the model will look like this:
The System Enterprise has zero one or more Established Post
Position has no behaviour, only state, e.g. it can not act.
When The System Enterprise hires Mary she takes one of vacant position - it can be modelled as a ternary relationship (Company as Employer,EstablishedPost as Position,Person as Employee) or two separate relationships.
When Mary leaves the company, she takes all her belongings but leaves all work-related state in the scope of position.
When a newcomer takes the same position he takes the state kept in EstablishedPost and continues.
What do you think?
|
Your model obviously works, too. The difference is, whether or not you
are forced by the language to make EstablishedPost explicit.
It may just be very convenient to speak of "the Lecturer" owning the slides,
without explicit distinction whether I'm talking about the EstablishedPost
or the role associated with this post. The light-weight solution may still have
an implicit concept of established posts: these may be variables of the
enclosing team. (It's a common theme that variables can sometimes be
used as a light-weight concept for roles - without the need for
specific role types).
That said, I haven't yet seen any applications of role migration in real world
OT/J code.
Given that the solution uses a special type IBaseMigratable rather than
new syntax this is pretty light-weight and shouldn't bother those who
don't need it
Or do you think this feature makes the language unneccessarily complex
and more difficult to understand?
|
|
|
|
| Re: Role migration - is it really needed? [message #507997 is a reply to message #507846] |
Fri, 15 January 2010 13:45 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Eugene Hutorny wrote:
> My fear that the role class may become inconsistent for the migration
> duration.
If you are speaking of low level inconsistency, be assured that we try
hard to avoid this: the migrate methods are synchronized, they don't
accept null inputs etc. Thus you should never see a role with a
temporarily missing base link, or inconsistent state of the internal
role cache (as accessed by lifting and the getRole* group of methods).
If you are speaking of application level semantic inconsistencies,
programmers will always be able to create those. If, e.g., the team
keeps explicit references for a role's base object [1] you will be
able to program situations where you will be surprised to find a
base object that is no longer any role's base object.
[1] it shouldn't - the rules about base import tell you to avoid
mentioning the base class within the team. Do you see how we
care about consistency?
However, in clean designs, no part of the program should reference
both a given role *and* its base object. In such designs you should
see no adverse effect of role migration.
But still, you needn't use the feature and if you don't,
its existence shouldn't affect you at all,
you don't have to pay for it.
Stephan
|
|
|
|
| Re: Role migration - is it really needed? [message #567660 is a reply to message #507846] |
Fri, 15 January 2010 13:45 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Eugene Hutorny wrote:
> My fear that the role class may become inconsistent for the migration
> duration.
If you are speaking of low level inconsistency, be assured that we try
hard to avoid this: the migrate methods are synchronized, they don't
accept null inputs etc. Thus you should never see a role with a
temporarily missing base link, or inconsistent state of the internal
role cache (as accessed by lifting and the getRole* group of methods).
If you are speaking of application level semantic inconsistencies,
programmers will always be able to create those. If, e.g., the team
keeps explicit references for a role's base object [1] you will be
able to program situations where you will be surprised to find a
base object that is no longer any role's base object.
[1] it shouldn't - the rules about base import tell you to avoid
mentioning the base class within the team. Do you see how we
care about consistency?
However, in clean designs, no part of the program should reference
both a given role *and* its base object. In such designs you should
see no adverse effect of role migration.
But still, you needn't use the feature and if you don't,
its existence shouldn't affect you at all,
you don't have to pay for it.
Stephan
|
|
|
Powered by
FUDForum. Page generated in 0.03833 seconds
] 
Search
Help
Register
Login
Home
)