I'm not debating whether a feature should or should not be considered for inclusion in FP. It just occurred to me that class attributes are constructs that have *real* use beside just stylish correctness. Class methods have been implemented, right? Aren't them just as equivalent to global procedures and functions as class fields are to global variables? BTW, Peter replied to my message saying that class fields are supported through the use of the static directive.
I know that an OS initiative such as FP should invest its time in the development of features that will bring the most benefit to a larger share of the community. Things such as bringing compatibility with Delphi, making the compiler stabler and faster, supporting more plataforms, and implement missing or unfinished functionality come to my mind. All I wanted to do was discuss possibilities and understand why a given feature was not implemented by FP and if it was being considered for implementation.
I do agree with you that when a "hybrid" language such as Object Pascal offers constructs that allow me to implement funcionality simpliar or analogous to those I'd implement using pure OO constructs on another language, other features deserve more attention because they will add more to the project.
I also won't debate which OO features are worth using/implementing. This will bring us down to our understanding and our personal opinions about the OO paradigm. Bertrand Meyer has written in his book Object-Oriented Software Construction that method overloading (syntactic polymorphism) is not such a great technique because it makes the source code hard to read and understand. Overloading itself is not an OO specific feature but many OO languages do implement it. As you see, it is questionable whether this is a good feature or not. I personally like to use it, and I use it with care but I understand the reasons why Mr. Meyer thinks it is not a good technique.
Anyway, thanks for the reply. It is always nice to share experience with knowledgeable people!
Regards,
Demian
Marco van de Voort wrote:
same thing more or less.
Both can be solved properly, and personally I find the workaround presented in the article uglier than the simple variable in the implementation of the unit.
----
I think you missed the point of the article. I had no intention
to list the benefits of using class attributes. I just wanted to share a technique that would enable developers that wish to use class attributes to be able to use them.
In my opinion, class fields/properties do bring about many benefits. Not only do they allow data hiding on the class level, they also allow global values to be bound to their classes, and not left outside the class code. A value you define that is only meaningful in the class context should in fact be encapsulated in the class.
Nice and stylish, but still no practical reason.
Also, and perhaps this is a big point to note, using global or unit local variables is questionable OO programming technique. If you really wish to develop in OO style, you will stay away from globals and try to keep all your class data within your class definition, and all your object data within your object instance.
That is exactly why I use a "multi-paradigm" language like Object Pascal, because
I'm able to use the strengths of those.
If I want to use pure OO, I'll use SmallTalk. OO is a tool, not a religion.
More important is the Pascal background I think. The Wirthian languages always were relatively small, consistent and clean, and usually the argument is that this makes compilers easier to implement, and avoids nasty side effects, which you are bound to encounter when programs get big (read way over a hundred thousand lines)
but new features will always come along- it is inevitable. the secret is knowing what is worthwile supporting in new compiler versions...
That is exactly the reason why I'm having this discussion. There have to be benefits, rather than just stylish correctness.
I'd rather have the time spent on e.g. generics (what C++ calls templates),
which are also fashionable, but at least I can view them as a serious tool.
FPC needs these discussion even more than e.g. Delphi. Borland can
commission a couple of programmers for a year to follow what turns out to be
a dead end.
For FPC, that same "year" is much longer, since the developers do this part time. Adding rare used features.
This is also a reason why FPC is not embarking on some .NET or Java bytecode adventure.
_______________________________________________ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
