bug 157624 - prep for freezing nsISupports* primitives by renaming the string classes appropriately

nsISupportsString  -> nsISupportsCString
nsISupportsWString -> nsISupportsString
r=dougt, sr=jag


git-svn-id: svn://10.0.0.236/trunk@126389 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
alecf%netscape.com
2002-08-06 00:53:19 +00:00
parent 5ac3383c58
commit 573e11653f
150 changed files with 510 additions and 510 deletions

View File

@@ -20,7 +20,7 @@ import new
from xpcom import xpt, COMException, nsError
# Suck in stuff from _xpcom we use regularly to prevent a module lookup
from xpcom._xpcom import IID_nsISupports, IID_nsIClassInfo, IID_nsISupportsString, IID_nsISupportsWeakReference, \
from xpcom._xpcom import IID_nsISupports, IID_nsIClassInfo, IID_nsISupportsCString, IID_nsISupportsWeakReference, \
IID_nsIWeakReference, XPTI_GetInterfaceInfoManager, NS_GetGlobalComponentManager, XPTC_InvokeByIndex
# Attribute names we may be __getattr__'d for, but know we don't want to delegate
@@ -159,7 +159,7 @@ class _XPCOMBase:
# See if the object support strings.
def __str__(self):
try:
self._comobj_.QueryInterface(IID_nsISupportsString, 0)
self._comobj_.QueryInterface(IID_nsISupportsCString, 0)
return str(self._comobj_)
except COMException:
return self.__repr__()

View File

@@ -40,7 +40,7 @@ object, thereby allowing explicit control over the type of variant created.</p>
term collectively the <i>nsISupports Primitives Interfaces</i>.&nbsp; These
are a set of interfaces a component can support to allow automatic conversion to
and from many basic types.&nbsp; For example, an interface can define that it
supports the <i>nsISupportsString</i> interface, and this could be used by any
supports the <i>nsISupportsCString</i> interface, and this could be used by any
program that wishes to get a string representation of the object.&nbsp; If an
interface wishes to expose itself as a &quot;boolean value&quot;, it may choose
to support the <i>nsISupportsPRBool</i> interface.</p>
@@ -48,8 +48,8 @@ to support the <i>nsISupportsPRBool</i> interface.</p>
calling), you can use
the builtin functions <i>str()</i>, <i>int()</i>, <i>long()</i> etc., on the
object<i>.</i>&nbsp; In the
case of <i>str()</i>, if the object does not support the <i>nsISupportsString</i>
or <i>nsISupportsWString</i> interfaces, the default string <i>str()</i> for the
case of <i>str()</i>, if the object does not support the <i>nsISupportsCString</i>
or <i>nsISupportsString</i> interfaces, the default string <i>str()</i> for the
object will be returned (i.e., what is normally returned for most XPCOM objects -
support for these interface is not very common!).&nbsp; In the case of the numeric functions, a <i>ValueError</i>
exception will be raised if the objects do not support any interface that can be
@@ -71,8 +71,8 @@ of these interfaces:</p>
</li>
<li>If your class does not define support for these interfaces, the framework
will use standard Python class semantics to implement them - i.e., if your
class provides a <i>__str__</i> method, it will be used to implement <i>nsISupportsString</i>
and <i>nsISupportsWString</i>, if you provide <i>__int__</i>, <i>__long__</i>,
class provides a <i>__str__</i> method, it will be used to implement <i>nsISupportsCString</i>
and <i>nsISupportsString</i>, if you provide <i>__int__</i>, <i>__long__</i>,
<i>__float__</i> etc., methods, they will be used to implement the numeric
interfaces.&nbsp; If your class defines no such special methods, then the <i>
QueryInterface()</i> for those interfaces fails (rather than the QI succeeding
@@ -83,7 +83,7 @@ of these interfaces:</p>
possible.&nbsp; Consider Python code that does a <i>str()</i> on an&nbsp; XPCOM
interface, and where the XPCOM interface itself is implemented in Python and
provides a <i>__str__</i> method.&nbsp; The <i>str()</i> on the original
interface queries for the <i>nsISupportsString</i> interface.&nbsp; The
interface queries for the <i>nsISupportsCString</i> interface.&nbsp; The
Python implemented object responds to this interface and delegates to the <i>__str__</i>
method. At the end of all this, <i>str()</i> returns the same result
as if the objects were native Python objects with no XPCOM layer in between.</p>

View File

@@ -294,8 +294,8 @@ class DefaultPolicy:
return self._doHandleException(name, exc_info)
_supports_primitives_data_ = [
("nsISupportsCString", "__str__", str),
("nsISupportsString", "__str__", str),
("nsISupportsWString", "__str__", str),
("nsISupportsPRUint64", "__long__", long),
("nsISupportsPRInt64", "__long__", long),
("nsISupportsPRUint32", "__int__", int),

View File

@@ -143,7 +143,7 @@ PyXPCOM_TypeObject::Py_str(PyObject *self)
char *val = NULL;
Py_BEGIN_ALLOW_THREADS;
{ // scope to kill pointer while thread-lock released.
nsCOMPtr<nsISupportsString> ss( do_QueryInterface(pis->m_obj, &rv ));
nsCOMPtr<nsISupportsCString> ss( do_QueryInterface(pis->m_obj, &rv ));
if (NS_SUCCEEDED(rv))
rv = ss->ToString(&val);
} // end-scope

View File

@@ -579,7 +579,7 @@ init_xpcom() {
Py_XDECREF(obFuncPtr);
REGISTER_IID(nsISupports);
REGISTER_IID(nsISupportsString);
REGISTER_IID(nsISupportsCString);
REGISTER_IID(nsIModule);
REGISTER_IID(nsIFactory);
REGISTER_IID(nsIWeakReference);

View File

@@ -17,7 +17,7 @@
# Test our support for the interfaces defined in nsISupportsPrimitives.idl
#
# The framework supports nsISupportsString and nsISupportsWString, but
# The framework supports nsISupportsCString and nsISupportsString, but
# only if our class doesnt provide explicit support.
from xpcom import components
@@ -32,7 +32,7 @@ class ImplicitSupportsString:
return "<MyImplicitStrObject>"
class ExplicitSupportsString:
_com_interfaces_ = [components.interfaces.nsISupports, components.interfaces.nsISupportsString]
_com_interfaces_ = [components.interfaces.nsISupports, components.interfaces.nsISupportsCString]
# __str__ will be ignored by XPCOM, as we have _explicit_ support.
def __str__(self):
return "<MyImplicitStrObject>"