On Mon, 19 Oct 2009 04:02:45 -0500, <fpcl...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
