# Assignment method semantics

**URL:** <https://www.ruby-forum.com/t/assignment-method-semantics/120667>\
**Category:** Ruby\
**Created:** [November 19, 2007, 5:16pm UTC](https://www.ruby-forum.com/t/assignment-method-semantics/120667 "2007-11-19T17:16:18Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [November 19, 2007, 5:16pm UTC](https://www.ruby-forum.com/t/assignment-method-semantics/120667/1 "2007-11-19T17:16:18Z")

</div>

Are there any guidelines for the operational semantics of assignment  
methods? It seems that because its little more than syntactic sugar,  
its pretty adhoc.

While working with Ruby in Sketchup I came across a method to assign a  
texture to a material. ie

myMaterial.texture= “filename\_of\_an\_image”

Its meant to read an image file, create a “texture” object and assign  
it.

The behaviour appears to be that if the filename doesn’t exist / can’t  
be read, the property “texture” isn’t changed. My first reaction was  
that its just wrong but on reflection, if assignment methods are  
really just regular “set” style methods dressed up, then thats exactly  
the behaviour I would expect - or at least would think reasonable.

However, if it really _is_ assignment, I’d expect myMaterial.texture  
to be nil after a reading of a non-existent filename.

Thoughts?

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [November 19, 2007, 5:41pm UTC](https://www.ruby-forum.com/t/assignment-method-semantics/120667/2 "2007-11-19T17:41:34Z")

</div>

removed\_email\_address@domain.invalid wrote:

> it.  
> Thoughts?  
> Yup, it’s just setter sugar. The method Material#texture= can do  
> _anything_. Whether it’s a good idea to leave the property unchanged on  
> failure, I don’t know. Neither way is guaranteed to be safe.

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [November 19, 2007, 6:50pm UTC](https://www.ruby-forum.com/t/assignment-method-semantics/120667/3 "2007-11-19T18:50:47Z")

</div>

2007/11/19, removed\_email\_address@domain.invalid [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> it.  
> Thoughts?  
> IMHO the questionable part is that a setter can actually fail because  
> it does _complex things_ (I understood from your posting that the  
> whole file reading stuff is done _inside_ the assignment method).  
> Maybe not a setter should be used here but an ordinary method. Of  
> course setters can fail as well, especially if the value passed does  
> not meet criteria imposed by the class (e.g. a numeric value is  
> negative where only positive values are allowed). In those case I’d  
> expect an exception and that the state does not change (as opposed to  
> set to nil).

Generally if a method that should change the state of my object fails  
I expect that object’s state to be left untouched (at least with  
regard to the part of the state that was about to be modified).  
That’s more like transactional behavior. Setting to nil in case of  
failure is a bad idea IMHO.

Kind regards

robert