VAR as a topic
-
- Posts: 606
- Joined: Nov 28, 2012 1:27
- Location: CA, USA moving to WA, USA
- Contact:
VAR as a topic
Perhaps a doc could be written that would show when VAR **should** ever be used in a program?
It has its place:
Simplicity in a small program.
Arbitrary variable assignment in more complex programs.
Also, could we **never, ever** use VAR in some other keyword example? It adds unnecessary uncertainty and confusion for a beginner.
david
It has its place:
Simplicity in a small program.
Arbitrary variable assignment in more complex programs.
Also, could we **never, ever** use VAR in some other keyword example? It adds unnecessary uncertainty and confusion for a beginner.
david
Re: VAR as a topic
I think the trade-off with VAR versus DIM is strict typing for convenience. If explicit and strict typing is your thing, then probably never.speedfixer wrote:when VAR **should** ever be used in a program?
I like your approach; just because it can be used doesn't mean it should be, but it has its uses.
Maybe for a kind of best practice if VAR is used, then it's implied type should be obvious - or at least local so don't have to look too far to figure out its type.
VAR has some symmetry with CONST:
In either case, if the symbol is going to be used globally, a better choice of name would help make it obvious what kind of value it should hold.
Code: Select all
const i = 196883ull
const s = "hello"
var vi = 196883ull
var vs = "hello"
Code: Select all
scope
'' swap a and b
var tmp = a
b = a
a = tmp
end scope
Some made up thingy:
Code: Select all
Sub FrobnicateGizmos( byref g1 as string, byref g2 as string )
var a = getGizmo( g1 )
var b = getGizmo( g2 )
prepareGizmo( a )
prepareGizmo( b )
Frobnicate( a, b )
End Sub
For me, if VAR is used, then there must be well named initializers and variables to go along with it.
Re: VAR as a topic
Me who likes strongly typed languages, I rarely use the keyword 'VAR' except where precisely the variables passed are not typed (and can thus be of different types according to the call) as for example inside the body (or for processing the result) of some macros.
-
- Posts: 606
- Joined: Nov 28, 2012 1:27
- Location: CA, USA moving to WA, USA
- Contact:
Re: VAR as a topic
So it seems we each prefer more strongly typed variables.
Then, for the sake of simplicity and clarity:
anyone, everyone: if you review any example in the docs could we please remove all VAR uses except in the VAR keyword page and a select few others?
david
Then, for the sake of simplicity and clarity:
anyone, everyone: if you review any example in the docs could we please remove all VAR uses except in the VAR keyword page and a select few others?
david
Re: VAR as a topic
Except the 'VAR' documentation page, there are 10 other documentation pages using the 'VAR' keyword in their 'Example' paragraph:
- - __FB_ARG_LEFTOF__
- __FB_ARG_RIGHTOF__
- __FB_UNQUOTE__
- BYREF (variables)
- Cairo
- Operator PROCPTR (Procedure pointer)
- Operator Step (Iteration)
- Properties
- STRING
- THREADDETACH
Re: VAR as a topic
var can be very valuable (like auto in C++)
I always use it if I can.
Code is just as easy to read, speed unchanged.
It is a personal choice for coders after all.
Why obliterate it?
Code: Select all
#macro engine
var i=begin,j=finish
var x =array(((I+J)\2))
While I <= J
While array(I) < X :I+=1:Wend
While array(J) > X :J-=1:Wend
If I<=J Then Swap array(I),array(J): I+=1:J-=1
Wend
If J >begin Then quicksort(array(),begin,J)
If I <Finish Then quicksort(array(),I,Finish)
#endmacro
Sub quicksort overload(array() As double,begin As Long,Finish As long)
engine
end sub
Sub quicksort(array() As string,begin As Long,Finish As long)
engine
end sub
dim as double d(...)={3,7.4,-6,0}
dim as string s(...)={"good","bad","ugly","Clint"}
quicksort(d(),lbound(d),ubound(d))
quicksort(s(),lbound(s),ubound(s))
for n as long=lbound(d)to ubound(d)
print d(n),s(n)
next
sleep
Code is just as easy to read, speed unchanged.
It is a personal choice for coders after all.
Why obliterate it?
Re: VAR as a topic
No one ever said, that this is for Beginners (a weak argument anyhow).
VAR can easily be forced to be of a wanted datatype (by those that know "the basics of datatypes").
There are in fact three prerequisites to success: where:
s = String, cnt = ULongInt, x = UInteger, y = Integer (signed) ...
VAR can easily be forced to be of a wanted datatype (by those that know "the basics of datatypes").
There are in fact three prerequisites to success:
- 1) knowledge of all Standard Datatypes (of FreeBASIC)
2) coercion & conversion
3) literal sufixes
Code: Select all
Var s = "", cnt = 0ull, x = 0u, y = 0
s = String, cnt = ULongInt, x = UInteger, y = Integer (signed) ...
Re: VAR as a topic
I know VAR can be convenient but I hate it's use, I like to know the type a variable has by looking at the definition and VAR can seriously obfuscate the code in my opinion.
Re: VAR as a topic
I second that. I also use VAR whenever possible. It doesn't only help when declaring local variables in a short and readable form likedodicat wrote:I always use it if I can.
Code is just as easy to read, speed unchanged.
It is a personal choice for coders after all.
Why obliterate it?
Code: Select all
VAR a = "", b = 1uL, c = .5
Code: Select all
#PRINT TYPEOF(b)
Instead of removing that keyword from example code, I'd encourage beginners to use it.
Re: VAR as a topic
This is why in the list of 10 pages that I provided above, the example of the Cairo page is one of the pages where the use of 'VAR' is justified:TJF wrote:The real advantage is when you deal with big libraries and pointer types. You need not take care of each character in the type name, just let the compiler do the work. I hate to use DIM to create a structure for a return value.
Code: Select all
Var surface = cairo_image_surface_create_for_data(ScreenPtr(), CAIRO_FORMAT_ARGB32, SCREEN_W, SCREEN_H, SCREEN_W * SizeOf(ULong))
Var c = cairo_create(surface)
Re: VAR as a topic
I agree with fxm, I wouldn't mind VAR at all if there were an IDE that would show the type on mouse-over, having to #PRINT TYPEOF(b) is a pain
-
- Posts: 606
- Joined: Nov 28, 2012 1:27
- Location: CA, USA moving to WA, USA
- Contact:
Re: VAR as a topic
In truth, I thought I saw more than these few.
I'm not suggesting that VAR does not have value, or that it should be warned away from as bad practice. Everyone has their own style.
VAR in ProPgProperties at least will be contained and not cause problems outside of the function it is used in. But, no clue why it is used and departs from declarations used in the code presented above.
VAR in KeyPgString just doesn't make sense. Why show a keyword then show how to avoid using it?
Without further explanation, the most direct conclusion would be that VAR is a synonym for STRING.
Silly conclusion for us, but maybe not for a complete noob. It should either be changed, or this new keyword needs to be added to the links below.
VAR in KeyPgOpStep implies that any automatic type assignment will have no bearing on operation results. That just isn't true.
VAR in KeyPgThreadDetach suggests again that the resulting type is not important. Immediate use here works, but if you have thread management routines that need stored thread pointers, that can lead to some very bad code across different platforms. Consistency would suggest that the other thread functions should use VAR also.
re: TJF: "The real advantage is when you deal with big libraries and pointer types."
I feel just the opposite. Much more important to remove any ambiguity in larger code sets. In order to use that function in Cairo in some other manner, a lot of research into the Cairo lib needs to happen. Just my opinion.
Nice to see these other opinions on its use.
This isn't that critical. I just think it should ALWAYS be as clear and simple as possible for any beginner using the docs.
david
I'm not suggesting that VAR does not have value, or that it should be warned away from as bad practice. Everyone has their own style.
VAR in ProPgProperties at least will be contained and not cause problems outside of the function it is used in. But, no clue why it is used and departs from declarations used in the code presented above.
VAR in KeyPgString just doesn't make sense. Why show a keyword then show how to avoid using it?
Without further explanation, the most direct conclusion would be that VAR is a synonym for STRING.
Silly conclusion for us, but maybe not for a complete noob. It should either be changed, or this new keyword needs to be added to the links below.
VAR in KeyPgOpStep implies that any automatic type assignment will have no bearing on operation results. That just isn't true.
VAR in KeyPgThreadDetach suggests again that the resulting type is not important. Immediate use here works, but if you have thread management routines that need stored thread pointers, that can lead to some very bad code across different platforms. Consistency would suggest that the other thread functions should use VAR also.
re: TJF: "The real advantage is when you deal with big libraries and pointer types."
I feel just the opposite. Much more important to remove any ambiguity in larger code sets. In order to use that function in Cairo in some other manner, a lot of research into the Cairo lib needs to happen. Just my opinion.
Nice to see these other opinions on its use.
This isn't that critical. I just think it should ALWAYS be as clear and simple as possible for any beginner using the docs.
david
Re: VAR as a topic
Var [Shared] variablename = expression
is equivalent to:
Dim [Shared] As TypeOf((expression)) = expression
which implies that 'VAR' cannot replace 'STATIC', which means that a static variable in a compound instruction block or in a procedure scope cannot be defined with 'VAR'.
[edit]
See the following post from dodicat.
Re: VAR as a topic
@speedfixer,
This is also why I proposed to replace 'VAR' by 'DIM' for these 4 cases: As for Cairo, I think the 2 types (for 'VAR') are respectively:
This is also why I proposed to replace 'VAR' by 'DIM' for these 4 cases: As for Cairo, I think the 2 types (for 'VAR') are respectively:
- cairo_surface_t ptr
cairo_t ptr
Re: VAR as a topic
You can use var for a static variable.
I have used this in cairo
Var surface = cairo_image_surface_create_for_data(Screenptr(), CAIRO_FORMAT_ARGB32,xres,yres,xres*4)
Which was quite handy at the time.
Also, likewise, var is quite handy in some winapi code where the compiler works out what exactly it is, you can always of course find out what it is yourself and use dim instead.
Code: Select all
function f()byref as zstring ptr
static var g=strptr(" Hello")
return g
end function
print *f
for n as long=1 to 10
var x=str(n)
f()=strptr(x)
print *f
next
var byref z=f
z=strptr(" Goodbye, press any key to end . . .")
print *f
sleep
Var surface = cairo_image_surface_create_for_data(Screenptr(), CAIRO_FORMAT_ARGB32,xres,yres,xres*4)
Which was quite handy at the time.
Also, likewise, var is quite handy in some winapi code where the compiler works out what exactly it is, you can always of course find out what it is yourself and use dim instead.