If you came to REAL World (which you should have -- it was awesome, as usual!), and you came to my Design Patterns I talk (which you also should have, unless you're an OOP expert), then this is not new information for you. However, since many of you missed out on the year's greatest REALbasic related gathering, I'll release this tidbit into the wild.
Interface contracts can be satisfied by non-public methods.
I'll let that sink in for a moment before continuing on... ;-)
..
..
..
..
Ok, so what does that mean? It means that you can satisfy an interface's contract using private and protected methods as well as public ones. Sounds scary, but it's actually the basis for some really powerful features when combined with future REALbasic language features.
Here's an example of what I mean so that our discussion can become a little more concrete.
Interface Foobar
Sub Wahoo( s as String )
End Inteface
Class Yippee Implements Foobar
???
End Class
Most people implement the ??? part with "Sub Wahoo( s as String )" and are happy. And that's almost always what you want to do, too. That satisfies the Foobar contract with a public method. However, you can also implement it with "Private Sub Wahoo( s as String )" and it will work too! So let's say you do that -- what does that mean?
It means that someone with an instance of Yippee cannot call Wahoo on it (since Yippee.Wahoo is private). But Yippee also IsA Foobar, and Foobar has a public method called Wahoo on it. So if the user has an instance of Foobar instead, then it can call Foobar.Wahoo!
This may seem like a silly thing, or even a bug. But it's actually a very important, powerful feature. Due to the unreleased nature of things, I cannot go into details. However, once things become released, then expect to see a continuation of this discussion.
There were some VERY interesting things that this allows you to do especially when combined with another yet to be released feature
Mars metioned it in one of his sessions and it has some VERY cool implications
Cool stuff !
Now, that said, if a person has a Yippee could they not still cast it to a Foobar and call wahoo ?
Something like Foobar(Yippee).Wahoo
That's exactly correct -- that's what I meant by having a reference to a Foobar instead of a Yippee. Foobar can call Wahoo, Yippee cannot. But since Yippee IsA Foobar, you can cast them around via the wonders of polymorphism.
Aaron,
Why did you think that was some kind of deep dark secret? I've used it for awhile... and I never have even been to Real world! ;)
I tend to try things that should logically work (they don't always ) when looking to solve a problem ... and that was one that did work.
Interfaces are something I worked with a lot to generalize things early on while learning to use RB.
- Karen
@Karen -- you're doing better than everyone at REAL World then. ;-) This is a language feature that I believe is unique to REALbasic (obvious or not), but is really quite neat.
Ah but was it originally implemented that way on purpose or by oversight? ;-)
Sometimes not having a computer science background and being self taught might make one think of trying things that others would not because of their education.
I'm very curious about what the new feature that will be paired with it will be... but I know I will have to wait!
- Karen
Do I smell controlled internal class access from RBScripts? This technology would seem to be a shoo-in for that purpose.
It's certainly not intuitive
I dont know of another language I've used that would let you do this
I just checked VB.NET and it will do this also. I didn't know it would. Interesting ramifications.
Thanks, Aaron!
-John
@Karen -- It was entirely by design.