Default BYVAL or BYREF Parameter Passing?
As the weight of evidence presented in this thread leans towards a consistent ByRef default, v1ctors objection must be based on something missing from the discussion. Now it is not too late to argue the case for no change. Does anyone have any ideas as to what the reason is?
My guess is that it has to do with passing pointers as arguments ByVal. Pointers are simple numbers so now in FB0.17 they are passed ByVal. The last thing you would want to do is pass them ByRef. Those who, now and in the future, write FB in the style of C, or who interface to existing C code may be advantaged by relying on the ByVal default for passing pointers. Could this be the case?
My guess is that it has to do with passing pointers as arguments ByVal. Pointers are simple numbers so now in FB0.17 they are passed ByVal. The last thing you would want to do is pass them ByRef. Those who, now and in the future, write FB in the style of C, or who interface to existing C code may be advantaged by relying on the ByVal default for passing pointers. Could this be the case?
I disagree, the weight of evidence leaned on byval until they deleted the poll. Yeah I voted for byval but who cares? They thought the poll was rigged. I think no amount of argument would change their mind on this.Richard wrote:As the weight of evidence presented in this thread leans towards a consistent ByRef default, v1ctors objection must be based on something missing from the discussion. Now it is not too late to argue the case for no change. Does anyone have any ideas as to what the reason is?
Well the poll did look weird. It isn't a foregone conclusion that it was rigged, but there was just... oddities.
Anyways, byval certainly has its place, and if you look at a random API I've created in the last months, byval is on about 90% of parameters. Again, my view on byref default has nothing to do with how much I'll have to type, nor personal preference.
I guess maybe that's the reasoning v1ctor used, since most args are byval, why not make it the default? But so you're clear, v1c doesn't say "leave it as it is", he's with the original suggestion that only strings/UDTs be passed by reference, all else by value...
btw, sometimes you will want to pass a pointer byref ;) It's rare but it has its uses.
Anyways, byval certainly has its place, and if you look at a random API I've created in the last months, byval is on about 90% of parameters. Again, my view on byref default has nothing to do with how much I'll have to type, nor personal preference.
I guess maybe that's the reasoning v1ctor used, since most args are byval, why not make it the default? But so you're clear, v1c doesn't say "leave it as it is", he's with the original suggestion that only strings/UDTs be passed by reference, all else by value...
btw, sometimes you will want to pass a pointer byref ;) It's rare but it has its uses.
I don't think the poll was rigged, but something was wrong with it. Just after I created the poll I deleted one item and added another and I think I screwed it up. I had a hard time believing as many people choose "don't care" as BYVAL. Besides, it's probably good to have the discussion first and a poll afterwards.
I could add the poll again, but maybe with options that are more suitable to what has been discussed so far, for example:
1) Default all BYREF ( except function returns ).
2) Default all BYVAL ( except arrays, and implicit THIS ).
3) Mixed default: all BYVAL except Strings, UDTs and arrays.
4) Don't care ( 1 to 3 ), so long as it is documented.
5) No default. Explicit BYVAL/BYREF only.
I might change my mind, there's no denying that there are lots of C++/Java/PHP programmers.: http://www.tiobe.com/tpci.htm But I look on the message boards for various other languages and there seems to be never ending questions from users about what references are and how to use them. If BYVAL is the "right" thing to learn first, why do users have so much trouble learning to work with references after. I don't remember having this problem learning basic. Learning BYREF (although I didn't know it) first, being careful not to modify parameters, then adding the BYVAL copy behaviour on top later. Maybe in the end, it doesn't matter, same lessons learned, just a different path.
I could add the poll again, but maybe with options that are more suitable to what has been discussed so far, for example:
1) Default all BYREF ( except function returns ).
2) Default all BYVAL ( except arrays, and implicit THIS ).
3) Mixed default: all BYVAL except Strings, UDTs and arrays.
4) Don't care ( 1 to 3 ), so long as it is documented.
5) No default. Explicit BYVAL/BYREF only.
I might change my mind, there's no denying that there are lots of C++/Java/PHP programmers.: http://www.tiobe.com/tpci.htm But I look on the message boards for various other languages and there seems to be never ending questions from users about what references are and how to use them. If BYVAL is the "right" thing to learn first, why do users have so much trouble learning to work with references after. I don't remember having this problem learning basic. Learning BYREF (although I didn't know it) first, being careful not to modify parameters, then adding the BYVAL copy behaviour on top later. Maybe in the end, it doesn't matter, same lessons learned, just a different path.
The only ways to change a poll would be: modifying it directly in the forum's DB (and i'm the only one with access to that and of course i would never do a stupid thing like that - not even to "defend" my choice :P); taking over other people's accounts (phpbb, we never know..); or creating bogus users.
By reference params don't make much sense in object oriented languages, and -lang fb in future should support OO fully - but don't be afraid, -lang fb will *always* support procedural coding too.
Java doesn't have support for by reference params for primitive types for a reason, it doesn't make sense to return results in params when you can access the data members directly or through getters (yeah, FB doesn't compare to Java, i know we allow globals and so one, but we also have properties that make getters even more simple to use).
In mathematical terms, a function should only return a result and never modify any params. If it has to return more than one result, then it's bad designed - take getXY() for example, while you could say "But, hey! What if it is too costly to access some data source twice??", then it should maintain some state in the object instance (OO again) or return a tuple (Type pos : as integer x,y etc). But as i said, the FB sources are filled with that too, typing a BYREF more when you really need to doesn't cost much even to beginners, IMO.
Byref params will also make gcc go nuts trying to deal with data aliasing when optimizing the intermediate code - when we start to emit C code too or using the gcc backend directly.
So, Richard, if you have any better reasons than those listed above, don't be afraid to share them (unless i missed something!), thanks
By reference params don't make much sense in object oriented languages, and -lang fb in future should support OO fully - but don't be afraid, -lang fb will *always* support procedural coding too.
Java doesn't have support for by reference params for primitive types for a reason, it doesn't make sense to return results in params when you can access the data members directly or through getters (yeah, FB doesn't compare to Java, i know we allow globals and so one, but we also have properties that make getters even more simple to use).
In mathematical terms, a function should only return a result and never modify any params. If it has to return more than one result, then it's bad designed - take getXY() for example, while you could say "But, hey! What if it is too costly to access some data source twice??", then it should maintain some state in the object instance (OO again) or return a tuple (Type pos : as integer x,y etc). But as i said, the FB sources are filled with that too, typing a BYREF more when you really need to doesn't cost much even to beginners, IMO.
Byref params will also make gcc go nuts trying to deal with data aliasing when optimizing the intermediate code - when we start to emit C code too or using the gcc backend directly.
So, Richard, if you have any better reasons than those listed above, don't be afraid to share them (unless i missed something!), thanks
I think the learning experiences of most or all of the people posting opinions here are not representative of the experiences that the typical beginner will have. Most people are not intellectually suited for programming, and I doubt that anyone who is has any automatic understanding of how it all looks to anyone who is not. I’m assuming that the people who originally made the decision to use ByRef as the default had sufficient experience with beginners to know what would work best. But it also occurs to me that beginners who would have significant problems with any of the possibilities being considered here, probably don’t have a future in programming, so what would be the value in catering to them.
Well, maybe we should have another poll (Jeff, your template there looks good to me), because honestly I don't know which way to go with this anymore, good points have been made on both sides and I'm not going to be stubborn with my preferences :) These decisions affect everyone who uses the language, so it's important to know how everyone feels.
I'm glad we could talk about it. Ultimately (as Jeff said earlier) I will support any decision v1ctor makes, he started and poured insane amount of effort into the compiler, and has final say on any and all nuances, as far as I'm concerned.
I'm glad we could talk about it. Ultimately (as Jeff said earlier) I will support any decision v1ctor makes, he started and poured insane amount of effort into the compiler, and has final say on any and all nuances, as far as I'm concerned.
Another possibility occured to me:
Make a fork!
What I mean is:
1.) Copy and rename fbc to fqbc, compile it without the lang fb option. This compiler would generate qb code only, with all the byref qb had. Also this compiler is done, finito, finished - only bugfixes will be done, nothing will be added in the future.
2.) Now change the fbc code: delete every code that isn't used in lang fb (and with that all the quirks and ugly workarounds that needed to be because of qb compatibility). I assume the code will not only be much cleaner but also easier to maintain. This compiler code will be the one that uses byval (afaik except strings and arrays) and will get all the attention from the core developers.
Now who throws the first stone at me... :P
Make a fork!
What I mean is:
1.) Copy and rename fbc to fqbc, compile it without the lang fb option. This compiler would generate qb code only, with all the byref qb had. Also this compiler is done, finito, finished - only bugfixes will be done, nothing will be added in the future.
2.) Now change the fbc code: delete every code that isn't used in lang fb (and with that all the quirks and ugly workarounds that needed to be because of qb compatibility). I assume the code will not only be much cleaner but also easier to maintain. This compiler code will be the one that uses byval (afaik except strings and arrays) and will get all the attention from the core developers.
Now who throws the first stone at me... :P
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
I have to say, that I'd quite like the idea of a separate executable that will compile QB source without needing a command line switch; I often worry about the number of hurdles presented to a new user, especially one who's done a bit of QBASIC programming and brings with them certain expectations.
But if we did that simply as a solution to the byref/byval problem, it would be like saying that the FB dialect simply isn't suitable for beginners.
Therefore I think that, whether or not it's a good idea, it would be better to consider it separately - this issue is proving to be complicated enough on its own.
I suggest doing another poll, this time opening a thread, and people can state their preference by posting in the thread, with their choice at the start of the post, and any other comments if they want. It gets rid of the worries about the poll reliability. But I guess it might be a problem if people want their vote to remain anonymous...
Anyway, as have been said by others, I'll go along with whatever the community and/or v1ctor settle on.
But if we did that simply as a solution to the byref/byval problem, it would be like saying that the FB dialect simply isn't suitable for beginners.
Therefore I think that, whether or not it's a good idea, it would be better to consider it separately - this issue is proving to be complicated enough on its own.
I suggest doing another poll, this time opening a thread, and people can state their preference by posting in the thread, with their choice at the start of the post, and any other comments if they want. It gets rid of the worries about the poll reliability. But I guess it might be a problem if people want their vote to remain anonymous...
Anyway, as have been said by others, I'll go along with whatever the community and/or v1ctor settle on.
Not true, it would just say FB is not suitable for people that used to use QB, have certain expectations, and want to keep it that way. They can use the FQBC compiler ;)counting_pine wrote:But if we did that simply as a solution to the byref/byval problem, it would be like saying that the FB dialect simply isn't suitable for beginners.
Beginners that never worked with QB have different expectations.
They can use FB from the start and learn while coding, while walking through example code or reading the docs. Why should they expect that a programing language should act like QB if they never worked with QB?
If the language has to change to fit in with a better design then it must. If that means it is more complex and requires more time to learn, then we will have to ease that burden on the beginner by writing more documentation, tutorials, answering more questions in the forums, writing IDE's that help guide the user, or whatever. It is still very important that beginners try the language and want to stay with it, even if the most skill they aquire is only slightly better than not programming at all.
I don't think forking the project would be a good idea for several reasons, but please start a new thread for that discussion, thanks.
Anyway, I re-added the poll: should be good to go and sorry about the screw up with the first poll. Please feel free to add more comments if there are any, and thanks to everyone that has participated in the discussion. :)
I don't think forking the project would be a good idea for several reasons, but please start a new thread for that discussion, thanks.
Anyway, I re-added the poll: should be good to go and sorry about the screw up with the first poll. Please feel free to add more comments if there are any, and thanks to everyone that has participated in the discussion. :)
agreedcoderJeff wrote:If the language has to change to fit in with a better design then it must. If that means it is more complex and requires more time to learn, then we will have to ease that burden on the beginner by writing more documentation, tutorials, answering more questions in the forums, writing IDE's that help guide the user, or whatever. It is still very important that beginners try the language and want to stay with it, even if the most skill they aquire is only slightly better than not programming at all.
sorrycoderJeff wrote: ... forking the project ..., but please start a new thread for that discussion, thanks.
What I really wanted to know was why such a fundamental change had been made. There is no point holding another pole as v1ctor is clearly firm in the decision not to restore an across the board ByRef default. This discussion has polarised to the point where both sides have dug into defensive positions from which there can be no movement.
I never got to vote in the original pole. I thought it best to think carefully about it first, then when I went to vote, the pole had disappeared. I do agree that discussion and analysis should definitely take place before any vote.
It would have been good to explore alternative syntax options, maybe something in the position and form of Cdecl(, e.g. Byval( or Byref( to signify the over-rideable default for that declaration. There has been little discussion of alternative possibilities.
We were all beginners once. As we progressively develop our skills we lose sight of what it was like as beginners. FB has lost contact with the beginner. Should we pull up the drawbridge behind us to prevent beginners getting in the way? Maybe FA should chase all beginners away and officially rename the language FreeASIC.
Globalisation is causing the extinction of many spoken languages. FreeBASIC once had something elegant to differentiate it from other languages. It had the best of both worlds, a default to ByRef with the option ByVal. Just as we do with genetic diversity, we should have valued and celebrated that difference. The choice was between the wisdom of KISS and a messy compromise born of a committee. I’m sorry, but only plain vanilla language is now available.
Who cares? I do. It is with sadness that I mourn this loss of elegance.
I never got to vote in the original pole. I thought it best to think carefully about it first, then when I went to vote, the pole had disappeared. I do agree that discussion and analysis should definitely take place before any vote.
It would have been good to explore alternative syntax options, maybe something in the position and form of Cdecl(, e.g. Byval( or Byref( to signify the over-rideable default for that declaration. There has been little discussion of alternative possibilities.
We were all beginners once. As we progressively develop our skills we lose sight of what it was like as beginners. FB has lost contact with the beginner. Should we pull up the drawbridge behind us to prevent beginners getting in the way? Maybe FA should chase all beginners away and officially rename the language FreeASIC.
Globalisation is causing the extinction of many spoken languages. FreeBASIC once had something elegant to differentiate it from other languages. It had the best of both worlds, a default to ByRef with the option ByVal. Just as we do with genetic diversity, we should have valued and celebrated that difference. The choice was between the wisdom of KISS and a messy compromise born of a committee. I’m sorry, but only plain vanilla language is now available.
Who cares? I do. It is with sadness that I mourn this loss of elegance.
-
- Posts: 1186
- Joined: May 08, 2006 21:58
- Location: Crewe, England
... but a programming language function is not the same a mathematical function. In most cases it does a lot more than return a value, and returning a value often only indicates the success or failure of the operation - for example, I/O functions.v1ctor wrote:In mathematical terms, a function should only return a result and never modify any params. If it has to return more than one result, then it's bad designed
Suppose you have a function to scan and convert a character string to a numeric type, when there is a possibility that the string is invalid, or contains no input. The best way (IMO) is to pass the target variable BYREF and make the function return an error code:
declare char_to_int (byval source as string, byref target as integer) returns integer
if char_to_int(mystring,myint)<>0 then print "error in input"
Or do you expect me to set up a type with a "NaN" flag for every integer I may need to input, plus a load of operator overrides for the type ...
With regard to cha0s's comment that he has found himself mainly using BYVAL recently, that need not surprise us. When you think about it, the majority of the parameters to a function will be inputs; the programmer thinks: "I don't need the variable, just its value", but in point of fact it doesn't actually matter.
The terminology is being misused. In both mathematics and in programming, constants are things that do not change their value within a program. Parameters retain a particular value for this instance or run. Variables are expected to change. Arguments are the things functions and subroutines work with and on. Passing ByRef or ByVal does not map directly with the terms variable and parameter respectivly. If you pass ByVal then your local copy could vary.
Since a routine may alter the value of its arguments it is not always the case that the term parameter is applicable. We should be refering to "argument passing", not "parameter passing".
Since a routine may alter the value of its arguments it is not always the case that the term parameter is applicable. We should be refering to "argument passing", not "parameter passing".