demian at knowhow-online.com.br
Thu Nov 13 17:52:58 CET 2003
> There are some extensions yes, and in the future, foreign
> OSes and processors might cause some more extensions.
> However in general we reluclantly add features, usually
> because the main argument from most people is "it would
> be nice to have ....", and there are many more reasons
> not to (clean language, less features means more time
> spent on stability etc).
That is a very good point and I'm inclined to agree with
>> FP offers operator overloading, which is not an Object
>> Pascal feature. I'm not yet familiar with the compiler
>> but I guess many other features are also particular to
> Never versions of Delphi offer it.
Guess I should read the manuals of the newer versions
because I missed this new feature...
>> Class attributes is another missing part of the
>> (language feature) puzzle. Why is it not supported
>> by Object Pascal and FP?
> That's the wrong question. The good question is "what
> would be the use?"
> I see two reasons in your article,
> The first is class instance counting, for which I, and
> I'm no OOP hotshot, can already name two solutions
> - use a factory pattern, or
> - a global var in the implementation part of the unit
> that implements it, and that is atomically updated
> by create and destroy.
> and there is no added benefit to have the properties in
> the language for this example, except the minimal benefits
> of datahiding. (actually the data is properly hidden if
> you only put that class in the unit, all constructs can be
> abused. I can also keep a pointer to class attributes)
> The second solution is even a general workaround for class
> The second reason (association of an object instance to the
> class as a whole (for management purposes), is actually the
> 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. 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.
> FPC is about providing a production compiler, not to do
> language research, so added features must have real use.
>> It really doesn't make sense to me. Unless, of course,
>> this is so complex to implement...
> It is certainly _very_ complex to implement I think.
>> It's good that you pointed out early that the main thought
>> here is to keep Delphi compatibility. This way I won't dream
>> of features that will "never" be part of FP.
> 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
> Baroque syntax doesn't originate in the Pascal camp :-)
> I know a lot of the new open source scripting languages
> like to have a lot of features. How many _really_ large
> programs were written in them?
I see your point...
More information about the fpc-pascal