diff options
Diffstat (limited to 'website2/templates/features/experimental/ExtensionMethod.html')
| -rw-r--r-- | website2/templates/features/experimental/ExtensionMethod.html | 67 |
1 files changed, 0 insertions, 67 deletions
diff --git a/website2/templates/features/experimental/ExtensionMethod.html b/website2/templates/features/experimental/ExtensionMethod.html deleted file mode 100644 index ca63bb2e..00000000 --- a/website2/templates/features/experimental/ExtensionMethod.html +++ /dev/null @@ -1,67 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="@ExtensionMethod" logline="Annoying API? Fix it yourself: Add new methods to existing types!"> - <@f.history> - <p> - <code>@ExtensionMethod</code> was introduced as experimental feature in lombok v0.11.2. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - High-impact on code style. - </li><li> - Really would like to ship with utility methods to expand common classes, but so far lombok doesn't have a good distribution method for such runtime dependencies. - </li><li> - Affects quite a bit of eclipse, and auto-complete e.d. do not work yet in netbeans. - </li><li> - Should @ExtensionMethod be legal on methods? Should it be legal on packages? - </li><li> - This feature has more bugs associated with it than we would like, and it is a large maintenance burden. - </li> - </ul> - Current status: <em>hold</em> - Currently we feel this feature will not move out of experimental status anytime soon, but it will not significantly change and support for it is unlikely to be removed in future versions of lombok either. - </@f.experimental> - - <@f.overview> - <p> - You can make a class containing a bunch of <code>public</code>, <code>static</code> methods which all take at least 1 parameter. These methods will extend the type of the first parameter, as if they were instance methods, using the <code>@ExtensionMethod</code> feature. - </p><p> - For example, if you create <code>public static String toTitleCase(String in) { ... }</code>, you can use the <code>@ExtensionMethod</code> feature to make it look like the <code>java.lang.String</code> class has a method named <code>toTitleCase</code>, which has no arguments. The first argument of the static method fills the role of <code>this</code> in instance methods. - </p><p> - All methods that are <code>public</code>, <code>static</code>, and have at least 1 argument whose type is not primitive, are considered extension methods, and each will be injected into the namespace of the type of the first parameter as if they were instance methods. As in the above example, a call that looks like: <code>foo.toTitleCase()</code> is replaced with <code>ClassContainingYourExtensionMethod.toTitleCase(foo);</code>. Note that it is actually not an instant <code>NullPointerException</code> if <code>foo</code> is null - it is passed like any other parameter. - </p><p> - You can pass any number of classes to the <code>@ExtensionMethod</code> annotation; they will all be searched for extension methods. These extension methods apply for any code that is in the annotated class. - </p><p> - Lombok does not (currently) have any runtime dependencies which means lombok does not (currently) ship with any useful extension methods so you'll have to make your own. However, here's one that might spark your imagination: <br /> - <pre>public class ObjectExtensions { - public static <T> or(T object, T ifNull) { - return object != null ? object : ifNull; - } -}</pre><br /> - With the above class, if you add <code>@ExtensionMethod(ObjectExtensions.class)</code> to your class definition, you can write:<br /> - <pre>String x = null; -System.out.println(x.or("Hello, World!"));</pre><br /> - The above code will not fail with a <code>NullPointerException</code>; it will actually output <code>Hello, World!</code> - </p> - </@f.overview> - - <@f.snippets name="experimental/ExtensionMethod" /> - - <@f.confKeys> - <dt> - <code>lombok.extensionMethod.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@ExtensionMethod</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - Calls are rewritten to a call to the extension method; the static method itself is not inlined. Therefore, the extension method must be present both at compile and at runtime. - </p><p> - Generics is fully applied to figure out extension methods. i.e. if the first parameter of your extension method is <code>List<? extends String></code>, then any expression that is compatible with that will have your extension method, but other kinds of lists won't. So, a <code>List<Object></code> won't get it, but a <code>List<String></code> will. - </p> - </@f.smallPrint> -</@f.scaffold> |