Create a static method for ambiguous overloaded constructor by Naum-PDFTron · Pull Request #150 · ApryseSDK/PDFNetWrappers

Naum-PDFTron · 2025-03-25T11:02:44Z

Description

SWIG has issues with C++ overloaded methods (and constructors) to target scripting languages like Python, PHP and Ruby, like:

class ObjectIdentifier
{
public:
    ObjectIdentifier(const Predefined in_oid_enum);
    ObjectIdentifier(const DigestAlgorithm::Type in_digest_algorithm_type);
    // etc.
};

Both constructors take integral as input and, when called from scripting language (Python, PHP, Ruby), which knows just for one Integer type, SWIG has no way to unambiguosly distinguish which constructor to call. Therefor, SWIG offers several options to overcome that:

%rename the second overloaded method and call it from the script by new name, say FromDigestAlgorithm().
It is fine for class method but not for constructor since one need an instance to call it and SWIG doesn't add a static prefix to call it as static. One need to create a dummy instance to call the instance method:
```
ObjectIdentifier dummy();
ObjectIdentifier oid = dummy.FromDigestAlgorithm(in_digest_algorithm_type);
```
This way to go is rejected.
%inline the second method by creating a global (non-class-related) static method to do the above (1.) job. In script it would be called like:
```
ObjectIdentifier oid1 = ObjectIdentifierFromDigestAlgorithm(in_digest_algorithm_type);	// construct from `DigestAlgorithm::Type`
```
This works, but may confuse the developer. Say, in a similar case one should create instance as:
```
ObjectIdentifier oid1 = ObjectIdentifier(in_oid_enum);	// construct from Crypto::Predefined
```
Developer doesn't need to know that it is a SWIG that dictates the API which may look confusing.

%extend the ObjectIdentifier class (internally and locally to SWIG) with a static method that will call propper constructor:

%extend pdftron::Crypto::ObjectIdentifier {
	public:
	static pdftron::Crypto::ObjectIdentifier* FromDigestAlgorithm(const DigestAlgorithm::Type in_digest_algorithm) {
		return new pdftron::Crypto::ObjectIdentifier(in_digest_algorithm);
	}
}

The developer could call:

	ObjectIdentifier oid1 = ObjectIdentifier(in_oid_enum);	// construct from Crypto::Predefined
	ObjectIdentifier oid2 = ObjectIdentifier.FromDigestAlgorithm(in_digest_algorithm_type);	// construct from `DigestAlgorithm::Type`

This is acceptable solutuion. But there is one additional proposal...

Could we have a static method for the first case too and let it look like:
```
ObjectIdentifier oid1 = ObjectIdentifier.FromPredefined(in_oid_enum);	// construct from Crypto::Predefined
ObjectIdentifier oid2 = ObjectIdentifier.FromDigestAlgorithm(in_digest_algorithm_type);	// construct from `DigestAlgorithm::Type`
```
Or, generally, could we wrap all overloaded constructors (and methods) with this kind of extension?

Q: What to do with customers that already use current API?
A: They can continue as is is now, but with one note in the documentation: "Deprecated. Please use new notation ..."
During Script/GenSwigWrappers.py run, there are several important products that are left in dark and that may be good to be uploaded somehow:

PDFNetPython/PDFNetPython.cpp
PDFNetPython/PDFNetPython.hpp
PDFNetPython/PDFNetPython.py

PDFNetPHP/PDFNetPHP.cpp
PDFNetPHP/PDFNetPHP.php
PDFNetPHP/php_PDFNetPHP.h

PDFNetRuby/PDFNetRuby.cpp
PDFNetRuby/PDFNetRuby.hpp

PDFNet*/swig.log
PDFNet*/swig.err.log

SWIG log files hides lot of overloading and missing defs info which would be good to look if some doesn;t work.