plugins/org.eclipse.objectteams.otdt.doc/guide/otjld/xdef/s2.3.1.d.html - objectteams/org.eclipse.objectteams - Gitiles

 <!DOCTYPE html
   PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
       <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
       <link rel="stylesheet" type="text/css" href="../css/ot.css" />
       <link rel="stylesheet" type="text/css" href="../css/otjld.css" />
       <title>OT/J Language Definition v1.3</title>
    </head>
    <body class="otdt">
       <div id="content">
          <table class="nav">
             <tr>
                <td class="back"><a id="top"></a><a href="s2.3.1.c.html" rel="prev">&lt;&lt;&nbsp;&sect;2.3.1.(c)&nbsp;Custom lifting constructor</a></td>
                <td class="top"><a href="index.html" rel="contents">&uarr;&nbsp;Table of Contents&nbsp;&uarr;</a></td>
                <td class="next"></td>
             </tr>
          </table>
          <div class="breadcrumb"><a class="nav" href="s2.html" rel="section">&sect;2&nbsp;Role Binding</a>&nbsp;&gt;&nbsp;<a class="nav" href="s2.3.html" rel="section">&sect;2.3&nbsp;Lifting</a>&nbsp;&gt;&nbsp;<a class="nav" href="s2.3.1.html" rel="section">&sect;2.3.1&nbsp;Implicit role creation</a></div>
          <div class="subsect depth4" id="s2.3.1.d">
             <h4 class="subsect">&sect;2.3.1.(d)&nbsp;<span class="title">Fine-tuning role instantiation</span><a class="img" href="s2.3.1.d.html"
                   title="PermaLink to (d)&nbsp;Fine-tuning role instantiation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
                        alt="" /></a></h4>
             <p>If the lifting operation as defined above degrades the program performance, the lifting semantics can be modified per role
                class
                					by adding the annotation <code>@org.objectteams.Instantiation</code> which requires an argument of type
                					<code>org.objectteams.InstantiationPolicy</code> in order to select between the following behaviors:

             </p>
             <dl>
                <dt>ONDEMAND</dt>
                <dd>This is the default behavior as defined above.</dd>
                <dt>ALWAYS</dt>
                <dd>This strategy avoids maintaining the internal role cache, but instead a fresh role instance is created for each lifting request.
                   				    This may increase the number of role instances but cuts the costs of accessing the cache, which could otherwise become

                   				    expensive if a cache grows large. As a result of this strategy role state can no longer be shared
                   				    over time, thus it is discouraged to define fields in a role with this strategy. Also, comparing roles could lead
                   to
                   				    unexpected results. Therefor, roles with this strategy should implement custom <code>equals</code> and <code>hashCode</code>
                   				    methods, which should simply delegate to the base instance (using callout <a href="s3.html" title="&sect;3&nbsp;Callout Binding" class="sect">&sect;3</a>).
                </dd>
                <dt>NEVER</dt>
                <dd>Roles with this instantiation policy are never instantiated by lifting.
                   	 				Such roles cannot define non-static fields.
                   	 				Otherwise this optimization is fully transparent, specifically callout bindings will refer to the correct base instance.<br />
                   	 				As of version 2.0 the OT/J compiler does not implement this strategy.
                </dd>
                <dt>SINGLETON</dt>
                <dd>Roles declaring this strategy will be instantiated at most once per team. Subsequent lifting requests in the same team
                   	 				will always answer the same role instance. Such roles may receive triggers from callin bindings, but cannot define
                   	 				callout bindings.<br />
                   	 				As of version 2.0 the OT/J compiler does not implement this strategy.
                </dd>
             </dl>
          </div>
          <table class="nav">
             <tr>
                <td class="back"><a href="s2.3.1.c.html" rel="prev">&lt;&lt;&nbsp;&sect;2.3.1.(c)&nbsp;Custom lifting constructor</a></td>
                <td class="top"><a href="index.html" rel="contents">&uarr;&nbsp;Table of Contents&nbsp;&uarr;</a></td>
                <td class="next"></td>
             </tr>
          </table>
          <div class="breadcrumb"><a class="nav" href="s2.html" rel="section">&sect;2&nbsp;Role Binding</a>&nbsp;&gt;&nbsp;<a class="nav" href="s2.3.html" rel="section">&sect;2.3&nbsp;Lifting</a>&nbsp;&gt;&nbsp;<a class="nav" href="s2.3.1.html" rel="section">&sect;2.3.1&nbsp;Implicit role creation</a></div>
       </div>
       <div id="footer">
          <hr /><a class="w3c img" href="http://jigsaw.w3.org/css-validator/check/referer"
             shape="rect"><img src="../images/valid-css2-blue.png" alt="Valid CSS!" height="31" width="88" /></a><a class="w3c img" href="http://validator.w3.org/check?uri=referer" shape="rect"><img src="../images/valid-xhtml10-blue.png" alt="Valid XHTML 1.0 Strict" height="31"
                  width="88" /></a><address>&copy; Stephan Herrmann, Christine Hundt, Marco Mosconi</address>
          			OT/J version 1.3 &mdash; last modified: 2011-05-15
       </div>
    </body>
 </html>
	<!DOCTYPE html
	PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<link rel="stylesheet" type="text/css" href="../css/ot.css" />
	<link rel="stylesheet" type="text/css" href="../css/otjld.css" />
	<title>OT/J Language Definition v1.3</title>
	</head>
	<body class="otdt">
	<div id="content">
	<table class="nav">
	<tr>
	<td class="back"><a id="top"></a><a href="s2.3.1.c.html" rel="prev"><< §2.3.1.(c) Custom lifting constructor</a></td>
	<td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td>
	<td class="next"></td>
	</tr>
	</table>
	<div class="breadcrumb"><a class="nav" href="s2.html" rel="section">§2 Role Binding</a> > <a class="nav" href="s2.3.html" rel="section">§2.3 Lifting</a> > <a class="nav" href="s2.3.1.html" rel="section">§2.3.1 Implicit role creation</a></div>
	<div class="subsect depth4" id="s2.3.1.d">
	<h4 class="subsect">§2.3.1.(d) <span class="title">Fine-tuning role instantiation</span><a class="img" href="s2.3.1.d.html"
	title="PermaLink to (d) Fine-tuning role instantiation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
	alt="" /></a></h4>
	<p>If the lifting operation as defined above degrades the program performance, the lifting semantics can be modified per role
	class
	by adding the annotation <code>@org.objectteams.Instantiation</code> which requires an argument of type
	<code>org.objectteams.InstantiationPolicy</code> in order to select between the following behaviors:

	</p>
	<dl>
	<dt>ONDEMAND</dt>
	<dd>This is the default behavior as defined above.</dd>
	<dt>ALWAYS</dt>
	<dd>This strategy avoids maintaining the internal role cache, but instead a fresh role instance is created for each lifting request.
	This may increase the number of role instances but cuts the costs of accessing the cache, which could otherwise become

	expensive if a cache grows large. As a result of this strategy role state can no longer be shared
	over time, thus it is discouraged to define fields in a role with this strategy. Also, comparing roles could lead
	to
	unexpected results. Therefor, roles with this strategy should implement custom <code>equals</code> and <code>hashCode</code>
	methods, which should simply delegate to the base instance (using callout <a href="s3.html" title="§3 Callout Binding" class="sect">§3</a>).
	</dd>
	<dt>NEVER</dt>
	<dd>Roles with this instantiation policy are never instantiated by lifting.
	Such roles cannot define non-static fields.
	Otherwise this optimization is fully transparent, specifically callout bindings will refer to the correct base instance.<br />
	As of version 2.0 the OT/J compiler does not implement this strategy.
	</dd>
	<dt>SINGLETON</dt>
	<dd>Roles declaring this strategy will be instantiated at most once per team. Subsequent lifting requests in the same team
	will always answer the same role instance. Such roles may receive triggers from callin bindings, but cannot define
	callout bindings.<br />
	As of version 2.0 the OT/J compiler does not implement this strategy.
	</dd>
	</dl>
	</div>
	<table class="nav">
	<tr>
	<td class="back"><a href="s2.3.1.c.html" rel="prev"><< §2.3.1.(c) Custom lifting constructor</a></td>
	<td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td>
	<td class="next"></td>
	</tr>
	</table>
	<div class="breadcrumb"><a class="nav" href="s2.html" rel="section">§2 Role Binding</a> > <a class="nav" href="s2.3.html" rel="section">§2.3 Lifting</a> > <a class="nav" href="s2.3.1.html" rel="section">§2.3.1 Implicit role creation</a></div>
	</div>
	<div id="footer">
	<hr /><a class="w3c img" href="http://jigsaw.w3.org/css-validator/check/referer"
	shape="rect"><img src="../images/valid-css2-blue.png" alt="Valid CSS!" height="31" width="88" /></a><a class="w3c img" href="http://validator.w3.org/check?uri=referer" shape="rect"><img src="../images/valid-xhtml10-blue.png" alt="Valid XHTML 1.0 Strict" height="31"
	width="88" /></a><address>© Stephan Herrmann, Christine Hundt, Marco Mosconi</address>
	OT/J version 1.3 — last modified: 2011-05-15
	</div>
	</body>
	</html>