(partially solved) Clean up little language inconsistencies

[Bitblazer]

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.

[Little John]

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?

[Bitblazer]

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?

Then this specific example might be a documentation inconsistency which should be fixed.

[skywalk]

#TRUE and #FALSE are interchangeable with 0 and 1 and I use the latter for simplicity.
What is the problem here?

[Bitblazer]

#TRUE and #FALSE are interchangeable with 0 and 1 and I use the latter for simplicity.
What is the problem here?

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.

[Little John]

What is the problem here?

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.

#TRUE and #FALSE are interchangeable with 0 and 1

If that would be an official statement,

PureBasic has more than 10'000 built in named constants.
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

There is a short paragraph about constants in general in the official documentation: General rules.

i will dig out the source and situation where doing this, created unexpected behaviour.

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]

i will dig out the source and situation where doing this, created unexpected behaviour.

Yes, please show a snippet of working code (as short as possible), where interchanging #True and #False with 1 and 0, respectively, causes troubles.

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.

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.

[BarryG]

it will probably take 4 weeks before i stumble on this special case by chance again

PEBKAC. There is nothing wrong with DisableGadget(). The parameter you used with it had an incorrect value.

[spikey]

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:-

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)

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.

[Josh]

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.

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.

[wombats]

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?

Yup. Go to "Session History" in the "File" menu.

[Little John]

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.

Such an addition to the documentation would probably be the perfect solution here.

However ...

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.

I would put it this way:
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.

[Tenaja]

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.

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.