Hi Hans,
I am sorry to disagree with you.
The attributes in particular allow you to do real magic, and reduce your
code by at least 4 times, and speed up your development up to 10 times.
We have done that in Delphi.
I actually did a session in the PasCon few days on that.
Here is example:
TMyInterfacedClass1 = class;
[CreateType( typeinfo( TMyInterfacedClass1 ))] // Specifies the default
creation type as TMyInterfacedClass1
IMyInterface = interface
['{EB12CEBD-42C3-4259-AE2C-70267B67F454}']
function GetValue() : String;
end;
TMyInterfacedClass1 = class( TBasicInterfacedObject, IMyInterface )
public
function GetValue() : String;
end;
TMyInterfacedClass2 = class( TBasicInterfacedObject, IMyInterface )
public
function GetValue() : String;
end;
TMyNestedClass = class( TBasicObject )
protected
[Default( True )] // FValue1 will be initialized with True
FValue1 : Boolean;
[Default( 11.5 )] // FValue2 will be initialized with 11.5
FValue2 : Real;
[AutoManage( TMyInterfacedClass2 )] // FInterfaceValue will be created as
TMyInterfacedClass2
FInterfaceValue : IMyInterface;
public
property Value1 : Boolean read FValue1;
property Value2 : Real read FValue2;
property InterfaceValue : IMyInterface read FInterfaceValue;
end;
TMyClass = class( TBasicObject )
protected
[Default( 100 )] // FValue1 will be initialized with 100
FValue1 : Integer;
[Default( 'Helo World!' )]
FValue2 : String; // FValue1 will be initialized with 'Helo World!'
[AutoManage] // FNested will be automatically created and destroyed
FNested : TMyNestedClass;
[AutoManage( TStringList )] // FStrings will be automatically created as
TStringList and destroyed
// [AutoDestroy] // - If AutoDestroy is used instead of AutoManage, the
object will not be created but will be automatically destroyed!
FStrings : TStrings;
[AutoManage] // FNested will be automatically created as TStringArrayList
FStringArrayList : IStringArrayList;
[AutoManage] // FInterfaceValue will be created as TMyInterfacedClass1
FInterfaceValue : IMyInterface;
public
property Value1 : Integer read FValue1;
property Value2 : String read FValue2;
property Nested : TMyNestedClass read FNested;
property Strings : TStrings read FStrings;
property StringArrayList : IStringArrayList read FStringArrayList;
property InterfaceValue : IMyInterface read FInterfaceValue;
end;
As you can see all the management of all the classes and interfaces is done
without the need of even one line of code.
No constructors, no destructors, nothing.
This alone cuts vast amounts of code.
This however only scratches the surface of the RTTI power. You have no idea
about some of the other possibilities ;-) .
The RTTI does not only work with properties and fields, but with functions
as well, allowing easy implementation of RPC and network distributed
execution.
It is a whole ball game.
Frankly some of the arguments you provide ware the same I have heard 20
years ago when I programmed in C++ and people ware telling me I should be
doing it in Assembler.
They simply had no idea what power OOP had as example, as you probably have
no idea what is the real power of modern RTTI when properly used.
I am at the same time huge fan of strong typed languages. The advanced RTTI
does not really mean the code should and will not be strongly typed. Indeed
I have done my own RTTI API which is stronger typed than the one Delphi
provides.
With best regards,
Boian Mitov
-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message-----
From: Hans-Peter Diettrich
Sent: Friday, September 19, 2014 4:28 PM
To: FPC developers' list
Subject: Re: [fpc-devel] RTTI generating
Boian Mitov schrieb:
It's up to the coder to make all properties etc. published, when he
*intends* to ever use RTTI on them. That't the way to tell the compiler
what to do.
Inside a program there exists no distinct "brave object inspector" and
"unauthorized object garbler" - both can be implemented by using RTTI.
If you don't like safe types and other restrictions, which exist in
Pascal for good reasons, then choose any unsafe language to implement
whatever mess you like :-]
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
