Every once in a while you run into some code that tries to present a fairly abstract API to some class \/ module. Maybe this is in your own code or in code you have received from some other source.<\/p>\n\n\n\n
But as you work with it you find that the abstraction reveals internal implementation details that really should not be known outside the class. One way to hide these sorts of details from other portions of your code is to use an API defined in an interface.<\/p>\n\n\n\n
However, even that doesnt always work.<\/p>\n\n\n\n
Suppose you have some set of classes where you want to make it possible for one to contain many of the others and that the internal storage mechanism should be invisible, or at least not easily guessable, from other classes. Something like you see in the IDE where you have Folders that can contain all kinds of other items, or Modules that can also contains other items.<\/p>\n\n\n\n
It would make sense for the classes that represent such a Container type to implement the Xojo.Core.Iterable interface so you could use either in a For … Next loop.<\/p>\n\n\n\n
Lets start by assuming we’re going to create a set up like <\/p>\n\n\n\n
Class ContainerType\n Implements Xojo.Core.Iterator\n\n Function MoveNext() as Boolean\n End Function\n\n Function Value() as Auto\n End Function\nEnd Class\n\nClass FolderType\n Inherits ContainerType\nEnd Class\n\nClass ModuleType\n Inherits ContainerType\nEnd Class<\/code><\/pre>\n\n\n\nWe’ll have a base ContainerType class and then two subclasses*. The names of the classes I’ve chosen don’t conflict with built in ones.<\/p>\n\n\n\n
At this point you might think you could write<\/p>\n\n\n\n
Dim f As New ContainerType\n\nFor Each foo As Auto In f\n \nNext<\/code><\/pre>\n\n\n\nbut you can’t. In a for .. each you need an item that implements Xojo.Core.Iterator – not Xojo.Core.Iterable.<\/p>\n\n\n\n
OK we need an iterator so we’ll add one like<\/p>\n\n\n\n
Class ContainerTypeIterator\n Implements Xojo.Core.Iterator\n\n Function MoveNext() as Boolean\n End Function\n\n Function Value() as Auto\n End Function\nEnd Class<\/code><\/pre>\n\n\n\nAs well we need to make our initial class implement Xojo.Core.Iterable<\/p>\n\n\n\n
Class ContainerType\n Implements Xojo.Core.Iterable\n\n Function GetIterator() as Xojo.Core.Iterator\n End Function\n\nEnd Class\n\nClass FolderType\n Inherits ContainerType\nEnd Class\n\nClass ModuleType\n Inherits ContainerType\nEnd Class<\/code><\/pre>\n\n\n\nAnd now we can write<\/p>\n\n\n\n
Dim f As New ContainerType \/\/ or new FolderType or new ModuleType\n\nFor Each foo As Auto In f\n \nNext<\/code><\/pre>\n\n\n\nBut how do we make the Iterator itself work ? Unfortunately there don’t seem to be any Xojo code examples and the docs are kind of light on this.<\/p>\n\n\n\n
The iterator isnt a “friend” of our base class so it cannot reach into its guts and grab whatever data it wants. Especially not if that data is protected or private in any way. So our Iterator needs some api to be able to get the data it needs from our ContainerType classes. So we need an API for that.<\/p>\n\n\n\n
But whatever API we put on the ContainerType class is also going to be usable outside the Iterator. There’s no way straight forward simple way to restrict an API to ONLY being by one class in Xojo. (This is where “friend” classes would be handy as they could have a “special” relationship and be allowed to use some private api that no other class could – there are hacky ways to achieve this though)<\/p>\n\n\n\n
And so however you implement the Iterator & its access to the individual members of each class that implements Iterable those API’s are usable by ANY other code. And so that abstraction of “iterable” and how it’s implemented leaks out to the rest of the world.<\/p>\n\n\n\n
Stopping this leakage can be done – in a limited way. In a module you can have an interafce that is private to that module and then classes that are in that module can implement that interface. Only methods and other classes in that module can then use that interface.<\/p>\n\n\n\n
Module Containers\n Private Interface PrivateContainerAccessors\n Function MoveNext() as boolean\n Function Value() as Variant\n End Interface\n\n Class ContainerType\n Implements Xojo.Core.Iterable\n\n Function GetIterator() as Xojo.Core.Iterator\n End Function\n\n Function MoveNext() as boolean\n End Function\n\n Function Value() as Variant\n End Function\n\n End Class\n\n Class FolderType\n Inherits ContainerType\n\n Function MoveNext() as boolean\n End Function\n\n Function Value() as Variant\n End Function\n\n End Class\n\n Class ModuleType\n Inherits ContainerType\n Function MoveNext() as boolean\n End Function\n\n Function Value() as Variant\n End Function\n\n End Class\nEnd Module\n <\/code><\/pre>\n\n\n\nAnd now only classes IN the module can cast the classes that implement this interface in a way they can call the interface methods. This is quite handy – but it does have a drawback. Nothing outside this module can implement that interface. And that limits its usefulness to code you write and put in that module.<\/p>\n\n\n\n
Friend scope would be really handy. In the mean time this is as close as you get and can stop your Iterable abstraction and the implementation from leaking out into the rest of your code.<\/p>\n\n\n\n
*This really is JUST an example and not actual Xojo IDE code for those of you who might be suspiciously minded – I can assure you the IDE is vastly different than this – this is JUST an example that you can relate to from using the IDE<\/p>\n","protected":false},"excerpt":{"rendered":"
Every once in a while you run into some code that tries to present a fairly abstract API to some class \/ module. Maybe this is in your own code or in code you have received from some other source. But as you work with it you find that the abstraction reveals internal implementation details … <\/p>\n