Deferred Dependencies

APL-related discussions - a stream of APL consciousness.
Not sure where to start a discussion ? Here's the place to be
Forum rules
This forum is for discussing APL-related issues. If you think that the subject is off-topic, then the Chat forum is probably a better place for your thoughts !

Deferred Dependencies

Postby Morten|Dyalog on Wed Mar 28, 2018 3:05 pm

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!
User avatar
Morten|Dyalog
 
Posts: 329
Joined: Tue Sep 09, 2008 3:52 pm

Re: Deferred Dependencies

Postby Dick Bowman on Wed Mar 28, 2018 3:55 pm

Maybe have the default as a configuration option?
Visit http://apl.dickbowman.com to read more from Dick Bowman
User avatar
Dick Bowman
 
Posts: 235
Joined: Thu Jun 18, 2009 4:55 pm

Re: Deferred Dependencies

Postby Morten|Dyalog on Wed Mar 28, 2018 4:40 pm

Dick Bowman wrote:Maybe have the default as a configuration option?


Possibly, if you can explain why it would help you :-).
User avatar
Morten|Dyalog
 
Posts: 329
Joined: Tue Sep 09, 2008 3:52 pm

Re: Deferred Dependencies

Postby StefanoLanzavecchia on Thu Mar 29, 2018 8:20 am

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.
User avatar
StefanoLanzavecchia
 
Posts: 64
Joined: Fri Oct 03, 2008 9:37 am

Re: Deferred Dependencies

Postby paulmansour on Thu Mar 29, 2018 1:07 pm

For the love of God, please don't make it optional!
paulmansour
 
Posts: 282
Joined: Fri Oct 03, 2008 4:14 pm

Re: Deferred Dependencies

Postby Morten|Dyalog on Thu Mar 29, 2018 1:14 pm

Dick Bowman wrote: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?
User avatar
Morten|Dyalog
 
Posts: 329
Joined: Tue Sep 09, 2008 3:52 pm

Re: Deferred Dependencies

Postby Phil Last on Thu Mar 29, 2018 1:26 pm

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!
User avatar
Phil Last
 
Posts: 485
Joined: Thu Jun 18, 2009 6:29 pm

Re: Deferred Dependencies

Postby Dick Bowman on Thu Mar 29, 2018 2:02 pm

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.
Visit http://apl.dickbowman.com to read more from Dick Bowman
User avatar
Dick Bowman
 
Posts: 235
Joined: Thu Jun 18, 2009 4:55 pm

Re: Deferred Dependencies

Postby paulmansour on Thu Mar 29, 2018 3:13 pm

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
 
Posts: 282
Joined: Fri Oct 03, 2008 4:14 pm

Re: Deferred Dependencies

Postby paulmansour on Thu Mar 29, 2018 3:20 pm

I forgot to note that ⎕FML should probably be able to be localized.
paulmansour
 
Posts: 282
Joined: Fri Oct 03, 2008 4:14 pm

Next

Return to APL Chat

Who is online

Users browsing this forum: No registered users and 1 guest