/* Copyright (c) 2007 Timothy Wall, All Rights Reserved
 * 
 * The contents of this file is dual-licensed under 2 
 * alternative Open Source/Free licenses: LGPL 2.1 or later and 
 * Apache License 2.0. (starting with JNA version 4.0.0).
 * 
 * You can freely decide which license you want to apply to 
 * the project.
 * 
 * You may obtain a copy of the LGPL License at:
 * 
 * http://www.gnu.org/licenses/licenses.html
 * 
 * A copy is also included in the downloadable source code package
 * containing JNA, in file "LGPL2.1".
 * 
 * You may obtain a copy of the Apache License at:
 * 
 * http://www.apache.org/licenses/
 * 
 * A copy is also included in the downloadable source code package
 * containing JNA, in file "AL2.0".
 */
package com.sun.jna;

import java.lang.reflect.Method;

/** Provides mapping of Java method names to native function names.  
 * An instance of this interface may be provided to 
 * {@link Native#loadLibrary(String, Class, java.util.Map)} as an entry in
 * the options map with key {@link Library#OPTION_FUNCTION_MAPPER}.
 * <p>
 * There are several circumstances where this option might prove useful.
 * <ul>
 * <li>C preprocessor macros are used to allow C code to refer to a library 
 * function by a different name
 * <li>Generated linker symbols are different than those used in C code.  
 * Windows <code>stdcall</code> functions, for instance, are exported with a 
 * special suffix that describes the stack size of the function arguments
 * (see {@link com.sun.jna.win32.StdCallFunctionMapper}).
 * <li>The naming of the C library methods conflicts horribly with your
 * Java coding standards, or are otherwise hard to follow.  It's generally
 * better to keep the original function names in this case, to avoid confusion
 * about what's actually being called, but the option is available.
 * </ul>
 * 
 * @see Library#OPTION_FUNCTION_MAPPER 
 */
public interface FunctionMapper {
    String getFunctionName(NativeLibrary library, Method method);
}