set functions should return reference to self

[Jesper Juhl]

It would be nice if "setters" like for example sf::sprite::setPosition() returned a reference to themselves rather than void.

sf::sprite& sf::sprite::setPosition(...) {
  ...
  return *this;
}

This would allow easy chaining of multiple setFoo calls on the same object like:
  Foo f;
  f.setBar().setBaz();
Etc..

Since setters currently return void we know that no one is storing, or otherwise relying on, their return value, so changing the return value shouldn't cause any problems for legacy code. It would just provide new functionality that old code could blissfully keep ignoring but that new code could exploit.

I'd be happy to make the code change and submit a pull request if this would be liked/wanted/acceptable.

[eigenbom]

Method chaining is useful to model named parameters when constructing complex objects, but I don't think it's beneficial otherwise. Especially when it comes to debugging, because you have multiple function calls on a single line. It is a cool trick, but not something I think needs to be in a Simple library like SFML. In the end you're only saving a few key strokes.

[Jesper Juhl]

But what's the harm in making it possible?
If you don't want to use it, then don't and no harm done.
But if you want to use it it would be nice to have the option.

As I see it, it gives users options and doesn't harm anyone who don't want to take advantage of it.

[Nexus]

It has already been discussed and can't be done because sf::Transformable& would be returned, not a reference to the derived class.

Furthermore, features are implemented when they are useful for many people, not when they do no harm

[Jesper Juhl]

Fair enough, Nexus. It was just a proposal (born of my own annoyance). It's not important and I can still enjoy SFML without

[Tank]

I would vote strongly against that. If a function logically does not return a value, then it should be kept like that. Doing nasty tricks to save a \n and ; is not worth it, in my opinion.

[pdinklag]

Agreed, function chaining is pretty popular in Java, and the result in an inconveivable mess.
Granted it's a matter of taste, it still doesn't make any sense for something that is simply supposed to set a member value to return anything.

[MorleyDev]

Function chaining is great when used for a Fluent syntax. For example, the following code is highly readable and functional:

sqlFactory.select("*")
          .from("some_table")
          .where("somevalue = 12")
          .execute();
 

In C++, libraries like cpplinq achieve similar results with syntax such as:

cpplinq::from(some_collection)
    >> cpplinq::where([](auto data) { return data.value == expected; })
    >> cpplinq::select([](auto data) { return data.other_value == expected; })
    >> cpplinq::to_vector();
 

Such syntax is both readable and greatly extensible. In these situation the chaining is inherent to the design pattern and, increases readability. It's intuitive and useful. However, as others have pointed out setters do not logically return a value so should not, it's simply not a returned value one would intuitively expect.

[eigenbom]

Dart's got something similar to function chaining called method cascading.. 

Code: [Select]

some_variable
    ..background = 'red'
    ..border = '2px solid black'   
    ..some_function_call()
    ..etc = whatever