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
In PR #7039 a discussion started about exporting to python free functions as part of new user specified namespaces.
After discussion in @KratosMultiphysics/technical-committee we reached the consensus to keep the current usage, that is, to have static methods exported as members of classes and not as free functions within specific namespaces
The rationale of this is
classes allow private members and methods while namespaces don't
classes can be templated
KRATOS_API has to be added only once
On the other hand the @KratosMultiphysics/technical-committee agrees in principle about adding a limited number of namespaces, on the line of "internal", "utilities", "processes" in order to better organize the code and to benefit of better code suggestions by modern editors. However to avoid the proliferation of such namespaces we require that this is agreed to by the @KratosMultiphysics/technical-committee
We shall also observe however that adding such namespaces for existing classes, for example for processes and utilities, would imply a very large effort, so we would need to consider this carefully before actually doing it.
This message should be ported to our coding style guides.
The text was updated successfully, but these errors were encountered:
Description
In PR #7039 a discussion started about exporting to python free functions as part of new user specified namespaces.
After discussion in @KratosMultiphysics/technical-committee we reached the consensus to keep the current usage, that is, to have static methods exported as members of classes and not as free functions within specific namespaces
The rationale of this is
On the other hand the @KratosMultiphysics/technical-committee agrees in principle about adding a limited number of namespaces, on the line of "internal", "utilities", "processes" in order to better organize the code and to benefit of better code suggestions by modern editors. However to avoid the proliferation of such namespaces we require that this is agreed to by the @KratosMultiphysics/technical-committee
We shall also observe however that adding such namespaces for existing classes, for example for processes and utilities, would imply a very large effort, so we would need to consider this carefully before actually doing it.
This message should be ported to our coding style guides.
The text was updated successfully, but these errors were encountered: