Is there any way to get a Swift type name as a string with its namespace (or framework name)?
For example, if Foo.framework has a class named Bar, I would like to get a string something like "Foo.Bar".
The followings just return the class name "Bar".
let barName1 = String(Bar.self) // returns "Bar"
let barName2 = "\(Bar.self)" // returns "Bar"
let barName3 = "\(Bar().dynamicType)" // returns "Bar"
I would like to also get the framework name "Foo" as a namespace.
Use String(reflecting:):
struct Bar { }
let barName = String(reflecting: Bar.self)
print(barName) // <Module>.Bar
From the Xcode 7 Release Notes:
Type names and enum cases now print and convert to String without
qualification by default. debugPrint or String(reflecting:) can still
be used to get fully qualified names.
String(reflecting:) works right now, but could change in the future. So if you only need the fully-qualified name temporarily, you should be fine. However, if the name is something you're going to rely on over a longer period of time (spanning multiple releases of Swift) you shouldn't use it.
The Swift community is trying to come to a consensus on a longer-term method for getting the information from a type.
From Joe Groff:
In 4.2, String(reflecting:) still shows a fully qualified name for local types, but the local type context is anonymized and printed in a way that's intended to be clear is non-stable, since no matter what reflection support we add in the future, it'd be a bad idea to incidentally rely on the presence or identity of local types in dynamic code.
https://forums.swift.org/t/getting-the-more-fully-qualified-name-of-a-type/14375/9
Related
When using Swift 3, I was defining my model like so
class Model: NSObject {
var prop1: String
}
When I wanted to access the static string value of the property name prop1, I would use let sad = #keyPath(Model.prop1) and it would give me "prop1" printed out. Happy days.
The problem is, that since upgrading to Swift 4, I am having trouble doing the above. I see in other posts that we can use the new \Model.prop1 syntax but that seems to be providing the value of property rather than the string representation of the name.
I am also refactoring out the need for NSObject on my Swift models, but I would have thought I can still get this functionality.
Any help here would be appreciated!
Swift properties do not necessarily retain the strings of the property names at runtime. Therefore, if the Swift key path syntax were able to give you this string value, it would only be able to be used on NSObject-derived classes. The Swift key path syntax doesn't only work with those, though; it can also be used to refer to properties of non-#objc classes and structs. Therefore, this is not possible. The #keyPath syntax remains available, however, to get the string key path of an Objective-C property.
I know the recommended way in Swift is to use:
class Address {
var firstLine : String?
var secondLine : String?
}
but sometimes I see other developers write their code this way:
class Address {
var firstLine : String = ""
var secondLine : String = ""
}
Is this the unrecommended way because whenever you have nil you will just crash and there's no outlet for your to recover. Is that right? Or there are some use cases where using non-optionals with default can be good. If so then where?
I saw this other question which is asking about efficiency rather than which better suits your needs. I'm looking for an answer where it says "This is a good place to use non-optionals and this is a good place to use optionals". Sometimes I see folks just dump optionals everywhere and it makes me think do we not ever need non-optionals? Sometimes I see people trying to avoid optionals as much as possible and just code in an Objective-C kind of style.
The above question's answer doesn't represent a valid case for where non-optionals are good. It's mute about that. As for choosing optionals: I'm guessing for models which get populated by network calls, optionals are the right choice, because you don't know whether it's nil or not.
The choice depends on what you model.
If a property of the object that you model may be absent completely, e.g. a middle name, a name suffix, an alternative phone number, etc., it should be modeled with an optional. A nil optional tells you that the property is not there - i.e. a person does not have a middle name or an alternative phone number. You should also use optional when you must distinguish between an empty object and a missing object.
If a property of the object must be set, and has a meaningful default, use an non-optional with a default:
class AddressList {
var addresses : [Address]
var separator : String = ";"
...
}
If users of your class need to change the separator, they have a way to do that. However, if they do not care about the separator, they can continue using the default without mentioning it in their own code.
Well you should use optionals if you think that the variable might not have a value. But if you're really sure that it's gonna have a value then you don't need to use them.
So only use non-optionals if you're sure that the variable will have a value else use optionals.
So I was doing some reading, and I wanted to know what the following meant. Let's say for instance in Swift, you have a method like recordResponse(_:) what does the parameter mean?
I'm working with MVCs and was doing an exercise in a book that had that preset parameter. In the model, I'm supposed to use that method to record a passed answer of "true" or "false" (obviously a string not a boolean), to indicate that a current response was given from a method "currentQuestion".
The exercise in the online book also states that the same method recordResponse(_:) should check if the answer given from the question currentQuestion() method is correct or not.
It's a way of stating the name of the function. The function might be declared like this:
func recordResponse(s:String) {
// ...
}
Now, by default, the s is an internal parameter name only; the external parameter name is suppressed. So we need a notation that describes the function, recordResponse, as taking one parameter with no external name. That notation is recordResponse(_:). The colon follows each parameter name — here there is only one parameter, and has no external name, which is what the underscore indicates.
In the usage you are asking about, this notation is just that: a notation. It's a convention for giving the name of the function in a complete way, when humans talk to humans (as in a tutorial). But in Swift 2.2, this notation will become very important, because it will be part of the language — it's how you'll form a function reference. That is, it will be Swift's own name for the function.
I am giving a example for this
func test()
{
let strOne : String = "hello"
let _ : String = "Linuxn00b"
print(strOne)
}
in let strTwo line xcode produce a warnig that Having an "_" the "named parameter" will be explicitly unused.Happy coding .
I'm new to Swift and iOS coding and have been working on writing my first app. While my programming background is pretty significant, I come from a Python and C# background where pretty much anything can be None or null and it's up to the user to check at runtime for a null. I'm finding this whole concept of "nullable vs. non-nullable types" or "optional types" in Swift to be confusing.
I understand that the core concept is that a variable declared as a type like myObject cannot be set to nil. However, if I define it as type myObject? then the value can be set to nil.
The problem is that, when I look at my code designs, it feels like everything will have to be "nullable" in my code. It feels like this either means I'm not thinking correctly with how my code should run, or that I'm missing some crucial piece of understanding.
Let's take the simplest example of something I am confused about. Suppose I have two classes - one that stores and manages some sort of data, and another that provides access to that data. (An example of this might be something like a database connection, or a file handle, or something similar.) Let's call the class containing data myData and the class that works with that data myObject.
myObject will need a class-level reference to myData because many of its methods depend on a local reference to the class. So, the first thing the constructor does is to generate a data connection and then store it in the local variable dataConnection. The variable needs to be defined at the class level so other methods can access it, but it will be assigned to in the constructor. Failure to obtain the connection will result in some sort of exception that will interfere with the very creation of the class.
I know that Swift has two ways to define a variable: var and let, with let being analogous to some languages' const directive. Since the data connection will persist throughout the entire life of the class, let seems an obvious choice. However, I do not know how to define a class-level variable via let which will be assigned at runtime. Therefore, I use something like
var dataConnection: myData?
in the class outside any functions.
But now I have to deal with the nullable data type, and do explicit unwrapping every time I use it anywhere. It is frustrating to say the least and quite confusing.
func dealWithData() {
self.dataConnection.someFunctionToGetData() <- results in an unwrapping error.
self.dataConnection!.someFunctionToGetData() <- works.
let someOtherObjectUsingData: otherObject = self.getOtherObject() <- may result in error unless type includes ?
someOtherObjectUsingData.someMethod(self.dataConnection) <- unwrap error if type included ?
var myData = self.dataConnection!
someOtherObjectUsingData.someMethod(myData) <- works
}
func somethingNeedingDataObject(dataObject: myData?) {
// now have to explicitly unwrap
let myDataUnwrapped = myData!
...
}
This just seems to be an extremely verbose way to deal with the issue. If an object is nil, won't the explicit unwrap in and of itself cause a runtime error (which could be caught and handled)? This tends to be a nightmare when stringing things together. I've had to do something like:
self.dataConnection!.somethingReturningAnObject!.thatObjectsVariable!.someMethod()
var myData? = self.dataConnection
var anotherObject? = myData!.somethingReturningAnObject
...
The way I'm used to doing this is that you simply define a variable, and if it is set to null and you try to do something with it, an exception (that you can catch and handle) is thrown. Is this simply not the way things work anymore in Swift? This has confused me sufficiently that just about every time I try to compile an app, I get tons of errors about this (and I just let Xcode fix them). But this can't be the best way to deal with it.
Do I have to consistently deal with wrapping and unwrapping variables - even those which are expected to never be null in the first place but simply can't be assigned at compile time?
However, I do not know how to define a class-level variable via let which will be assigned at runtime.
This part is easy. Just use let instead of var. With Swift 1.2 and later, you can delay the actual assignment of a let. The compiler is smart enough to do flow analysis and make sure it's assigned once, and only once, in all paths. So in the case of a class-wide let, the assignment can also happen in the constructor.
But now I have to deal with the nullable data type, and do explicit unwrapping every time I use it anywhere.
But this is what implicitly unwrapped Optionals are for. For example, StoryBoard defines all #IBOutlets as implicitly unwrapped, because the semantics are very clear: upon entrance to viewDidLoad() and everywhere after, unwrapping is safe. If you can prove clear semantics to yourself, you can do the same.
So you have roughly 4 choices:
A) declare at class level as implicitly unwrapped:
let dataConnection: MyData!
And be forced to initialize it in the constructor:
init() {
let whateverObj = someInitialCalculation()
dataConnection = whateverObj.someWayOfGettingTheConnection()
}
And from then on you don't need the '!'; it should be clear that implicit unwrap is always safe.
B) Initialize it right in its declaration if its initialization is reliable and sensible at that point, allowing you to forgo the entire concept of Optionals:
let dataConnection = SomeClass.someStaticMethod()
C) Declare at class level as a var, as implicit optional:
var dataConnection: MyData!
You won't have to init it in the constructor; let it be nil until its value can/should be computed. You still need some flow analysis to prove after a certain point, as in the case of #IBOutlets, accessing it will always be valid
D) The most 'unpredictable' case. Declare it as an explicit optional, because throughout the lifecycle of the class, the data connection will come and go:
var dataConnection: MyData?
func someMethodThatHandlesData() {
if let dC = dataConnection {
dc.handleSomeData()
}
else {
alert("Sorry, no data connection at the moment. Try again later.")
}
}
I think you're imagining that Swift always forces you down path D).
As far as your spaghetti-string code, you want to look into Optional Chaining, and only need to check the end result for nil.
What is the best way to handle a helper table (I think there's a more technical word for that but it's escaping me at the moment)? For instance, my object named Entity has an entity_type property. That entity_type needs a string description along with it. Let's assume there are only a handful of entity_types possible.
So I can see going a few ways:
Having another Core Data entity object name Entity_Type and joining it to-many so that I can obtain the description easily. This will allow me to use in a UIPickerView easily, for example.
I could also see why #1 is a trap because later on I will need to do something like a switch/case to handle specific functionality for each type. Being a Core Data object, I have no "id" per say in order to do the switch statement. The alternative would be to hard code an enum, but then how would I handle the descriptions?
Maybe a combination of the two?
Any advice or experience with a similar situation would greatly help. I tried searching, but all I turned up was how to find the ID of a CD object, which is irrelevant.
The 'combination' approach you speak of would work something like this:
You have your Entity_Type with a string description, and an NSNumber 'enumValue' attribute.
Then you define an enum type with explicit values for forwards and backwards compatibility (you don't want people inserting a new enum at the top and breaking everything).
// these values must not change
enum Foo {
FooType1 = 1,
FooType2 = 2
};
Now, you don't want to deal with your 'enumValue' attribute as an NSNumber, so rather than using #dynamic to generate the property, you define your own getter/setter to expose a native enum value rather than an NSNumber. Something like this:
- (void)setEnumValue:(enum Foo)newValue
{
NSNumber *numberValue = [NSNumber numberWithInt:newValue];
[self willChangeValueForKey:#"enumValue"];
[self setPrimitiveValue:numberValue forKey:#"enumValue"];
[self didChangeValueForKey:#"enumValue"];
}
- (enum Foo)enumValue
{
[self willAccessValueForKey:#"enumValue"];
NSNumber *numberValue = [self primitiveValueForKey:#"enumValue"];
[self didAccessValueForKey:#"enumValue"];
// optionally validate against possible enum values, maybe handle the case
// when you are reading a database made by a later version which has new
// unknown-to-us values, etc.
return (enum Foo) [numberValue intValue]
}
I have written this code from memory but that's the general gist of things. The getter/setters talk to the underlying managed object's NSNumber value, but your object itself exposes the property as your strongly typed enum type.
You can then define some helper methods to fetch out the associated entity for an enum value. This should just be a simple fetch request with a enumValue == %# predicate.
You also have to be careful with dealing with unknown enum values. An older version of your software may end up reading a database that contains new enum values that it has no knowledge of.
I've used enums in the past. Like I have a entity to represent a cost and it has a costType which I define as an enum and store in core data as an int. There are 4 possible costTypes (fixed, time, product, travel) and depending on the cost type the cost value will be calculated differently.
I think this is what your getting at, else I'd say give me a firmer example.
I'd suggest two more tools to aid.
Be aware of the NSObject "description" method which you can override, to provide string representation of anything. So if you subclass NSNumber to create an NSNumber that only allows your enumerated set of values, you can also add the "description" method that will simply lookup the value as index in some array of descriptions. Something like
Be very aware of NSValueTransformer! you can create a standalone transformer from any type to any type (and back, for two-way transformers). You can attach a transformer directly to the UI in your .xib, so when you set a NUMERICAL value (your enum) to the UI field, the user will see THE TRANSFORMED (string) value. This also works the other way round.
I'm not attaching code because I'm in a hurry, but I'll do sometime soon.
The above methods are alternative solutions, but maybe you can combine them in the manner suggested by Mike Weller --- Add a new strongly-typed enumerated accessor to the attribute in core-data (which will be some kind of int), but instead of using an enum, use a subclass of NSNumber that has "description" overridden, and Enum accessors as well.
Then define a transformer for this class (into string) that will simply return the description when transforming to string, and will do the opposite when given the description.
Attach this transformer to your UI, and voila!
The techniques described here are Mac too, not just iOS.