(partially solved) Clean up little language inconsistencies
(partially solved) Clean up little language inconsistencies
There are some irritating small inconsistencies (left over i guess) in the language which keep nagging me during daily usage. One of those that i keep having to open and check the help file each time is this:
In many different gadgets/libraries you need to disable, hide, enable, show a window, entity or gadget. It is a basic thing a programmer has to do many times. One annoying thing is that you cant tell if the purebasic language uses a negative or positive method. It would be better if it was always one case and not sometimes the other. For example to show a window, you have to use hidewindow with a parameter of false. That is like a double negation to achieve what you want, but ok. Lets call that a convention, but then you have this for gadgets:
DisableGadget
but for windows it is
DisableWindow
The parameter difference seems minor and i am even used of using 0 for #false and 1 for #true in other languages (because thats how they are usually internally used). But i recently did the same in purebasic 5.62 x64 windows and was surprised about the code suddenly showing irritating unexpected behaviour. So you need to keep these minor inconsistencies in your mind and at least remember that you have to check any recently added function call which uses a on/off parameter.
My suggestion is to make a break at some point and clean all these little historic inconsistencies up. I know it will create "help my project doesnt compile anymore!" postings and necessary cleanups of code archives, but it's one of those things which you really dont expect in a professional language/environment. Just IMHO
I am sure there is a small number of these that where introduced throughout the years and others can point out more of them.
In many different gadgets/libraries you need to disable, hide, enable, show a window, entity or gadget. It is a basic thing a programmer has to do many times. One annoying thing is that you cant tell if the purebasic language uses a negative or positive method. It would be better if it was always one case and not sometimes the other. For example to show a window, you have to use hidewindow with a parameter of false. That is like a double negation to achieve what you want, but ok. Lets call that a convention, but then you have this for gadgets:
DisableGadget
but for windows it is
DisableWindow
The parameter difference seems minor and i am even used of using 0 for #false and 1 for #true in other languages (because thats how they are usually internally used). But i recently did the same in purebasic 5.62 x64 windows and was surprised about the code suddenly showing irritating unexpected behaviour. So you need to keep these minor inconsistencies in your mind and at least remember that you have to check any recently added function call which uses a on/off parameter.
My suggestion is to make a break at some point and clean all these little historic inconsistencies up. I know it will create "help my project doesnt compile anymore!" postings and necessary cleanups of code archives, but it's one of those things which you really dont expect in a professional language/environment. Just IMHO
I am sure there is a small number of these that where introduced throughout the years and others can point out more of them.
Last edited by Bitblazer on Mon Nov 04, 2019 6:42 pm, edited 1 time in total.
-
- Addict
- Posts: 4527
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany
Re: Clean up little language inconsistencies
HideWindow(a, #True) hides window a,
DisableWindow(a, #True) disables window a,
DisableGadget(a, #True) disables gadget a.
Using #False as parameter instead of #True will have the opposite effect, as expected.
There is no inconsistency in the behaviour of those built-in commands.
There is only a minor "inconsistency" in the documentation of DisableGadget(), because there it reads 1 instead of #True, and 0 instead of #False.
So what?
DisableWindow(a, #True) disables window a,
DisableGadget(a, #True) disables gadget a.
Using #False as parameter instead of #True will have the opposite effect, as expected.
There is no inconsistency in the behaviour of those built-in commands.
There is only a minor "inconsistency" in the documentation of DisableGadget(), because there it reads 1 instead of #True, and 0 instead of #False.
So what?
Re: Clean up little language inconsistencies
Then this specific example might be a documentation inconsistency which should be fixed.Little John wrote:There is only a minor "inconsistency" in the documentation of DisableGadget(), because there it reads 1 instead of #True, and 0 instead of #False.
So what?
Re: Clean up little language inconsistencies
#TRUE and #FALSE are interchangeable with 0 and 1 and I use the latter for simplicity.
What is the problem here?
What is the problem here?
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Clean up little language inconsistencies
If that would be an official statement, i will dig out the source and situation where doing this, created unexpected behaviour. Seems the problem is just in the documentation.skywalk wrote:#TRUE and #FALSE are interchangeable with 0 and 1 and I use the latter for simplicity.
What is the problem here?
-
- Addict
- Posts: 4527
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany
Re: Clean up little language inconsistencies
The only potential say "micro problem" here is, that the help is not didactically perfect, since in some cases #True and #False is used, while at least in one comparable case 1 and 0 is used instead. I can't regard that as a real problem either.skywalk wrote:What is the problem here?
PureBasic has more than 10'000 built in named constants.Bitblazer wrote:If that would be an official statement,skywalk wrote:#TRUE and #FALSE are interchangeable with 0 and 1
There is no "official statement" about each named constant ... they are defined and that's it.
Just look for #True and #False in the IDE's Structure Viewer, or run this tiny code snippet:
Code: Select all
Debug #True
Debug #False
Yes, please show a snippet of working code (as short as possible), where interchanging #True and #False with 1 and 0, respectively, causes troubles.Bitblazer wrote:i will dig out the source and situation where doing this, created unexpected behaviour.
Re: Clean up little language inconsistencies
I just tried to reproduce it, but failed. It happened in a project i edited some days ago, but i have about 6 active projects currently. Is there an easy way to browse the recent editing history of these 6 active projects to find the situation again? Otherwise, it will probably take 4 weeks before i stumble on this special case by chance again It was among the changes during the recent 2 weeks.Little John wrote:Yes, please show a snippet of working code (as short as possible), where interchanging #True and #False with 1 and 0, respectively, causes troubles.Bitblazer wrote:i will dig out the source and situation where doing this, created unexpected behaviour.
There has to be a session history file file which the ide creates, so it can show the recent changes in case of a crash recovery. Is there already a tool to easily check that data? Preferably by project.
Re: Clean up little language inconsistencies
PEBKAC. There is nothing wrong with DisableGadget(). The parameter you used with it had an incorrect value.Bitblazer wrote:it will probably take 4 weeks before i stumble on this special case by chance again
Re: (partially solved) Clean up little language inconsistenc
I can see the point - although I don't agree with the conclusion.
In a strongly typed language with a distinct Boolean type True does not equal one and False does not equal zero - they are discrete values on their own. Such assignments or comparisons would lead to a compiler error, an unexpected cast or a bug, in that language.
The fact that PB doesn't have a strong Boolean type is only apparent from its absence in the documentation - something which could be easy to miss if you aren't expecting it, especially when the presence of #True and #False seems to imply one from a particular perspective.
Working around this perceived problem would lead to redundant code in PureBasic:-
I suggest the solution is to document specifically on the 'Variables, Types and Operators' help page that PB doesn't have a distinct strong Boolean or Logical type and that #True is equal to 1 and #False is equal to 0 and are interchangeable. A cross reference to the Bool function at the same point probably wouldn't go amiss.
In a strongly typed language with a distinct Boolean type True does not equal one and False does not equal zero - they are discrete values on their own. Such assignments or comparisons would lead to a compiler error, an unexpected cast or a bug, in that language.
The fact that PB doesn't have a strong Boolean type is only apparent from its absence in the documentation - something which could be easy to miss if you aren't expecting it, especially when the presence of #True and #False seems to imply one from a particular perspective.
Working around this perceived problem would lead to redundant code in PureBasic:-
Code: Select all
If SomeBoolean = #True
HideGadget(#SomeGadget, 1)
Else
HideGadget(#SomeGadget, 0)
EndIf
; instead of
HideGadget(#SomeGadget, SomeBoolean)
; or
If SomeInteger = 1
HideWindow(#SomeWindow, #True)
Else
HideWindow(#SomeWindow, #False)
EndIf
; instead of
HideWindow(#SomeWindow, SomeInteger)
Re: (partially solved) Clean up little language inconsistenc
Of course it can be done that way. But it seems a little weird to me that we still have to discuss #True and #False with a forum member with several hundred posts.spikey wrote:I suggest the solution is to document specifically on the 'Variables, Types and Operators' help page that PB doesn't have a distinct strong Boolean or Logical type and that #True is equal to 1 and #False is equal to 0 and are interchangeable. A cross reference to the Bool function at the same point probably wouldn't go amiss.
sorry for my bad english
Re: Clean up little language inconsistencies
Yup. Go to "Session History" in the "File" menu.Bitblazer wrote:There has to be a session history file file which the ide creates, so it can show the recent changes in case of a crash recovery. Is there already a tool to easily check that data?
-
- Addict
- Posts: 4527
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany
Re: (partially solved) Clean up little language inconsistenc
Such an addition to the documentation would probably be the perfect solution here.spikey wrote:I suggest the solution is to document specifically on the 'Variables, Types and Operators' help page that PB doesn't have a distinct strong Boolean or Logical type and that #True is equal to 1 and #False is equal to 0 and are interchangeable. A cross reference to the Bool function at the same point probably wouldn't go amiss.
However ...
I would put it this way:spikey wrote:The fact that PB doesn't have a strong Boolean type is only apparent from its absence in the documentation - something which could be easy to miss if you aren't expecting it, especially when the presence of #True and #False seems to imply one from a particular perspective.
The fact that PB doesn't have a Boolean type is obvious from its absence on the 'Variables, Types and Operators' help page.
And when someone gets to know a new programming language (or something else), s/he better should not assume that things are as s/he expects, but rather inform her/himself thoroughly.
Re: (partially solved) Clean up little language inconsistenc
I think assumptions cause more Help! or Bug! threads started by newbies than anything else! I think I even asked for help a few times because of this.Little John wrote: And when someone gets to know a new programming language (or something else), s/he better should not assume that things are as s/he expects, but rather inform her/himself thoroughly.