Or even more drastic example like this one:
AAttributes := TRTRtti.GetType(
Component.ClassType() ).GetCustomAttributes(
TVLCommonFilterHostedPreviewAttribute, True );
for AAttribute in AAttributes do
if( AAttribute is TLPComponentEditorAttribute ) then
begin
AAttrItem := GComponentEditorAttributeList.Find(
function( AItem : IComponentEditorAttributeItem ) :
Boolean
var
AAttributes : IRTAttributes;
AAttributeClass : TCustomAttributeClass;
begin
AAttributeClass :=
AItem.GetInstance().AttributeClass;
AAttributes := TRTRtti.GetType(
Component.ClassType() ).GetCustomAttributes( TLPSuppressAttribute, True );
if( AAttributes.Find(
function ( ASupressAttribute :
TCustomAttribute ) : Boolean
begin
Result := ( AAttributeClass =
TLPSuppressAttribute( ASupressAttribute ).Attribute );
end
) <> NIL ) then
Exit( False );
Result := ( AAttribute is AAttributeClass );
end
);
Exit( AAttrItem.GetInstance().ComponentEditor.Create( Component,
Designer ));
end;
Try to write this without anonymous methods ;-) :-D .
With best regards,
Boian Mitov
-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message-----
From: Martin
Sent: Sunday, March 03, 2013 8:42 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods
On 04/03/2013 03:49, Boian Mitov wrote:
Yes, really!
Then again this is over 4 mln mines of code after all. :-D
Thank you for letting me know what closure is :-D . Can you imagine, me
being component vendor for over 16 years and not knowing what closure is
:-D.
Did I? Wow, I didn't know I did. Didn't mean to neither. I was just
checking, if you accidentally used the wrong word. (Happens to everyone,
even the very best / so no judgement implied)
Anonymous methods lead to a different way of thinking altogether and allow
you to do things that you can't even imagine with closures ;-) .
And they make the code infinitely easier to read, especially if like me
this is a huge codebase ;-) . After all we sell well over 400 components
not to mention some of our other Delphi based products ;-) .
Sure, if you have small code you can do just fine with closures, as I have
for many years, then again I did just fine without having classes, and
objects in the old days, and also did fine in the older days in Assembler
:-D .
So according to this logic, we really should be doing everything in
machine code (as I actually did briefly 24 years ago :-D ), who needs new
features such as those whatmacallit... ohhh yeahh... "compilers" :-D .
Well I give you the benefit of the doubt, and believe you. But that does
not help me, because I still do not know which case you are talking
about.... So for my benefit, please enlighten me with an example.
From your above statement, I take, that you already used closures, and
that the big improvements really happened of a result of anonymous methods.
Just to be save, let me state the obvious: We are talking of dropping
the function name; and introducing the ability, to declare the function
anywhere within the code (probably the latter being the important). That
are the 2 only things, that anonymous methods do offer? (OR am I missing
anything?)
If so then I do not see how they save 20000 lines?
- The name is part of the declaration line, SO it should not affect the
line count at all). Unless you always write the name on a separate line
(which I would consider a very special case)
- the place of declaration also does not change the line count.
-----Original Message----- From: Martin
Sent: Sunday, March 03, 2013 7:38 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods
On 04/03/2013 01:47, Boian Mitov wrote:
Really, just by dropping the names? Or did you mean, you did all that by
using closures?
Closures, do not need to be written/declared in the middle of other code
(in-line)
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
