Add additional cli option and properties to swift3 for Objective-C compatibility. (#6129)
Currently, in the swift3 language, if you have an optional integer, number, or boolean property in a model, then the generated swift3 model class might look like:
class SomeModel {
var someInt: Int?
var someFloat: Float?
var someDouble: Double?
var someBool: Bool?
}
This works fine if you are accessing this model only from Swift code. However, it is very common for iOS codebases to contain both Swift AND Objective-C. If you need to access this model from Objective-C, then those 4 properties are not accessible, since Optional scalars do not translate to Objective-C.
Therefore, in the swift3 language, we want to add some code for Objective-C compatibility:
1. We add a "objCompatible" boolean command-line option. If objCompatible=true, then this enables some additional code generation to make these types of properties accessible from Objective-C. If objCompatible=false, then the generated code is exactly as it currently is. The default is objcCopmatible=false.
2. If objCompatible=true, then for these types of Objective-C-inaccessible properties (Optional scalars), then we add a "x-swift-optional-scalar=true" vendor extension in the CodegenProperty.
3. Then, in the model.mustache template, if we see x-swift-optional-scalar=true, then we add an additional computed property which returns an optional NSNumber.
So, for example, when objcCompatible=false (the default case), then the generated code for the "declawed" property of the Cat model looks like:
open class Cat: Animal {
public var declawed: Bool?
...
But when objcCompatible=true, then it looks like:
open class Cat: Animal {
public var declawed: Bool?
public var declawedNum: NSNumber? {
get {
return declawed.map({ return NSNumber(value: $0) })
}
}
...
2017-08-02 10:20:01 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
SCRIPT="$0"
|
2018-04-23 07:58:45 +00:00
|
|
|
echo "# START SCRIPT: $SCRIPT"
|
Add additional cli option and properties to swift3 for Objective-C compatibility. (#6129)
Currently, in the swift3 language, if you have an optional integer, number, or boolean property in a model, then the generated swift3 model class might look like:
class SomeModel {
var someInt: Int?
var someFloat: Float?
var someDouble: Double?
var someBool: Bool?
}
This works fine if you are accessing this model only from Swift code. However, it is very common for iOS codebases to contain both Swift AND Objective-C. If you need to access this model from Objective-C, then those 4 properties are not accessible, since Optional scalars do not translate to Objective-C.
Therefore, in the swift3 language, we want to add some code for Objective-C compatibility:
1. We add a "objCompatible" boolean command-line option. If objCompatible=true, then this enables some additional code generation to make these types of properties accessible from Objective-C. If objCompatible=false, then the generated code is exactly as it currently is. The default is objcCopmatible=false.
2. If objCompatible=true, then for these types of Objective-C-inaccessible properties (Optional scalars), then we add a "x-swift-optional-scalar=true" vendor extension in the CodegenProperty.
3. Then, in the model.mustache template, if we see x-swift-optional-scalar=true, then we add an additional computed property which returns an optional NSNumber.
So, for example, when objcCompatible=false (the default case), then the generated code for the "declawed" property of the Cat model looks like:
open class Cat: Animal {
public var declawed: Bool?
...
But when objcCompatible=true, then it looks like:
open class Cat: Animal {
public var declawed: Bool?
public var declawedNum: NSNumber? {
get {
return declawed.map({ return NSNumber(value: $0) })
}
}
...
2017-08-02 10:20:01 +00:00
|
|
|
|
|
|
|
|
while [ -h "$SCRIPT" ] ; do
|
|
|
|
|
ls=`ls -ld "$SCRIPT"`
|
|
|
|
|
link=`expr "$ls" : '.*-> \(.*\)$'`
|
|
|
|
|
if expr "$link" : '/.*' > /dev/null; then
|
|
|
|
|
SCRIPT="$link"
|
|
|
|
|
else
|
|
|
|
|
SCRIPT=`dirname "$SCRIPT"`/"$link"
|
|
|
|
|
fi
|
|
|
|
|
done
|
|
|
|
|
|
|
|
|
|
if [ ! -d "${APP_DIR}" ]; then
|
|
|
|
|
APP_DIR=`dirname "$SCRIPT"`/..
|
|
|
|
|
APP_DIR=`cd "${APP_DIR}"; pwd`
|
|
|
|
|
fi
|
|
|
|
|
|
2018-03-06 16:20:46 +00:00
|
|
|
executable="./modules/openapi-generator-cli/target/openapi-generator-cli.jar"
|
Add additional cli option and properties to swift3 for Objective-C compatibility. (#6129)
Currently, in the swift3 language, if you have an optional integer, number, or boolean property in a model, then the generated swift3 model class might look like:
class SomeModel {
var someInt: Int?
var someFloat: Float?
var someDouble: Double?
var someBool: Bool?
}
This works fine if you are accessing this model only from Swift code. However, it is very common for iOS codebases to contain both Swift AND Objective-C. If you need to access this model from Objective-C, then those 4 properties are not accessible, since Optional scalars do not translate to Objective-C.
Therefore, in the swift3 language, we want to add some code for Objective-C compatibility:
1. We add a "objCompatible" boolean command-line option. If objCompatible=true, then this enables some additional code generation to make these types of properties accessible from Objective-C. If objCompatible=false, then the generated code is exactly as it currently is. The default is objcCopmatible=false.
2. If objCompatible=true, then for these types of Objective-C-inaccessible properties (Optional scalars), then we add a "x-swift-optional-scalar=true" vendor extension in the CodegenProperty.
3. Then, in the model.mustache template, if we see x-swift-optional-scalar=true, then we add an additional computed property which returns an optional NSNumber.
So, for example, when objcCompatible=false (the default case), then the generated code for the "declawed" property of the Cat model looks like:
open class Cat: Animal {
public var declawed: Bool?
...
But when objcCompatible=true, then it looks like:
open class Cat: Animal {
public var declawed: Bool?
public var declawedNum: NSNumber? {
get {
return declawed.map({ return NSNumber(value: $0) })
}
}
...
2017-08-02 10:20:01 +00:00
|
|
|
|
|
|
|
|
if [ ! -f "$executable" ]
|
|
|
|
|
then
|
2018-05-16 13:39:52 +00:00
|
|
|
mvn -B clean package
|
Add additional cli option and properties to swift3 for Objective-C compatibility. (#6129)
Currently, in the swift3 language, if you have an optional integer, number, or boolean property in a model, then the generated swift3 model class might look like:
class SomeModel {
var someInt: Int?
var someFloat: Float?
var someDouble: Double?
var someBool: Bool?
}
This works fine if you are accessing this model only from Swift code. However, it is very common for iOS codebases to contain both Swift AND Objective-C. If you need to access this model from Objective-C, then those 4 properties are not accessible, since Optional scalars do not translate to Objective-C.
Therefore, in the swift3 language, we want to add some code for Objective-C compatibility:
1. We add a "objCompatible" boolean command-line option. If objCompatible=true, then this enables some additional code generation to make these types of properties accessible from Objective-C. If objCompatible=false, then the generated code is exactly as it currently is. The default is objcCopmatible=false.
2. If objCompatible=true, then for these types of Objective-C-inaccessible properties (Optional scalars), then we add a "x-swift-optional-scalar=true" vendor extension in the CodegenProperty.
3. Then, in the model.mustache template, if we see x-swift-optional-scalar=true, then we add an additional computed property which returns an optional NSNumber.
So, for example, when objcCompatible=false (the default case), then the generated code for the "declawed" property of the Cat model looks like:
open class Cat: Animal {
public var declawed: Bool?
...
But when objcCompatible=true, then it looks like:
open class Cat: Animal {
public var declawed: Bool?
public var declawedNum: NSNumber? {
get {
return declawed.map({ return NSNumber(value: $0) })
}
}
...
2017-08-02 10:20:01 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
# if you've executed sbt assembly previously it will use that instead.
|
|
|
|
|
export JAVA_OPTS="${JAVA_OPTS} -XX:MaxPermSize=256M -Xmx1024M -DloggerPath=conf/log4j.properties"
|
2018-03-06 16:20:46 +00:00
|
|
|
ags="generate -t modules/openapi-generator/src/main/resources/swift3 -i modules/openapi-generator/src/test/resources/2_0/swift/petstore-with-fake-endpoints-models-for-testing.yaml -l swift3 -c ./bin/swift3-petstore-objcCompatible.json -o samples/client/petstore/swift3/objcCompatible $@"
|
Add additional cli option and properties to swift3 for Objective-C compatibility. (#6129)
Currently, in the swift3 language, if you have an optional integer, number, or boolean property in a model, then the generated swift3 model class might look like:
class SomeModel {
var someInt: Int?
var someFloat: Float?
var someDouble: Double?
var someBool: Bool?
}
This works fine if you are accessing this model only from Swift code. However, it is very common for iOS codebases to contain both Swift AND Objective-C. If you need to access this model from Objective-C, then those 4 properties are not accessible, since Optional scalars do not translate to Objective-C.
Therefore, in the swift3 language, we want to add some code for Objective-C compatibility:
1. We add a "objCompatible" boolean command-line option. If objCompatible=true, then this enables some additional code generation to make these types of properties accessible from Objective-C. If objCompatible=false, then the generated code is exactly as it currently is. The default is objcCopmatible=false.
2. If objCompatible=true, then for these types of Objective-C-inaccessible properties (Optional scalars), then we add a "x-swift-optional-scalar=true" vendor extension in the CodegenProperty.
3. Then, in the model.mustache template, if we see x-swift-optional-scalar=true, then we add an additional computed property which returns an optional NSNumber.
So, for example, when objcCompatible=false (the default case), then the generated code for the "declawed" property of the Cat model looks like:
open class Cat: Animal {
public var declawed: Bool?
...
But when objcCompatible=true, then it looks like:
open class Cat: Animal {
public var declawed: Bool?
public var declawedNum: NSNumber? {
get {
return declawed.map({ return NSNumber(value: $0) })
}
}
...
2017-08-02 10:20:01 +00:00
|
|
|
|
|
|
|
|
java $JAVA_OPTS -jar $executable $ags
|
