Let's take a step away from our project and open up a new playground for a second.

In here, I have some code you can grab this code as well using

code snippet link in the teacher's notes of this video.

Go ahead and paste that into a playground in your end.

We start with a base class here, Employee, that contains just a name.

HourlyEmployee inherits from employee and adds information like hourly wages.

Similarly, salaried employee also inherits from employee and adds a salary property.

At the bottom here we have an array of employees.

We know from learning about arrays that Swift

arrays can only contain a single type.

But as you could see here we have two types, salaried and hourly employee,

both in the same array.

How is that possible?

Well, both these types have a common base type and when we mix and

match them in the array, Swift converts or

casts each object to the base type to satisfy the array homogeneity rule.

Meaning, they have to be the same thing in that array.

So if you check the type of the array, employees,

you'll see it's an array of employee rather than any of the specific subtypes.

It can only do this because they both share the same base class.

Let's add some code to each of our subclasses.

So over here now, you'll see that HourlyEmployee has a payWages method

that simply returns the wage times the hours work.

And the SalariedEmployee has a paySalary method.

So each of these has their own distinct pay method.

Now let's say we want to iterate through the items through the employees in

this employees array and pay each employee.

So we could say for employee, in employees and

then you'll notice that if we try to call either pay wages or pay salary,

none of those methods appear in the autocomplete and they just don't work.

This is because the type of each item that we get out of the array

is neither hourly nor salaried employee but the base class employee.

If you click on here, it says this is an instance of employee and

you'll notice that the class employee does not have any pay method so

we can't call anything on it.

At this point, the compiler does not know about these pay methods because it

thinks this is an Employee class.

To actually use this instance in the right context, we can either check but

it is the right type that we need or downcast them to a different type.

And to do that we have two operators at our disposal.

Let me get rid of this line of code.

The first one is the is operator.

The is operator returns true if the type matches a type we specify and

false if not.

So we can use it to inspect each item from the array.

So I can say, if employee, which is what we're pulling out of the array, the first

instance, is an instance of hourly employee, then go ahead and print hourly.

And you'll see that this has been executed once because there are two instances

only one of which is an hourly employee.

And similarly, we can say if employee is salaried employee, then print salary.

And this should also be executed just once.

Even though the array thinks that these items are of the base classes type,

we can check to see if there are instances of the sub class.

Now we don't want to get into the details of how this is done exactly in

the background.

But just know that even though it's an employee base class,

it actually contains information about what it actually is.

But all this allows us to do is check it, right?

I still can't call pay wages on this instance or pay salary on this instance.

What if we want to actually work with the specific sub types?

For that, we have another operator,

the Typecast operator as employee in this example is

a higher less specific type than any of the subclasses.

The as operator allows you to cast

to one of the more specific subclasses in a process known as downcasting.

It's called downcasting because if you think of the object graph as a tree, with

the base type on top, and more specific types as nodes extending downwards.

Then when going from a base, to a subclass we go down the tree.

Downcasting may not always succeed.

So the typecast operator comes into two flavors, the conditional form as with

a question mark and the forced form, as with an exclamation point.

The forced form, like the forced unwrap operator,

should only be used when you know the downcast will succeed.

For example, in our code, we verified that an employee instance

is of a particular type by using the type check operator.

We know that this employee here is an instance of the subclass for sure.

So inside the if statement, we can use the Force operator to downcast the instance.

So we can say let hourlyEmployee = employee as HourlyEmployee.

And now this instance is of type hourly employee.

This is the specific sub-class that we want and we can call the right method.

So we can say hourlyEmployee.payWages for 10.00 hours.

Similarly, if we were to do the same thing in here, we could say it let

salariedEmployee = employee as, and we're forcecasting

because inside this if statement, we're sure that employee is a salaried employee.

And then once we've done that, we can easily call paySalary.

The forced downcast operator, like the forced unwrap operator,

should be treated carefully however.

Only do this if you're 110% sure the downcast will succeed,

otherwise your application will crash.

For a safer option,

you can use the conditional typecast operator as with a question mark.

This operator returns an optional value if the CAS succeeds or nil if it fails.

So over here instead of as with an exclamation point, you can say,

employee as with a question mark.

Then when we do this, this instance now is an optional instance of HourlyEmployee.

So to call the pay wages method we have two options.

First, we can use optional chaining and

use a question mark to chain that method to the optional instance.

Or much cleaner, we can combine this, check over here,

employee as HourlyEmployee, with either and if let or

a guard let statement to unwrap the resulting value at once.

So we can see if let hourlyEmployee and then in here we

can call the right method on the unwrapped instance.

And as expected,

it should work and you'll see that we're calling and paying the wages right there.

Okay, that was a quick sidebar on what ambiguous types and downcasting is.

Now that you know this, let's head back to our main project.

Okay, where were we?

So we go to dictionary out of the P-list, but

we can't return it because it is the wrong type.

And NS dictionary in Swift is more specifically represented as

NS object to any object.

NS Object is an objective C type that is the base class for

every object in the language.

Similarly, any object represents any class in Swift because they both represent very

high level types, they can be downcast to a more concrete type that we want.

For now, we only want to cast the keys to strings.

We're going to return the values as any object, and

we'll do this by adding another condition to our guard statement right here.

So rather than adding a new one, we'll say guard let dictionary = and then I'm gonna

say as, I'm gonna use a question mark here cuz I don't want to force unwrap it, and

I'll say or forcecast in, then we'll say as string to any object.

So here we're using the conditional downcast operator to try and

cast the dictionary to the type we want.

If it works we have a dictionary cast to the right return type.

If not, we throw our conversion error.

And now we can finally return the dictionary.