Re: Discuss changing the behaviour of append()
- Posted by mindwalker Jun 10, 2014
- 4312 views
I don't have any horses in this race, but that has never stopped me from cheering.
Basically Derek states he has a need in some code he is writing to append an object to another object and that the append function currently is designed as a sequence operator requiring a sequence as the first parameter (from "4.1.4.9 Other Operations on Sequences" in the manual).
Currently this is illegal ...
sequence x x = append(1,2)
We get the error message ...
first argument of append must be a sequence
Then he states.
... I ... had to code an explicit test to get around it. This is 'ugly' and makes the code a bit slower and larger.
function F(object A, object B) sequence x if atom(A) then x = append({A}, B) else x = append(A, B) end if return x end function
His suggestion is to replace the append sequence function with an append object function which is essentially the F function that he discribed as "This is 'ugly' and makes the code a bit slower and larger". This of course saddles all OpenEuphoria programmers with this 'ugly', slower, larger functionality leaving his code no better off (except the code is hidden in the language now).
When I don't have any horses in a race I sometimes switch which horse I am cheering for (I cheer the underdog if there appears to be any chance).
In my opinion, one of the strengths of the Euphoria language is not having overloaded functions or multiple functions that all do the same basic thing but take different data types as parameters.
Viewed from that perspective, Derek's function becomes the appropriate append function which will work for all data types.
But the question is will this change break someone's program. Could someone have depended on the append function to detect when the first parameter is an atom and to stop the program in that case.
I guess that depends on when/how the error is currently detected. Can one call append(obj1, obj2) and when obj1 has a sequence assigned to it the function works and when an atom is assigned it fails? Or does the processor realize (say in a first pass) that obj1 is defined as an object variable not a sequence and throws the error irregardless of what is ultimately assigned to the variable?
In the second scenario changing horses will have no ill affects since the error detection would have resulted in the programmer changing obj1 into a sequence variable in order to get the program to run.
But in the first scenario it is possible someone's code will be affected if they choose to migrate their program to using the newest version of OpenEuphoria. When a large program written several years ago gets update to a newer version of a language, the initial assumptions and dependancies aren't always remembered (may not even be the same programmer). So this makes this kind of a change possibly serious. If some programmer was foolish enough to depend on the append function to detect corrupt data, the down stream data could become further corrupted when the program starts "working" instead of aborting.
Of course other languages handle this by producing thousands of pages of release notes with a one liner buried somewhere in the middle that reads something like: The append function has been modified (see manual for details).