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?

adambillyard@googlemail.com wrote:
> 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?
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.

--
Alex

2007/11/19, adambillyard@googlemail.com <adambillyard@googlemail.com>:
> 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?

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

--
use.inject do |as, often| as.you_can - without end