Fracture dLux\utils into another package.

[Jordan-Dennis]

Hi all,
this is an issue of some contention. Here is my attempt at an overview of the different perspectives. I have labelled these as the OOP persp, and the If it ain't broke don't fix it persp. I have also included a brief summary of other important information that is not a part of either perspective but not detailed enough to warrant a third [perspective].

OOP persp:

Moving functionality into functions and then calling them from within classes that implement no/very little of their own functionality is not a very object oriented design pattern. This is not necessarily a bad thing because object oriented programming is not the best paradigm for some problems. In an object oriented programming language like dart or java this is not even possible, instead you would put such functionality higher in the hierarchy so that it could be inherited. Alternatively for certain cases a static or singleton class might be the best design pattern to use.

Python is not an object oriented programming language. It is a general purpose language that implements some object oriented features. However, we decided that we were going to develop dLux in an object oriented way. So what are the benefits of strictly adhering to object oriented design? I believe that the primary motive to adhering to a single paradigm (as much as python allows) is translatibility. A developer or user who is familiar with object oriented programming can understand our code even if python is not their primary language.

Another advantage of using only object oriented design patterns is abstraction. In a procedural language, such as c one can define types, but the behaviour of the type is not included in that definition. Instead the type works be defining a specific pointer structure so that the various components can be accessed from memory. By including the behaviour as part of the pointer, you are left with a level of abstraction that is very relatable to the real world. Wavefronts and Apertures ect.

If it ain't broke don't fix it persp:

dLux/utils/ by no means causes things to break. It is safe, time-tested code. At the present it is not unit tested (functions that call it are) and I am not aware of any plans to add formal tests for it. Dividing it into another package would force us to write tests. Changing would produce some additional work for someone (I am happy to volunteer) on the order of a few hours. Writing tests would be more work again but arguably it should be tested as part of dLux anyway.

Additional notes:

@LouisDesdoigts has discussed making a much more general package for some time. I believe that dLux should only deal with differentiable, physical optics. I believe that @LouisDesdoigts idea, was based of a scipy which was only very cursorily ported to XLA by the JAX team. dLux/utils would be experiencing a similar fate with many sub-modules such as statics, polynomials ect. It makes a lot more sense to use a procedural or functional paradigm in the implementation of a package with this goal and structure.

As a final note, a general package like this might stir more public interest as things like factorial not been in JAX have been googled before.

Please add to this discussion.

Jordan