demian at knowhow-online.com.br
Thu Nov 13 18:45:05 CET 2003
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
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
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
> 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
More information about the fpc-pascal