SFML community forums

General => Feature requests => Topic started by: Jesper Juhl on February 11, 2014, 12:14:59 am

Title: set functions should return reference to self
Post by: Jesper Juhl on February 11, 2014, 12:14:59 am

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.

Title: Re: set functions should return reference to self
Post by: eigenbom on February 11, 2014, 12:32:42 am

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.

Title: Re: set functions should return reference to self
Post by: Jesper Juhl on February 11, 2014, 12:41:34 am

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.

Title: Re: set functions should return reference to self
Post by: Nexus on February 11, 2014, 12:57:13 am

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 ;)

Title: Re: set functions should return reference to self
Post by: Jesper Juhl on February 11, 2014, 01:00:16 am

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

Title: Re: set functions should return reference to self
Post by: Tank on February 11, 2014, 07:40:47 am

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.

Title: Re: set functions should return reference to self
Post by: pdinklag on February 24, 2014, 01:24:06 pm

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.

Title: Re: set functions should return reference to self
Post by: MorleyDev on February 25, 2014, 12:26:22 am

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.

Title: Re: set functions should return reference to self
Post by: eigenbom on February 25, 2014, 06:57:07 am

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

Code: [Select]

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