side-effects

Is there a standard or best practice for writing javadocs for Java/JVM language methods which contain side effects? I have a void method defined, which modifies one of the method parameters, but do not know how to document the actual return value (since there is no actual return). /** * @param obj - reference object * @return obj - obj.name is changed to 'hello' //TODO figure out javadoc annotation */ void methodName(Object obj) { if (obj != null) { obj.name = "hello"; } } It just seems that there is no good way to tag the side effects on the object, since the @param and @return annotations do

C++03 Standard 1.9/6 defines observable behavior : The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions. and then and then 1.9/7 defines side effects : Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Is a side effect an observable behavior or not? How are they related to each other? No, a side effect is not

I want to model the relationship between two entities, a group and an account with JPA/Hibernate. An account can have several groups, but not vice versa, so we have a OneToMany relationship between account and group. My working colleague suggested to model the entities Account and Group like public class Account { private List<Group> groups = new ArrayList<Group>(); public Account() {} public void setGroups(List<Group> usergroups) { this.groups = groups; } @OneToMany(mappedBy = "account") public List<Group> getGroups() { return groups; } } and public class Group { private String name; private

Does functional programming have a standard construct for this logic? const passAround = (f) => (x) => { f(x); return x; }; This enables me to compose functions that have side effects and no return values, like console.log . It's not like a Task because I don't want to represent the state of the side effect. The SKI combinator calculus might interest you. Let's pretend that f is always a pure function: const S = g => f => x => g(x)(f(x)); // S combinator of SKI combinator calculus const K = x => y => x; // K combinator of SKI combinator calculus const passAround = S(K); // Yes, the passAround

As I always understood it, any change to the programs state (or anything to do with IO) is a side effect. It does not matter, whether the change occurs in a global variable or in a private field of the object the method is called on. It follows that all methods which do not return anything either do nothing at all or have a side effect. My confusion comes from one of our university's instructors (who is still a student and thus not omniscient yet;) ) telling me setters don't have side effects. runako Your instructor is mistaken. With apologies to the SO editors for not pasting the entire

When I today read the C Standard, it says about side effects Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects and the C++ Standard says Accessing an object designated by a volatile glvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects Hence because both forbid unsequenced side effects to occur on the same scalar object, C allows the following, but C++ makes it undefined behavior int a = 0; volatile int *pa =

I have a question Regarding PHP Basic Coding Standards PSR1. PSR 1 Rule 2.3 states: Rule 2.3 Side Effects A file SHOULD declare new symbols (classes, functions, constants, etc.) and cause no other side effects, or it SHOULD execute logic with side effects, but SHOULD NOT do both. The phrase "side effects" means execution of logic not directly related to declaring classes, functions, constants, etc., merely from including the file . "Side effects" include but are not limited to: generating output, explicit use of 'require' or 'include', connecting to external services, modifying ini settings,