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
The current implementation of modifiers for network objects attempts to modify it in place, emulating behaviour of C++, Java, and Python classes, and R6 classes in R. This is accomplished by gabbing the expression for the network from the calling function and then assigning to it at the end if possible. This is quite kludgey, and may produce inconsistent or unpredictable behaviour, say, when a network object is passed to a function and modified there, or when a network is produced by an expression.
This may be possible to avoid using the same approach as R6 classes: whereas R lists are copied on modification, R environments are always references and need to be copied explicitly. Thus, if a network base class is an environment, changes to it will always change it in place automatically.
The text was updated successfully, but these errors were encountered:
The current implementation of modifiers for network objects attempts to modify it in place, emulating behaviour of C++, Java, and Python classes, and
R6
classes in R. This is accomplished by gabbing the expression for the network from the calling function and then assigning to it at the end if possible. This is quite kludgey, and may produce inconsistent or unpredictable behaviour, say, when a network object is passed to a function and modified there, or when a network is produced by an expression.This may be possible to avoid using the same approach as
R6
classes: whereas Rlist
s are copied on modification, Renvironment
s are always references and need to be copied explicitly. Thus, if anetwork
base class is anenvironment
, changes to it will always change it in place automatically.The text was updated successfully, but these errors were encountered: