JADE Environment Development Ideas

For the upcoming 2020 JADE release, the foreach instruction has been extended to include an optional as clause.

foreach variable in collection-expression [as type‑expression] [options] 

    [where condition] do [:label]

    [foreach-instructions]

endforeach [label];

This type-expression can include either an explicit type name or an expression that evaluates to a type and can be used to relax compile time restrictions to the foreach instruction's target variable. This syntax was chosen over simply relaxing the compile time restrictions, to make the intent of the code more explicit.

Using the example originally posted the following will be possible:

writeCustomerNames(customers: Collection);

vars

	customer: Customer;

begin

	foreach customer in customers as Customer do

		write customer.name;

	endforeach;

end;

When executed, a runtime exception will be raised if a value retrieved is not compatible with Customer.

The following feedback was posted on the FB User group:

Kevin Saul > Might be easier to discuss this one here as we don't get notifications from JEDI when others add comments (unless they're an admin). In general, I think generic interfaces will help with the issue highlighted (especially for new code), but updating/simplifying foreach statements while updating existing code depends on surrounding code being changed to use generic interfaces. If that involves changing existing method parameters to supply a collection or iterable interface, where we may just supply a basic collection type currently, it could lead to wider code changes to update method references (which'll lead to retesting). In cases like that, we'd probably prefer to stick with the current approach if we can't justify refactoring existing code to use generic interfaces. With that in mind, the original idea to relax the foreach variable requirements still has merit in my opinion, but I also agree with other comments about compiler vs runtime checks, so it'd be good to see this implemented with BeeJay's idea of using an 'as' modifier so we can explicitly indicate what type we expect a collection to contain at runtime.

Sam Stokell > It seems inconsistent that iterators are more flexible so I'm all for the change it will prevent all those casting lines directly after the foreach

Craig Shearer > I'm the originator of this suggestion. It's safe for existing code - i.e. code that compiles already can't be broken by relaxing this. It's only code written in the future that isn't protected by the existing restriction - then the developer needs to be more careful and test their code, but it's no different from an Iterator. But, BJ's suggestion of an "as" qualifier seems workable, albeit with lengthier syntax.

Generics sound like a great solution to me 👍

The Generic Interfaces feature under development for the 2020 release is described by: https://jedi.ideas.jadeworld.com/ideas/JAD-I-429.

The JADE plant is actively working on a feature set that includes support for generic interfaces implemented by RootSchema classes, language support for iterating over the equivalent of Enumerable / Enumerable<T> in .NET using foreach syntax. We plan to publish a JEDI idea to show the community what this might look like and to solicit feedback.

With the above mind, we believe generic interfaces could be applied to solve the use case shown here without compromising type safety.

Assume for a moment that JADE supported generic interfaces where we could define a JadeIterableIF<T> interface equivalent to IEnumerable<T> in .NET or Iterable<T> in Java.

With support for generic interfaces, we can arrange that the RootSchema::Collection class implements JadeIterableIF<T> where T is essentially equivalent to MemberType.

With that we can change the example signature to:

 writeCustomerNames(customers: JadeIterableIF<Customer>);

Now, given language support for foreach over JadeIterableIF<T>, the foreach int he method body would compile without error.

Usage

Using the example collection types in File Vision's post: The collection types

CustomerArray, CustomerSet and CustomerDictionary would implicitly implement JadeIterableIF<Customer>, the following calls are all valid.

writeCustomerNames(CustomerArray)
writeCustomerNames(CustomerSet)
writeCustomerNames(CustomerDictionary)

We are keen to receive feedback from the originator and voters for this idea on this alternative type safe alternative approach.

• Would use of generic interface suit the majority of use cases?

• Do you still see a need for a downcast capability subject to runtime exceptions?