You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This may not be considered a "bug", but it's a design pattern that I think is undesirable from an API standpoint.
There are some places in this package in which a function that "looks like" a constructor, in that it follows the Julia convention of having a camel-case and having the same name as an existing type, returns an object of a completely different type. The examples I have run into are in constructors for various types of ODEProblem which can be found here. There may be other examples of this, but I haven't gone through the package exhaustively.
While obviously Julia does not strictly enforce this convention for constructors, I would argue that it should and, at the very least, the results can be very confusing. For example, I discovered this issue when code I wrote was resulting in method errors because I had written methods for DynamicalODEProblem rather than ODEProblem because I was calling the function DynamicalODEProblem to create the object and I could see that this was indeed a real type (I would argue that if DynamicalODEProblem did not exist this function should be renamed so as not to have the misleading camel-case).
The text was updated successfully, but these errors were encountered:
Yeah, it's an odd design decision I made back in 2016. I don't know if I agree with it now, but it would be breaking to move away from it unless we make a DynamicalODEProblem type, which is not off the table.
This may not be considered a "bug", but it's a design pattern that I think is undesirable from an API standpoint.
There are some places in this package in which a function that "looks like" a constructor, in that it follows the Julia convention of having a camel-case and having the same name as an existing type, returns an object of a completely different type. The examples I have run into are in constructors for various types of
ODEProblem
which can be found here. There may be other examples of this, but I haven't gone through the package exhaustively.While obviously Julia does not strictly enforce this convention for constructors, I would argue that it should and, at the very least, the results can be very confusing. For example, I discovered this issue when code I wrote was resulting in method errors because I had written methods for
DynamicalODEProblem
rather thanODEProblem
because I was calling the functionDynamicalODEProblem
to create the object and I could see that this was indeed a real type (I would argue that ifDynamicalODEProblem
did not exist this function should be renamed so as not to have the misleading camel-case).The text was updated successfully, but these errors were encountered: