Deferred Dependencies

[Morten|Dyalog]

In version 17.0, we are going to make it possible to define a class which has dependencies that have not yet been defined (both in the editor and using ⎕FIX). Potential dependencies are base classes, interface definitions, or :Include of namespaces which do not exist. An error will be issued on first use of a class which has missing dependencies, rather than at "fix time".

The primary motivation for this change is to make it easier to define a "folder full" of source files in (for example) alphabetical order, rather than needing to take care to fix the base classes first, and then classes which depend upon them. Secondarily, it allows you to work "top down" when defining a class hierarchy.

Existing applications might be trapping errors at fix time and not have trapping in place at use time, which means this is a potentially breaking change. At the same time, I believe that in nearly all cases, the change will be a very significant improvement.

This leaves us with a dilemma with respect to picking a default. We would like this new behaviour to be on be default, but worry about making a breaking change without more notice. I'd be interested to hear any opinions on what the default should be, in particular if you think it should be OFF by default.

Thanks in advance for sharing opinions on this!

[Dick Bowman]

Maybe have the default as a configuration option?

[Morten|Dyalog]

Maybe have the default as a configuration option?

Possibly, if you can explain why it would help you :-).

[StefanoLanzavecchia]

We wrote ages ago a bit of code to build the dependency tree: the code parses the source code for the class definitions. The parser is somewhat primitive because it ignores ":include"s and nested classes. But it gets the job done for our use cases.

The addition you propose wouldn't break any of our code and it's likely that it would simplify it. So we welcome it! And we'd be glad if it was the new exclusive behaviour.

[paulmansour]

For the love of God, please don't make it optional!

[Morten|Dyalog]

Maybe have the default as a configuration option?

Dick, can you elaborate on whether that was just a helpful "if you can't decide, why not make it an option", or you actually have scenarios where you actually NEED a failure at fix time, and an option would be important to you?

[Phil Last]

None of this makes sense.

Morten's first post introduced the idea of a default. If there is a default then it must follow that non-default behaviour is possible.

Hence options

Agree with Stef's "exclusive" and Paul's higher plea.

Please do not make it optional. No default. Just do it!

[Dick Bowman]

My suggestion of a configuration option was made as nothing more than an off-the-cuff sense that whatever you do someone will disagree - so let people make their own decisions (I'm assuming, of course) that when you write "default" you imply that non-default behaviour will be legitimate.

[paulmansour]

Morten clearly says the feature/change will be optional, but does not indicate if it would be permanently or temporarily optional. The only question then is it a configuration option or ⎕DoYouWantTheNewClassFixingBehavior.

I think if it is optional, we need to introduce, for consistency, the idea that you can't fix a function if it refers to functions or variables that don't exist - you would get a value error at fix time. This should probably be on by default, as it has the salutary effect of prohibiting the use of global variables, or at least making it difficult to use them.

Perhaps we should have ⎕FML for Fixing Migration Level. 0 is the current behavior. 1 means functions are checked at fix time, and classes are checked at run time. 2 means both functions and classes are checked at fix time, and 3 means both functions and classes are checked at run time. We might need some additional options for operators and scripts - I haven't really worked all that out yet.

[paulmansour]

I forgot to note that ⎕FML should probably be able to be localized.