[fpc-devel] class constants

Peter Popov ppopov99 at gmail.com
Mon Oct 19 13:26:34 CEST 2009


On Mon, 19 Oct 2009 04:02:45 -0500, <fpclist at silvermono.co.za> wrote:

>> > All features being equal, I would rather have class constants and  
>> class
>> > types
>> > included in FPC.
>>
>> Class constants are exceptionally bad idea: I've seen a guy define
>> PI=3.1415... inside a C++ class! The same functionality already exists  
>> in
>> fpc: define a (class, inline) function returning the constant value.  
>> Then,
>> if you are a moron, you will have to write a lot of code to do a  
>> senseless
>> thing, otherwise possibilities for abuse multiply exponentially :-)
>
> The implementation I'm talking about that would have a constant PI=3.1415
> within say MyClass would only work if called as MyClass.PI

PI exists, it has a unique transcedental value, so it should clearly be  
global. Semanticaly, MyClass1.PI and MyClass2.PI are different  
identifiers, which given the nature of PI is a ridiculous concept.

>
> In your example, the global PI would always be defined unless somebody
> redifines it, and then it's not a class constant anyway.

That is my point: most constants are global in nature. It would be  
interested to see a class constant which is usefull where a global  
constant (within a unit) is not.

>
> if OOP is about data encapsulation, why are we using global constants and
> types?

You forget that units already provide one encapsulation level. This has  
been a distinct feature of Pascal long before C++ introduced namespaces.  
This means that Unit1.PI and Unit2.PI are two different entities. I think  
that is more than enough, as far as constants are concerned. So, what the  
class constant really implements is an inline function, returning a fixed  
value. Thus, the mechanism is already there and providing a meaningless  
language expansion goes the C++ way: every programming paradigm can be  
done in several different ways. This confuses the inexperienced mind and  
leads to the above mentioned absurdities.

Peter



More information about the fpc-devel mailing list