Francisco Reyes wrote

I was refering to not seeing a note that one can not have a unit name be the same as a function name. I was never refering to case sensitivity. Sorry for not been more clear.

---

Ahh, OK. Yes, I've run into that problem myself. The one I remember was where I was using the MacOSAll unit which defined a random function which then hid the FPC version of random with the same name declared in the system unit. The only reason I figured it out was that I tried passing a parameter which didn't work and someone pointed out to me what happened. I was told that you could use both versions and the FPC version could be accessed by calling system.random. That is, you can use the unit name as a dot notation prefix (like a record or method) to access the specific one you want.

In addition, I am thinking it would be a nice feature for an IDE to color code the FPC RTL routines to give one a clue if you are trying to redefine a system function. There are reasons for allowing multiple defined names but it can be a bit confusing.

By the way, I've tested the system.random function and three of the random functions supplied by Apple via MacOSAll, and I have found the FPC implementation to be the fastest most "accurate" and most flexible (due to the FPC function overloading.) - ROW

Where/why would one use a typed constant vs. a variable. i.e.

const
  	myConst : double = 2.0*Pi;
var
	myVar : double = 2.0*Pi;

It seems to me the typed constant is superfluous and can potentially lead to bugs.

Richard Ward wrote

Where/why would one use a typed constant vs. a variable. i.e.

Any time you have a value you want to have in an accessible holder, but want to ensure you will not change it's value by mistake.

It seems to me the typed constant is superfluous and can potentially lead to bugs.

On the contrary. They help saveguards against bugs. Imagine a team of people working on different parts of a large system. One team defines a constant; someone on another team sees a piece of code and thinkgs he working with a variable. He tries to change it and the compiler throws an error because it is a constant. That error just saved that system from a logical, possibly hard to find, error.

Typed constants ARE changeable (just like variables), the only place where they behave differently from variables is if they're declared in a local scope (i.e. function / procedure). Typed constants act like a static variables in C, where it's initialized only once during program execution.

Typed constants predate the existence of initialized variables. Furthermore,
a) typed constants are initialized once (when the program starts), and if changed keep their value until explicitly changed again (even if they are declared locally in a procedure/function, and over multiple independent invocations of such routines)
b) conversely, initialized variables are initialized every time their scope is activated (or whatever the proper term for that is: once in case they are declared in a program/unit scope, and every time a function/procedure is entered if they are declared locally in a routine) c) typed constants can be made read-only by using the {$j-} switch

Jonas

Jonas wrote:

b) conversely, initialized variables are initialized every time their scope is activated (or whatever the proper term for that is: once in case they are declared in a program/unit scope, and every time a function/procedure is entered if they are declared locally in a routine)

---

Thanks for this explicit clarification. This was the bit of information which was not getting through to me before.

Francisco,

In FPC, there are two types of constants: ordinary and typed.

"Ordinary" constants are what you were thinking of while "typed" constants act a bit differently as Jonas and lele wrote. My confusion was that typed constants and initialized variables seemed to me to behave exactly the same - that is, acted like variables - until I learned the subtle difference in (b) above. Although I can appreciate why the term "typed constant" was selected for such a language feature, it was confusing to me since I tend to think of constants as being "constant" and one has to be careful in realizing the difference lest things don't work the way as one might expect. - ROW