Marco van de Voort:
Class constants add the ability to provide scoped, "namespaced" constants.

A constant is already in a scope, the unit.

The unit scope is a very open scope. Via class constants, one gets private, protected and public scoping for constants, all of which are essential scope levels for OOP.


Although one can handle basic scoping with global constants, by placing them in interface vs implementation, they were not designed to be scope-limited.
They also do not provide a way to group several constants under a common
name, though one can simulate this functionality using creative constant
names.

Stuff them in one unit. unitname.constant.

1 unit for every unique constant prefix is asking a lot. Some applications have many (>100) different constant prefixes.


Some of the benefits of class constants are: 1. They provide object-oriented
constants,

That's a description, not a benefit. Taste matters are difficult to measure.

Constants are not OOP, adding class constants provides OOP constants.


3. They reduce coding errors due to the ability to only make public what is
necessary, keeping what is visible to outside units/classes to a mimimum.

Units/move them to implementation. The chance that random classes in the
same unit clash is negliable.

What if the developer wishes to provider the ability to override their class, and allow access to the constants from descendant classes? The constants inside the implementation section are invisible to descendant classes in other units. Class constants provide protected-level scoping


Personally, the main reason I need them is for compatibility. I have a large Delphi codebase that I'm porting to FPC and it uses class constants all over
the code.

IMHO that is the only decent reason. Technically IMHO it doesnt make much
sense, it's just a dotnetism, copying blindly from a different world to make
nice feature butlletlists.

And like the rest of the dotnetims, they are relatively little used,
probably mostly out D7- compat reasons. And thus they are waiting for an
implementor. I'm not aware of work being done on any of them (though I have a vaguely recollection that the strict private and protected exist, but I'm
not sure if in fully compat form).

Besides implementing, making a good study of what they _EXACTLY_ do, and a
bunch of testcases/unittests could really further the cause also.

Thanks for the info.

Jon
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to