[fpc-devel] class constants

[fpclist at silvermono.co.za]

On Monday 19 October 2009 13:26:34 Peter Popov wrote:
> 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.

This is your opinion, and you are entitled to it, however, as I have already 
said, class constants fit in better with OOP, where the constant has meaning 
only within the class  that houses its definition.

According to your logic, the same could be said for global variables versus 
class fields.


>
> > 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 at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel