Page 2 of 3
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 8:50 am
by MachineCode
Regenduft wrote:I would get a step futher and allow '$' as the part of a procedure names, if it's returning a Strings! But I guess this is not going to come.
You can already do that!
Just use either "Procedure.s MyProc()" or "Procedure$ MyProc()".
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 9:02 am
by Demivec
MachineCode wrote:Regenduft wrote:I would get a step futher and allow '$' as the part of a procedure names, if it's returning a Strings! But I guess this is not going to come.
You can already do that!
Just use either "Procedure.s MyProc()" or "Procedure$ MyProc()".
Your suggestion is incorrect. The '$' doesn't become part of the name, if it did then 'Procedure$ MyProc()' would require you to use 'MyProc$()' when calling the procedure.
That was the point of my feature request to disallow specifying '$' as a type because it doesn't become part of the actual name of a variable or procedure.
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 12:38 pm
by MachineCode
Demivec wrote:Your suggestion is incorrect.
I misunderstood what was being asked. My bad.
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 12:58 pm
by NicknameFJ
Demivec wrote:
(...) it doesn't become part of the actual name of a variable (...)
Hello Demivec,
it is part of the variable name:
You can use
and it will show "Test" because This.s and This is the same variable.
But you can not use
it will show nothing (ok it shows 0, the value of the intaeger variable) because That$ and That is not the same variable.
Look here (from the german offline help file - sorry for german in the forum)
HELP FILE wrote:
Schreibweise von String-Variablen: es ist möglich, '$' als letztes Zeichen eines Variablennamens zu verwenden, um die Variable als String zu kennzeichnen. Auf diesem Weg können Sie 'a$' und 'a.s' als zwei unterschiedliche String-Variablen verwenden. Bitte beachten Sie, dass das '$' zum Variablennamen gehört und immer hinzugefügt werden muss, während das '.s' nur beim ersten Deklarieren der String-Variable benötigt wird.
NicknameFJ
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 1:14 pm
by Demivec
NicknameFJ wrote:it is part of the variable name
@NicknameFJ: This was the reason for my request.
From what I understood, using '$' as the last character of a variable name made it a string and it was required that it be included each time the variable was used (as part of the name).
The language allows for a type to be specified as '$' without the '$' being attached to a variable (or procedure) name. That just seems to be a little confusing with regard to making the syntax more consistent.
I know the simple solution is to simply not use it and I never have. It still seems strange that it would be permitted.
It seems Fred doesn't favor the idea of making any changes in this regard so I guess it will hang around as a quirky part of the language. There are other quirks still lingering as well, one of these is allowing pointers to have a native type specified instead of a structure (i.e. *ptr.w, *ptr.s, or even *ptr$
).
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 2:14 pm
by Fred
Demivec wrote:There are other quirks still lingering as well, one of these is allowing pointers to have a native type specified instead of a structure (i.e. *ptr.w, *ptr.s, or even *ptr$
).
This one will be removed in the next version.
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 2:22 pm
by Demivec
Fred wrote:Demivec wrote:There are other quirks still lingering as well, one of these is allowing pointers to have a native type specified instead of a structure (i.e. *ptr.w, *ptr.s, or even *ptr$
).
This one will be removed in the next version.
I'm glad to hear that. Thanks for the heads up.
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 7:46 pm
by skywalk
Fred wrote:Demivec wrote:There are other quirks still lingering as well, one of these is allowing pointers to have a native type specified instead of a structure (i.e. *ptr.w, *ptr.s, or even *ptr$
).
This one will be removed in the next version.
Hi Fred,
Do you mean only the *ptr.s or *p.s will be removed?
Please don't change the remaining native data type decorations, *ptr.d, *ptr.u, etc.
I have many many Prototypes that would need changing otherwise.
And these are very helpful to keep code lines short and meaningful for documentation.
Code: Select all
Prototype PtrNoInfo(*p) ;<-- OK but not helpful with documentation
Prototype PtrToNativeD(*p.d) ;<-- OK and helps identify parameter type
Prototype PtrToStrucDouble(*p.Double) ;<-- OK but much more to type and makes for really long lines :(
Procedure PtrNoInfo(*p)
PokeD(*p,2 * PeekD(*p))
EndProcedure
Procedure PtrToNativeD(*p.d)
PokeD(*p,2 * PeekD(*p))
EndProcedure
Procedure PtrToStrucDouble(*p.Double)
;PokeD(*p,2 * PeekD(*p))
*p\d * 2 ;<-- Alternative use
EndProcedure
Define.d x
Define *pp.PtrNoInfo = @PtrNoInfo()
Define *p.d = @x ;<-- OK, and less typing than *p.Double
;Define *p.Double = @x ;<-- OK
;Define *p.Byte = @x ;<-- Also works, but not helpful with documentation
Debug "-- Using PtrNoInfo(*p) --"
x = #PI
Debug "x = " + StrD(x,2)
PtrNoInfo(*p)
Debug "x = " + StrD(x,2)
Debug "-- Using PtrToNativeD(*p.d) --"
x = #PI
Debug "x = " + StrD(x,2)
PtrToNativeD(*p)
Debug "x = " + StrD(x,2)
Debug "-- Using PtrToStrucDouble(*p.Double) --"
x = #PI
Debug "x = " + StrD(x,2)
PtrToStrucDouble(*p)
Debug "x = " + StrD(x,2)
Debug "-- Using Prototype *pp.PtrNoInfo(*p) --"
x = #PI
Debug "x = " + StrD(x,2)
*pp(@x)
Debug "x = " + StrD(x,2)
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 8:10 pm
by luis
*p.d, *p.i, *p.f, etc. never meant something.
*p and any of the above pointers are all the same, a pointer to some memory address containing something not specified.
The need to keep them because they were used for self documenting purposes sounds a little weak to me, compared to their unreasonable existence in the first place. They have no use in the language.
*p.Double is something different, it's a pointer to a structure and makes sense, since you can access its field.
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 8:30 pm
by Danilo
It could be turned into a feature, just map the PureBasic basic types to the corresponding structures internally:
*p.a -> *p.Ascii
*p.c -> *p.Character
*p.i -> *p.Integer
This is most intuitive for many starters. 'var.i' is a basic type, '*p.i' is a pointer to basic type.
At the same time, if turned into a feature, it is readable and intuitive, shorter to write, and compatible to old versions.
The other thing:
Code: Select all
Procedure GetTitle$()
EndProcedure
would be nice, IMO. It says it returns a string and becomes part of the name (you have to always use GetTitle$() with the '$').
But for this point, it could be late to change it now because PB's string functions don't use it (Trim()/Trim$() etc..), which could be confusing.
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Wed Nov 07, 2012 8:34 pm
by skywalk
Hi luis,
I see no reason to complicate lives with this proposed change
Code: Select all
; FROM C
;;FN_ERROR _A_FUNC somedllfunction(FN_HANDLE handle,u32 nPts,f32 xdata[],f32 ydata[],f64 *res1,f64 *res2);
; TO PB
; 1 - preferred
PrototypeC.l somedllfunction(handle.l, nPts.i, *xdata.f, *ydata.f, *res1.d, *res2.d)
; 2
PrototypeC.l somedllfunction(handle.l, nPts.i, *xdata, *ydata, *res1, *res2)
; 3 -- Not sure if this one actually works for the *xdata pointing to an array of Float?
PrototypeC.l somedllfunction(handle.l, nPts.i, *xdata.Float,*ydata.Float,*res1.Double,*res2.Double)
All 3 PrototypeC definitions work, but I rely on AutoComplete to show me the various intended pointer data types and to not say it with dozens more characters.
(
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Thu Nov 08, 2012 1:07 am
by netmaestro
I rely on AutoComplete to show me the various intended pointer data types and to not say it with dozens more characters.
(
Good point. Pointers qualified with unstructured native datatypes are meaningless and the fact that the compiler doesn't forbid them is a source of confusion, especially for someone trying to get a grip on the language. I'll be thrilled when Fred disallows them, I've always thought it should be done.
I think the mapping idea where '*ptr.l' would compile to '*ptr.Long' would be a mistake. 'l' is not the name of that structure and there are enough ways to get confused in coding without introducing another one.
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Thu Nov 08, 2012 1:43 am
by skywalk
Yeah, I'm not too sure what Fred meant?
I think he will disallow *ptr.s or *ptr$ and I agree that is a good thing.
The decorated *ptr.i,*ptr.l,*ptr.w,etc. are in no way a hindrance or source of bugs and should NOT be disallowed.
Otherwise, I have to change a lot of code and lose AutoComplete self-documentation or worse be forced to add bogus commenting. Can't say it enough, please do no harm.
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Thu Nov 08, 2012 2:21 am
by netmaestro
*ptr.i,*ptr.l,*ptr.w,etc. are in no way a hindrance
But what good do they do? Without a structure they are useless and a source of confusion because coders at earlier stages of learning will look at that and think it actually does something.
Re: Disallow use of '$' when it isn't part of a variable nam
Posted: Thu Nov 08, 2012 3:13 am
by skywalk
Hi netmaestro,
I think I've said several times that *p.d is waaayyyy shorter than typing *p.Double.
And if I have 6 or more parameters in a long function call, it gets ridiculous with no line continuation.
Did you run my example code above?
;Define *p.d = @x ;<-- OK, and less typing than *p.Double
;Define *p.Double = @x ;<-- OK
Define *p.Byte = @x ;<-- Also works, but not helpful with documentation
Defining *p.Byte behaved identically? How is that for confusing?
If there is no speed improvement or bug fix involved in this pursuit, then it is only harmful to legacy code and a larger source of confusion. I cannot see the logic as presented.