Fri, 16 Jan 2015 18:13:44 +0100
Integrate suggestion from review to improve consistency with existing code.
michael@0 | 1 | /* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ |
michael@0 | 2 | /* This Source Code Form is subject to the terms of the Mozilla Public |
michael@0 | 3 | * License, v. 2.0. If a copy of the MPL was not distributed with this |
michael@0 | 4 | * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ |
michael@0 | 5 | |
michael@0 | 6 | #ifndef nsSample_h |
michael@0 | 7 | #define nsSample_h |
michael@0 | 8 | |
michael@0 | 9 | /** |
michael@0 | 10 | * A sample of XPConnect. This file is the header of an implementation |
michael@0 | 11 | * nsSample of the nsISample interface. |
michael@0 | 12 | * |
michael@0 | 13 | */ |
michael@0 | 14 | |
michael@0 | 15 | #include "nsISample.h" |
michael@0 | 16 | #include "mozilla/Attributes.h" |
michael@0 | 17 | |
michael@0 | 18 | /** |
michael@0 | 19 | * SampleImpl is an implementation of the nsISample interface. In XPCOM, |
michael@0 | 20 | * there can be more than one implementation of an given interface. Class |
michael@0 | 21 | * IDs (CIDs) uniquely identify a particular implementation of an interface. |
michael@0 | 22 | * Interface IDs (IIDs) uniquely identify an interface. |
michael@0 | 23 | * |
michael@0 | 24 | * The CID is also a unique number that looks just like an IID |
michael@0 | 25 | * and uniquely identifies an implementation |
michael@0 | 26 | * {7CB5B7A0-07D7-11d3-BDE2-000064657374} |
michael@0 | 27 | */ |
michael@0 | 28 | |
michael@0 | 29 | #define NS_SAMPLE_CID \ |
michael@0 | 30 | { 0x7cb5b7a0, 0x7d7, 0x11d3, { 0xbd, 0xe2, 0x0, 0x0, 0x64, 0x65, 0x73, 0x74 } } |
michael@0 | 31 | |
michael@0 | 32 | #define NS_SAMPLE_CONTRACTID "@mozilla.org/sample;1" |
michael@0 | 33 | |
michael@0 | 34 | |
michael@0 | 35 | class nsSampleImpl MOZ_FINAL : public nsISample |
michael@0 | 36 | { |
michael@0 | 37 | public: |
michael@0 | 38 | nsSampleImpl(); |
michael@0 | 39 | |
michael@0 | 40 | /** |
michael@0 | 41 | * This macro expands into a declaration of the nsISupports interface. |
michael@0 | 42 | * Every XPCOM component needs to implement nsISupports, as it acts |
michael@0 | 43 | * as the gateway to other interfaces this component implements. You |
michael@0 | 44 | * could manually declare QueryInterface, AddRef, and Release instead |
michael@0 | 45 | * of using this macro, but why? |
michael@0 | 46 | */ |
michael@0 | 47 | // nsISupports interface |
michael@0 | 48 | NS_DECL_ISUPPORTS |
michael@0 | 49 | |
michael@0 | 50 | /** |
michael@0 | 51 | * This macro is defined in the nsISample.h file, and is generated |
michael@0 | 52 | * automatically by the xpidl compiler. It expands to |
michael@0 | 53 | * declarations of all of the methods required to implement the |
michael@0 | 54 | * interface. xpidl will generate a NS_DECL_[INTERFACENAME] macro |
michael@0 | 55 | * for each interface that it processes. |
michael@0 | 56 | * |
michael@0 | 57 | * The methods of nsISample are discussed individually below, but |
michael@0 | 58 | * commented out (because this macro already defines them.) |
michael@0 | 59 | */ |
michael@0 | 60 | NS_DECL_NSISAMPLE |
michael@0 | 61 | |
michael@0 | 62 | /** |
michael@0 | 63 | * The following is an explanation of how the interface header |
michael@0 | 64 | * file expands to for a c++ implementation. NS_DELC_NSISAMPLE |
michael@0 | 65 | * takes care of defining the right c++ implementation. |
michael@0 | 66 | * |
michael@0 | 67 | * The following if provided for more understanding. |
michael@0 | 68 | * |
michael@0 | 69 | * NS_IMETHOD expands to the standard XPCOM return type. XPCOM methods |
michael@0 | 70 | * should never return any other type. The return value is used |
michael@0 | 71 | * behind the scenes by the XPConnect runtime to figure out if the call |
michael@0 | 72 | * failed in any way. |
michael@0 | 73 | * These methods were generated by "attribute string Value" in |
michael@0 | 74 | * nsISample.idl. When reflected into JavaScript, XPCOM will use these |
michael@0 | 75 | * calls as Getter/Setter ops, so that they can be called transparently |
michael@0 | 76 | * as "sample.Value='foo';" and "var val = sample.Value" |
michael@0 | 77 | */ |
michael@0 | 78 | /* NS_IMETHOD GetValue(char * *aValue); */ |
michael@0 | 79 | /* NS_IMETHOD SetValue(char * aValue); */ |
michael@0 | 80 | |
michael@0 | 81 | /** |
michael@0 | 82 | * The const came from the "in" specifier in nsISample.idl. "in" |
michael@0 | 83 | * specifies that the value of this parameter is used only for input, |
michael@0 | 84 | * this method is not allowed to modify the contents of the buffer. |
michael@0 | 85 | */ |
michael@0 | 86 | /* NS_IMETHOD WriteValue(const char *aPrefix); */ |
michael@0 | 87 | |
michael@0 | 88 | /** |
michael@0 | 89 | * nsISample.idl specifies all of its string types as string, instead |
michael@0 | 90 | * of wstring (wide string), the Unicode type. If the world were a |
michael@0 | 91 | * perfect place, all normal strings in XPCOM interfaces would be unicode. |
michael@0 | 92 | * If this type had been specified as wstring, it would appear as |
michael@0 | 93 | * char16_t * in C++, which is the NSPR type for unicode characters. |
michael@0 | 94 | */ |
michael@0 | 95 | /* NS_IMETHOD Poke(const char* aValue); */ |
michael@0 | 96 | |
michael@0 | 97 | private: |
michael@0 | 98 | ~nsSampleImpl(); |
michael@0 | 99 | |
michael@0 | 100 | char* mValue; |
michael@0 | 101 | }; |
michael@0 | 102 | |
michael@0 | 103 | #endif |