The JADE 2022 release meets tomorrow’s business demands.
New RootSchema Iterable Interfaces
JadeIterableIF Interface
Definition
JadeIterableIF
- createIterator(): JadeIteratorIF;
Summary
The equivalent to the .NET IEnumerable or Java Iterable interfaces. JadeIterableIF is an interface that defines one method createIterator(), which returns a JadeIteratorIF interface providing the ability to iterate the JadeIterableIF implementor receiver. This allows non-Collection classes to be iterable and furthermore used in foreach statements.
Implemented by: RootSchema::Collection
JadeIteratorIF Interface
Definition
JadeIteratorIF
- next(value: Any output): Boolean;
- current(value: Any output): Boolean;
Summary
The equivalent to .NET IEnumerator or Java Iterator interfaces. Abstracts the current RootSchema::Iterator class exposing the Iterator::next(), Iterator::current() methods.
An object that implements the JadeIteratorIF interface generates a sequence of elements, one at a time. Successive calls to the next() method return successive elements of the sequence.
JadeReverseIterableIF Interface
Definition
JadeReverseIterableIF extends JadeIterableIF
- createReversibleIterator(): JadeReversibleIteratorIF;
Summary
The JadeReverseIterableIF interface extends JadeIterableIF and similarly defines one method createReversibleIterator(), which returns a JadeReversibleIteratorIF interface providing the ability to iterate the JadeReverseIterableIF implementor receiver in multiple directions.
Implemented by: RootSchema::Collection
JadeReversibleIteratorIF Interface
Definition
JadeReversibleIteratorIF extends JadeIteratorIF
- back(value: Any output): Boolean;
Summary
The JadeReversibleIteratorIF interface extends JadeIteratorIF and similarly abstracts the current RootSchema::Iterator class exposing the Iterator::back() method.
An object that implements the JadeReversibleIteratorIF interface generates a sequence of elements, one at a time, in both a forward and backward direction.
John Richards
Hi Matt,
Yes, I can appreciate the challenges involved - and with that in mind, I'd have been happier to wait until a future release before it was delivered - or deliver what's there with a feature toggle so we can just experiment with it & provide feedback, until it's ready for production use once outstanding issues are resolved.
Of the two potential migration paths mentioned - I'd certainly prefer the second, rather than creating duplicate interfaces (likely to have less friendly names and cause confusion). However, I'm still concerned about migration problems that'll arise if the conversion process has to update any method references. As we'll have patches in the pipeline extracted from an environment that hasn't been upgraded, we wouldn't want any compilation errors to occur when they're loaded into an upgraded system because the <Any> is missing, and we wouldn't be able to add the missing <Any> to patches in-flight as we'll still need the ability to load them into systems that haven't been upgraded.
To avoid problems of this nature - It'd be preferable if the generic interfaces implementation could default to the <Any> variation, without making any code changes (method & property references). Does/could it support that? (i.e. default type parameters without the < > brackets).
Hi Kevin,
As I'm sure you can appreciate, it has been a lot of work attempting to introduce a dynamic type system into the language and as some issues could not be addressed in time for the release, we have made the decision to postpone the feature to a later release.
To address your second and third question. We do not believe using these new interfaces will cause code to break in the future. When generic interfaces are introduced, one of two things will happen:
We will introduce new separate generic versions of the Iterable interfaces along with a tool of some sort, to easily convert existing usages/implementations to the generic versions - giving the user the choice.
As part of the upgrade we will convert the interfaces to equivalent generic interfaces and all references will be upgraded to <Any> variations, as this is essentially what the non-generic versions represent.
What happened to the generic interfaces? If we were to start coding against these new interfaces without being able to specify the type per #429, will future upgrades that introduce generic interfaces with this break our code? Will we end up with another set of iterable interfaces defined in more generic manner?