Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Base Imports
Base Imports [message #531139] Mon, 03 May 2010 20:35 Go to next message
Jan Marc Hoffmann is currently offline Jan Marc HoffmannFriend
Messages: 32
Registered: July 2009
Member
Hi all,

I have 2 small design question. Why are there two different imports? regular java imports and base imports? And why cant I base import and import the same class? (using fqn sucks ;P)

And a second one: What about inferred static callouts? Like calls to static base fields? They wont get inferred.

thanks :=)

greetings

Jan Marc
Re: Base Imports [message #531151 is a reply to message #531139] Mon, 03 May 2010 21:39 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1036
Registered: July 2009
Senior Member
OK, one answer at a time:

Jan Marc Hoffmann wrote on Mon, 03 May 2010 16:35
Hi all,

I have 2 small design question. Why are there two different imports? regular java imports and base imports? And why cant I base import and import the same class? (using fqn sucks ;P)



When you bind a role R to a base class B you have some privileges
(decapsulation, callin) that normal Java rules wouldn't grant.
However, I don't want those privileges to "leak", i.e., only the role binding
can make use of decapsulation. The role should then act as the single point
of access towards B.

From this you gain the following guarantees: If you want to find out about
any privileged access to B all you need to inspect are the callout/callin
bindings of role R. Secondly you avoid the confusion that would occur
if you try to compare (==) a role with its base. Should they be considered
the same object? By the OT/J scoping rules such mixed comparison
will generally be impossible, because normally no context has references
to both R and B instances.

The compile checks required for these guarantee are based on the
distinction between regular and base imports, because with a base import
you say: I don't want to directly access this class but only bind a role.

As mentioned, inside R's team all access to B should now go via R.
So I would be curious, if you really need addtional normal access to B,
why would that be? Is that some design that can perhaps be improved to
follow the single point of access rule? Can you give an example?

These rules may force you to think twice, but I believe that this will pay
off, resulting in a design that's easier to maintain etc.

best,
Stephan
Re: Base Imports [message #531320 is a reply to message #531139] Tue, 04 May 2010 14:35 Go to previous message
Jan Marc Hoffmann is currently offline Jan Marc HoffmannFriend
Messages: 32
Registered: July 2009
Member
There are a few cases where you need the basetype.

One of those cases is when you have 2 roles with the same base in the team and would like to use them in a team method. But rather than using a team method on the base of those roles you could also introduce a new super type for the two roles. Which might be a better design.

Or if your team is used for another operation concering the base objects. Like registration or similar.

But after reading your answer I agree that those cases are quite rare and might be an indicator of a bad design.

Thanks for your explanation.

greetings

Jan Marc
Re: Base Imports [message #574077 is a reply to message #531139] Mon, 03 May 2010 21:39 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1036
Registered: July 2009
Senior Member
OK, one answer at a time:

Jan Marc Hoffmann wrote on Mon, 03 May 2010 16:35
> Hi all,
>
> I have 2 small design question. Why are there two different imports? regular java imports and base imports? And why cant I base import and import the same class? (using fqn sucks ;P)


When you bind a role R to a base class B you have some privileges
(decapsulation, callin) that normal Java rules wouldn't grant.
However, I don't want those privileges to "leak", i.e., only the role binding
can make use of decapsulation. The role should then act as the single point
of access towards B.

From this you gain the following guarantees: If you want to find out about
any privileged access to B all you need to inspect are the callout/callin
bindings of role R. Secondly you avoid the confusion that would occur
if you try to compare (==) a role with its base. Should they be considered
the same object? By the OT/J scoping rules such mixed comparison
will generally be impossible, because normally no context has references
to both R and B instances.

The compile checks required for these guarantee are based on the
distinction between regular and base imports, because with a base import
you say: I don't want to directly access this class but only bind a role.

As mentioned, inside R's team all access to B should now go via R.
So I would be curious, if you really need addtional normal access to B,
why would that be? Is that some design that can perhaps be improved to
follow the single point of access rule? Can you give an example?

These rules may force you to think twice, but I believe that this will pay
off, resulting in a design that's easier to maintain etc.

best,
Stephan
Re: Base Imports [message #574126 is a reply to message #531139] Tue, 04 May 2010 14:35 Go to previous message
Jan Marc Hoffmann is currently offline Jan Marc HoffmannFriend
Messages: 32
Registered: July 2009
Member
There are a few cases where you need the basetype.

One of those cases is when you have 2 roles with the same base in the team and would like to use them in a team method. But rather than using a team method on the base of those roles you could also introduce a new super type for the two roles. Which might be a better design.

Or if your team is used for another operation concering the base objects. Like registration or similar.

But after reading your answer I agree that those cases are quite rare and might be an indicator of a bad design.

Thanks for your explanation.

greetings

Jan Marc
Previous Topic:Base Imports
Next Topic:OTDT 0.7.0 M2 - this is real
Goto Forum:
  


Current Time: Fri Nov 28 07:34:27 GMT 2014

Powered by FUDForum. Page generated in 0.02744 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software