[Implemented] #PB_Compiler_EnableExplicit

[Deeem2031]

It would be nice if you can check if you are in a EnableExplicit-block or not when writing an includefile. Because you can't use Enable/DisableExplicit now without effecting the main program. And always adding EnableExplicit when you edit the include file and remove it if your finished is annoying, so something like this should be possible:

Code: Select all

CompilerIf #PB_Compiler_EnableExplicit = #False
  EnableExplicit
  #TemporaryEnableExplicit = #True
CompilerEndIf

;... Code ...

CompilerIf #TemporaryEnableExplicit
  DisableExplicit
CompilerEndIf

[EDIT] Or you make it "stackable" like if you write EnableExplicit after a EnableExplicit you need two DisableExplicits to disable it.

[ts-soft]

+ 1

[Deeem2031]

Another solution to this problem would be, making Enable/DisableExplicit only changing the behavior in the source-file the command is written in. So files included are not affected at all - I think this is the best approach to this problem.

[Mistrel]

+1, considering you have no way to controlling the explicit once you step into an include file.

[akj]

+1

I am very much in favour of Deeem2031's suggestion with the proviso that every included source file is initially in DisableExplicit mode to maintain compatibility with older code.

It will certainly resolve the problem of third-party code (such as srod's) that unexpectedly contains Enable/DisableExplicit lines.

[srod]

It will certainly resolve the problem of third-party code (such as srod's) that unexpectedly contains Enable/DisableExplicit lines.

Nothing unexpected about it I'm afraid; I always start my utilities with EnableExplicit and then finish the code with a DisableExplicit and fill the space between them with as many bugs as I can find!

To be honest I find it difficult to see why anyone would want to disable the explicit mode? Maybe that's just me though.

[akj]

@srod:

The problem your code causes me is not the EnableExplicit at the start but the DisableExplicit at the end. The latter should either be (1) removed by you or (2) ignored by the compiler if EnableExplicit mode is already in effect when your code gets complled [which of course is the whole point of this forum topic].

[srod]

Aye, I understand the request and it is not an unreasonable one for sure. Must admit though that it never occurred to me that my surrounding my utilities with EnableExplicit / DisableExplicit would cause any problems. Having set this mode within a source-code include, I have no choice but to clear it before the end of the source so as not to disrupt someone else's code which may not have set this mode and may not have coded in an appropriate fashion (defining all variables explicitly etc.)

I generally pile all of my includes at the top of main source and then follow this with an additional EnableExplicit anyhow, which of course means that my main source benefits from setting explicit mode. I always code with this mode set and remove it for demo / test programs only. Guess I kind of figured that others would utilise their source code includes in a similar way, setting / clearing explicit mode as appropriate after the inclusion of these files.

I never really thought beyond my own use of this mode.

[akj]

@srod:
Thanks for your helpful reply. You are trying

not to disrupt someone else's code which may not have set this mode

but the problem is that it disrupts code that has set this mode.

Until Enable/DisableExplicit are redefined to be purely local to the current source file, the only good solution is to remove all instances of Enable/DisableExplicit in published include files, though of course they will probably exist during the author's development and testing of the code.

A further possibility has just occurred to me. The format of Enable/DisableExplicit could be extended:

Code: Select all

EnableExplicit [#PB_Default]
DisableExplicit [#PB_Default]

where

Enable/DisableExplicit would have their current meaning, but be purely local to the current source file

and

Enable/DisableExplicit #PB_Default would have the same meaning, but additionally would set the default Explicit mode for each subsequent source file processed by the compiler, during the lifetime/scope of the current source file.

Thus, if

Code: Select all

EnableExplicit #PB_Default

appeared at the very start of a program, not only would EnableExplicit be immediately in effect, but every [subsequent] include file would start life in EnableExplicit mode, even if the very next line of the program was DisableExplicit .

[srod]

I shall remove them from my utilities then prior to any future updates.

[ts-soft]

I shall remove them from my utilities then prior to any future updates.

thanks, so no more many work on update-days

[Little John]

It also depends on the order of the regarding lines in the main source code. Some time ago, it was a habit of mine to always write EnableExplicit as the first executable statement of a source code. I remember very well, consequently when I firstly used one of your (srod's) utilities, I did it this way:

Code: Select all

EnableExplicit
XIncludeFile "cool_tool.pbi"
...

And I was rather puzzled that my nice EnableExplicit didn't have any effect.
However, then I realized that doing it the other way round works fine.

Code: Select all

XIncludeFile "cool_tool.pbi"
EnableExplicit
...

Regards, Little John

[srod]

That's exactly how I structure all of my programs Little John.

[Kaeru Gaman]

However, then I realized that doing it the other way round works fine.

Code: Select all

XIncludeFile "cool_tool.pbi"
EnableExplicit
...

my thoughts exactly!

[ts-soft]

Code: Select all

XIncludeFile "cool_tool.pbi"
EnableExplicit
...

But sometimes requires my include some constants, structures or variables
from my source, so i can't put the XInclude ever at beginning.

Only for Testing EnableExplicit on includes, after finish i remove this.
Best way was the wish by Deem2031