The theory afaik is that Objects really should be references, but they aren't. So there's the inconsistency. We pass objects by reference and scalars by value.
It's a relatively easy explanation to give. I would have gone for all byref too. v1ctor and coderJeff agree with my decision, as do a fair amount of the polls. We didn't take the most popular decision, but I think our decision is far from perilous to FB's future.
Fb's beta, if you're ever unsatisfied, we'll give you your money back, and who knows... maybe down the road it'll change again. Just being realistic.
Could you name some of the 'cons' beside just inconsistency? If you want a strict language with very few rules/keywords, BASIC is not a good choice...
Default BYVAL or BYREF Parameter Passing?
-
jevans4949
- Posts: 1186
- Joined: May 08, 2006 21:58
- Location: Crewe, England
-
Sisophon2001
- Posts: 1706
- Joined: May 27, 2005 6:34
- Location: Cambodia, Thailand, Lao, Ireland etc.
- Contact:
They split the byval vote by giving us two choices (which I had difficulty choosing between), so we need proportional representation :).jevans4949 wrote:I hate to be a moaner, so I held back to let someone else have a say.cha0s wrote:v1ctor and coderJeff agree with my decision, as do a fair amount of the polls.
The fact is, this was the THIRD most popular option. Having asked peoples' opinion, you ignored it!
Seriously, they made their choice, so just leave it. Vote again next year.
Garvan
My thought is now that should be all BYVAL for anything that's more than one length (basic data types except strings) and BYREF otherwise. (arrays, strings)
The UDT is where the problem comes in to this line of thought. UDTs can be mixes of stuff, but sometimes they are just two integers, say .apple and .orange. A bit confusing but I would agree to put it as BYREF.
The UDT is where the problem comes in to this line of thought. UDTs can be mixes of stuff, but sometimes they are just two integers, say .apple and .orange. A bit confusing but I would agree to put it as BYREF.
This is just some observations since the change..
It could be that i'm just used to having a blanket default, in all of the languages I use, but this has been rather difficult for me to work with. Before I could just skim code and rely on the fact that if nothing was specified it was BYVAL, now I have to pay attention to types as well. And this is made even more difficult with type aliases - who knows if it's a scalar type or not without hunting for the alias. IMO, the code looks very messy, so much so that I've begun specifying BYVAL for everything not BYREF just for readability. That doesn't really help though, in a large source BYVAL and BYREF tend to look very similar.
Afaik, the theory is that not all objects are designed to be passed by reference. We pass objects both by reference and by value, depending on the design - no inconsistency there. No, I don't think I'd like it if FreeBASIC was uber strict and had few keywords, but this change just doesn't make sense to me, particularly in a BASIC context, which to me means an intuitive, easy-to-learn language.
It could be that i'm just used to having a blanket default, in all of the languages I use, but this has been rather difficult for me to work with. Before I could just skim code and rely on the fact that if nothing was specified it was BYVAL, now I have to pay attention to types as well. And this is made even more difficult with type aliases - who knows if it's a scalar type or not without hunting for the alias. IMO, the code looks very messy, so much so that I've begun specifying BYVAL for everything not BYREF just for readability. That doesn't really help though, in a large source BYVAL and BYREF tend to look very similar.
Afaik, the theory is that not all objects are designed to be passed by reference. We pass objects both by reference and by value, depending on the design - no inconsistency there. No, I don't think I'd like it if FreeBASIC was uber strict and had few keywords, but this change just doesn't make sense to me, particularly in a BASIC context, which to me means an intuitive, easy-to-learn language.
-
Basic Coder
- Posts: 180
- Joined: Aug 02, 2006 23:37
- Location: Australia
A real beginner understands nothing and I think could learn to thinkrelsoft wrote:Beginners don't understand "objects". I guess I still don't.
Well, I guess you probably understood what objects are when you started coding. That's probably the difference between us users and you developers.
in terms of objects as in Java easier than it has been for me who
learned to program in the old BASIC with GOSUBs !!!
For me the first version of FreeBasic was great as I could program
the way I always have, badly :)
I haven't given a view or a vote on how to pass things, my only
concern is whatever choice is made I know what it is.
No party in this debate is right, all parties have quite legitimate claims to their preference and diverse programming styles. Remember this discussion is only about a default, it is not compulsory.
ByRef is the equivalent of implicitly passing a pointer. QB avoided explicit pointers and therefore passed all ByRef. A programmer who comes to FreeBASIC from a language like QB or Fortran that implicitly passed pointers will write FreeBASIC in that style, they will pass ByRef and avoid explicitly declared pointers. Interfacing to assembly code favours passing addresses on the stack, which is implicitly ByRef.
{
A programmer who comes to FreeBASIC, from a language like Pascal or C that requires the declaration of pointers, will tend to write FreeBASIC in a C style, they will pass ByVal and use explicitly declared pointers. Interfacing FreeBASIC to C required the ability to declare pointers and pass ByVal. Likewise writing the FreeBASIC compiler will favour the C style because of the C development tools and rtl. Compiler developers will therefore be biased to favour a C style while beginners might favour the original QB style.
}
All ByRef was used in QB because it was simple, consistent and worked without explicitly declared pointers. A KISS principle solution now requires we either default ByRef like QB or we demand explicit. It logically follows that if there is a simple default, it would be ByRef because explicit is not a default, it is a demand.
Just because you believe you understand today’s rules for determining the defaults, it does not mean you can rely on them. We have been warned that the rules can be expected to mutate over time. Anyone who does not now always explicitly specify either ByRef or ByVal is knowingly writing potentially unreliable code. We have spawned a chimera.
There can be no pragmatic solution to this continuing problem along the present datatype dependent hybrid line. This futile tug of war will continue until one clear KISS solution is accepted and implemented.
ByRef is the equivalent of implicitly passing a pointer. QB avoided explicit pointers and therefore passed all ByRef. A programmer who comes to FreeBASIC from a language like QB or Fortran that implicitly passed pointers will write FreeBASIC in that style, they will pass ByRef and avoid explicitly declared pointers. Interfacing to assembly code favours passing addresses on the stack, which is implicitly ByRef.
{
A programmer who comes to FreeBASIC, from a language like Pascal or C that requires the declaration of pointers, will tend to write FreeBASIC in a C style, they will pass ByVal and use explicitly declared pointers. Interfacing FreeBASIC to C required the ability to declare pointers and pass ByVal. Likewise writing the FreeBASIC compiler will favour the C style because of the C development tools and rtl. Compiler developers will therefore be biased to favour a C style while beginners might favour the original QB style.
}
All ByRef was used in QB because it was simple, consistent and worked without explicitly declared pointers. A KISS principle solution now requires we either default ByRef like QB or we demand explicit. It logically follows that if there is a simple default, it would be ByRef because explicit is not a default, it is a demand.
Just because you believe you understand today’s rules for determining the defaults, it does not mean you can rely on them. We have been warned that the rules can be expected to mutate over time. Anyone who does not now always explicitly specify either ByRef or ByVal is knowingly writing potentially unreliable code. We have spawned a chimera.
There can be no pragmatic solution to this continuing problem along the present datatype dependent hybrid line. This futile tug of war will continue until one clear KISS solution is accepted and implemented.
Re: Default BYVAL or BYREF Parameter Passing?
Today I had a parameter that gave me an error and could not find the problem in FB 64 on 64-bit windows. It didn't return anything, and now I know that the default is ByVal. I Look in the help and there is nothing on this topic.To reduce memory I always prefer ByRef. But it is dangerous for data integrity. ThankscoderJeff wrote:Default BYVAL or BYREF Parameter Passing?
One issue for programmers that keeps coming up in different ways is the changed default BYVAL/BYREF paraneter passing expectation. In the 0.17-final release, the default is BYVAL for -lang fb. For those who may not know, in previous versions it was BYREF. The BYVAL/BYREF default affects how parameters are passed to procedures. With BYVAL, a copy of the variable is passed to the procedure. With BYREF a reference (adddress) is passed to the procedure.
I would like to change the default back to BYREF, because:
1) I always want to pass STRINGs BYREF.
2) I almost always want to pass UDT's BYREF.
3) The default in -lang fb is different from -lang qb and -lang deprecated which causes confusion.
4) When I copy code from other basics (like VB), I always must remember to add in the BYREF, or I have sometimes hard to find bugs.
But, I do not think OPTION BYVAL should come back with it. Any header that used it, was not easily (if at all) shareable in another project. However, a push/pop only #pragma for BYVAL could be added, such that it would only be in effect for the header/module in which it is used.
I am thinking that for anyone who made it through the first change from BYREF to BYVAL, this change won't matter, because you probably now do what I do: always specify BYVAL/BYREF.
As always, comments and questions are welcome!
-
Josep Roca
- Posts: 564
- Joined: Sep 27, 2016 18:20
- Location: Valencia, Spain
Re: Default BYVAL or BYREF Parameter Passing?
Add BYVAL or BYREF explicitily to the parameters, instead of relying on defaults, and you won't have any problem.
Re: Default BYVAL or BYREF Parameter Passing?
Look at BYVAL or BYREF documentation page:jmgbsas wrote:I Look in the help and there is nothing on this topic.
Dialect Differences:
- In the -lang fb dialect, Byval is the default parameter passing convention for all built-in types except String and user-defined Type which are passed Byref by default. The Zstring and Wstring built-in types are also passed Byref by default, but passing Byval is forbidden. Arrays are always passed Byref and the use of the specifier Byref or Byval is forbidden.
- In -lang qb and -lang fblite dialects, Byref is the default parameter passing convention.
Re: Default BYVAL or BYREF Parameter Passing?
That's easy, thumbs up!fxm wrote:In the -lang fb dialect, Byval is the default
In -lang fblite dialects, Byref is the default
Re: Default BYVAL or BYREF Parameter Passing?
Is my mistake yes and in Passing Arguments to Procedures too, I was reading with small fonts and do not see sorry Thanks..fxm wrote:Look at BYVAL or BYREF documentation page:jmgbsas wrote:I Look in the help and there is nothing on this topic.Dialect Differences:
- In the -lang fb dialect, Byval is the default parameter passing convention for all built-in types except String and user-defined Type which are passed Byref by default. The Zstring and Wstring built-in types are also passed Byref by default, but passing Byval is forbidden. Arrays are always passed Byref and the use of the specifier Byref or Byval is forbidden.
- In -lang qb and -lang fblite dialects, Byref is the default parameter passing convention.
Re: Default BYVAL or BYREF Parameter Passing?
Sounds fine. Maybe emit a warning when a value type exceeds a certain size ?fxm wrote:Look at BYVAL or BYREF documentation page:jmgbsas wrote:I Look in the help and there is nothing on this topic.Dialect Differences:
- In the -lang fb dialect, Byval is the default parameter passing convention for all built-in types except String and user-defined Type which are passed Byref by default. The Zstring and Wstring built-in types are also passed Byref by default, but passing Byval is forbidden. Arrays are always passed Byref and the use of the specifier Byref or Byval is forbidden.
- In -lang qb and -lang fblite dialects, Byref is the default parameter passing convention.
Note that ABI requirements also influence byval/byref.