if you assume that classes are in a “tree like” arrangement (starting with the top level super at the top and most derived subclass at the bottom) you’d have
ISA can test going UP (so an instance of a sports car ISA automobile)
And an instance of a plane ISA Vehicle
But the reverse is not true - a Vehicle is not a “plane” - it could be a train or an automobile
With object references though it IS legal to do
dim v as vehicle = New SportCar
Now why is this legal ? Well … a sports car IS a automobile. and an automobile ISA vehicle.
So the Vehicle reference can refer to the sportscar BUT when you do this asnd treat the sports car as a VEHICLE you can only use the methods & properties that exist for VEHICLE - because VEHICLES know nothing about sportcars and any of their special properties etc
But if you do
dim v as vehicle = New SportCar
if v isA SportsCar then
dim s as sportscar = SportsCar(v)
// in here you can use ALL the special bits that are "sportscar"
end if
This is one of those topics that is covered in the free book http://www.xojo.com/learn/
There will be lots you can skim over if you’ve been writing code for a long time - loops are loops are loops
But the object oriented bits will be of relevance as this is exactly what you’re asking about here
Thanks for the examples. I have been through that whole book and there is much of this that is not covered, nor is it in the language reference.
In your last example, why would I need to cast v as SportsCar? It already is, as it passed the IsA test. What happens if after the first Dim statement I treat v as a SportsCar, that is use a method only in that subclass? What is different about s and v after the cast?
[quote=302562:@Jon Fitch]In your last example, why would I need to cast v as SportsCar? It already is, as it passed the IsA test.
[quote]
Passing the test doesnt mean you CAN use it as one - its still JUST a VEHICLE
The test just tells you it IS safe to do that cast
[quote=302562:@Jon Fitch]I
What happens if after the first Dim statement I treat v as a SportsCar, that is use a method only in that subclass? What is different about s and v after the cast?[/quote]
Well you’d have to try it but as long as its a VEHICLE and you can use any sports car bits
Probably need to expand the example
Class Vehicle
Function Name() as String
return "Vehicle"
end Function
End Class
Class Plane
inherits Vehicle
Function Name() as String
return "Plane"
end Function
End class
Class Train
inherits Vehicle
Function Name() as String
return "Train"
end Function
end class
Class Automobile
Inherits Vehicle
Function Name() as String
return "Automobile"
end Function
end class
class SportsCar
inherits Automobile
Function Name() as String
return "SportsCar"
end Function
end class
dim v as vehicle
v = new SportsCar
print v.name
And this all works a LO this prints “SportsCar”
That is goo and is because since VEHICLE has a public method named Name so EVERY subclass either has their own which will get used (overriding) or the one in vehicle will get used
But if we alter this just a tiny bit like
Class Vehicle
Function Name() as String
return "Vehicle"
end Function
End Class
Class Plane
inherits Vehicle
Function Name() as String
return "Plane"
end Function
End class
Class Train
inherits Vehicle
Function Name() as String
return "Train"
end Function
end class
Class Automobile
Inherits Vehicle
Function Name() as String
return "Automobile"
end Function
end class
class SportsCar
inherits Automobile
Function Name() as String
return "SportsCar"
end Function
end class
dim v as vehicle
v = new SportsCar
print v.name
print v.Make
This will NOT run because - ONLY SPORTS cars have a MAKE method
And its NOT accessible from Vehicle
So in this case you would need to alter the last bit to
print v.name
if v isa SportsCar then
// since it ISA sports car we should treat it as one and not as a VEHICLE
dim s as SportsCar = SportsCar(v)
print s.Make
end if
FWIW you can try this code right away
Start the IDE
Then under the File menu select IDE Scripts > New IDE Script
And paste the code that I put in here in there and press run
It uses the same compiler and understands the same language
Right. The object that v points to is a SportsCar, and ISA rightly identifies it as such. However, the variable v is a Vehicle, not a SportsCar. Therefore you have to cast it as a sportscar, so the compiler knows that you expect v to contain a SportsCar instead of a plain Vehicle. It will not do the conversion on its own. By casting it, SportsCar(v) expects to receive a sportscar object. This is where the runtime checks to see if it actually is a sportscar.
dim v as vehicle
dim s as sportscar
s = v // the compiler will complain that this is illegal
s = SportsCar(v) // this satisfies the compiler, as you are promising to supply a sportscar object.
// this defers the type check until runtime, where you'll get an exception if it's wrong