Re: [fpc-devel] class abstract, class sealed implementation. please review.
On Tue, Oct 20, 2009 at 4:59 AM, Paul Ishenin i...@kmiac.ru wrote:
What we will get in the result of this language simplification? Yes,
extremely fast and easy compiler but do you like it?
Maybe the syntax should be simplified, rather than following new
delphi's .Nettist growing style? AFAIK, it's been discussed about
using class attributes.
Delphi has:
TMyHelper = class helper of TParent
...methods...
end;
TAbstractClass = abstract class(TSomething)
...methods...
end;
TSealedClass = sealed class(TSomething)
...methods...
end;
but FPC can use
TMyHelper = class(TParent)
[helper]
...methods...
end;
TAbstractClass = class(TSomething)
[abstract]
...methods...
end;
TSealedClass = class(TParent)
[sealed]
...methods...
end;
Using attributes makes language, simplier, because user don't need to
learn new constructions, they might need to learn *possible*
attribute, modifiers.
Let's say, thay FPC packages are finally implemented, and helper and
sealed classes are supported. The final syntax of the class would be:
TSealedClass = class(TParent)
[sealed, external]
...methods...
end;
With new features added to the FPC, will be easily added for classes:
TMyCoolClass = class(TParent)
[feature1, feature2... etc]
...methods...
end;
Such syntax also makes parsers' job easier. Because, they don't need
to be aware of new structures, but treat anything inside '[..]' as set
of modifiers or strings separated by commas.
attributes and stringed attributes are already used in Interfaces
declaration:
IMyInterface = interface
['{2EC9224F-3D48-4CD3-80E7-2EF7441C0DD5}']
procedure Method;
end;
Of course the primary reason for adding new structures
(helpers/abstract/sealed) to the compiler is delphi compatibility,
they can be left for {$mode delphi} only.
thanks,
dmitry
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
On Tue, Oct 20, 2009 at 17:59, dmitry boyarintsev skalogryz.li...@gmail.com wrote: On Tue, Oct 20, 2009 at 4:59 AM, Paul Ishenin i...@kmiac.ru wrote: Maybe the syntax should be simplified, rather than following new delphi's .Nettist growing style? AFAIK, it's been discussed about using class attributes. Excellent idea, and I even wanted to propose that myself, but it breaks compatibility. I would like to defer the current sealed/abstract implementation to Delphi mode and use some general syntax for fpc/objfpc. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
In our previous episode, dmitry boyarintsev said: What we will get in the result of this language simplification? Yes, extremely fast and easy compiler but do you like it? Maybe the syntax should be simplified, rather than following new delphi's .Nettist growing style? AFAIK, it's been discussed about using class attributes. Please no. While I directly agree it is better, having incompatible syntax, specially for minor features is more trouble then it is worth, since eventually the Delphi syntax will have to be supported anyway. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New global CustomApplication variable
Michael Schnell wrote: Important additional Question: Martin: Any comment on this ? Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New global CustomApplication variable
Martin, Any additional comment on Michael Van Canneyt's suggestion Feel free to contribute a descendant of TCustomApplication that adds a message queue. which I tried to gently pass over toward you ? :) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] New feature discussion: for-in loop
Hello, FPC developers' list. I think we can close 'sealed/abstract class' page and open another interesting topc. It is obvious you are full of energy to discuss new language features. The next feature which we should think of is for-in loop: http://wiki.lazarus.freepascal.org/for-in_loop There you can find: 1. Delphi implementation details 2. Proposed extended syntax 3. Proposed compiler implementation While discussion please try to have delphi compatibility in the mind. -- Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
Vinzent Höfler schrieb: Florian Klaempfl flor...@freepascal.org: Marco van de Voort schrieb: In our previous episode, Florian Klaempfl said: This is exactly my point about sealed classes. When you design the product or class, you have NO way of know what will come in the future. So you need to stay flexible to change! Yet another OOP principal that sealed tries to prevent! This might be true, but what's the difference with private etc.? Private is typically used in nearly every class, sealed in exceptional cases. At best. I meant regarding flexibility. Declaring a member private makes things also less flexible. The main difference is that private restricts visibility, It's not only not visible but neither accessible. And if something is not accessible, it affects flexibility. whilst sealed restricts extensibility. The former is usually a good thing, the latter not. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, 20 Oct 2009, Paul Ishenin wrote: Hello, FPC developers' list. I think we can close 'sealed/abstract class' page and open another interesting topc. It is obvious you are full of energy to discuss new language features. The next feature which we should think of is for-in loop: http://wiki.lazarus.freepascal.org/for-in_loop There you can find: 1. Delphi implementation details 2. Proposed extended syntax 3. Proposed compiler implementation While discussion please try to have delphi compatibility in the mind. At least one of the reasons we never did implement for-in is the absolutely horrible and totally wrong idea to use classes/interfaces for this, to which I seriously objected. The guy who thought of that should be shot, hanged, guillotined and poisoned. (you pick your order) It is a total negation of everything that pascal stands for: let a language feature (for in) depend on a user-class implementation. I can understand for y in enumerated do or For y in set do or For Y in range do Because this seems a natural extension of loops to enumerates (and even then) But not ever the class-based one. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
2009/10/20 Paul Ishenin i...@kmiac.ru: It is obvious you are full of energy to discuss new language features. :-) The next feature which we should think of is for-in loop: http://wiki.lazarus.freepascal.org/for-in_loop As an alternative to the very limited for-in, I have a better and more flexible design, using the Iterator design pattern. I have already written iterations for most of FPC's list components. It would be nice if the iterators could be part of the default list component and not as an external unit like I currently have. I'm willing to do the work in merging my external iterators with the various list components. Just say the word. It allows you to write code as follows, irrespective of what list component you are working with. MyIterator := MyList.GetIterator; while MyIterator.HasNext do ShowMessage(MyIterator.Next); The iterator interfaces has a lot more functions that just .HasNext and .Next. For example, I have a String Iterator that use regular expressions to filter the return results. So now you have the exact same code as above, but ShowMessage() will only act on the filtered return results. As you can see, a lot more flexible that the for-in construct. Additional methods that the iterator can support. Add(item) Inserts a specified item into the collection. (optional modifier operation) HasNext() Returns true if the collection has more items when traversing the collection in the forward direction. HasPrevious() Returns true if the collection has more items when traversing the collection in the reverse direction. Next() Returns the next item in the collection. Previous() Returns the previous item in the collection. Reset() Jump to the beginning of the collection, setting the cursor/index before the first item in the collection. The iterator is now in the same state as if you just created it. ToBack() Jump to the end off the collection, setting the cursor/index after the last item in the collection. This needs to be called before you want to traverse the collection in the reverse order. PeekNext() Returns the next item without moving the iterator's cursor/index. PeekPrevious() Returns the previous item without moving the iterator's cursor/index. Remove() Removes from the collection the last item that was returned by the Next() or Previous() calls. (optional modifier operation) SetItem(item) Replaces the last item returned by the Next() or Previous() calls with the specified item. (optional modifier operation) BTW: Java and .NET have such type of iterators on just about every list component and it's very handy (I can only comment here on Java implementation because I don't use .NET). I have written a article about this - in a lot more details. You can get a copy of the article at the following url: http://opensoft.homeip.net/articles/ -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, Oct 20, 2009 at 18:57, Graeme Geldenhuys graemeg.li...@gmail.com wrote: As an alternative to the very limited for-in, I have a better and more flexible design, using the Iterator design pattern. for-in is just a syntax sugar plus standard interface for the cost common usage of iterators. So they are not mutually exclusive at all. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, 20 Oct 2009, Graeme Geldenhuys wrote: 2009/10/20 Paul Ishenin i...@kmiac.ru: It is obvious you are full of energy to discuss new language features. :-) The next feature which we should think of is for-in loop: http://wiki.lazarus.freepascal.org/for-in_loop As an alternative to the very limited for-in, I have a better and more flexible design, using the Iterator design pattern. I have already written iterations for most of FPC's list components. It would be nice if the iterators could be part of the default list component and not as an external unit like I currently have. I'm willing to do the work in merging my external iterators with the various list components. Just say the word. It allows you to write code as follows, irrespective of what list component you are working with. MyIterator := MyList.GetIterator; while MyIterator.HasNext do ShowMessage(MyIterator.Next); The iterator interfaces has a lot more functions that just .HasNext and .Next. Exactly. I think that Graeme's approach is much better than the very unpascal-ish for Y in Someclass do and would much prefer this to be implemented in the RTL. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
2009/10/20 Alexander Klenin kle...@gmail.com: As an alternative to the very limited for-in, I have a better and more flexible design, using the Iterator design pattern. for-in is just a syntax sugar plus standard interface for the cost common usage of iterators. So they are not mutually exclusive at all. Well, with for-in you can only loop through a list is a specific order and direction. You can't peak forward, you can't move back, you can't filter returned content. So you, for-in is VERY LIMITED in my eyes, and a total waist of time. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
Florian Klaempfl wrote: Vinzent Höfler schrieb: Florian Klaempfl flor...@freepascal.org: Marco van de Voort schrieb: In our previous episode, Florian Klaempfl said: This is exactly my point about sealed classes. When you design the product or class, you have NO way of know what will come in the future. So you need to stay flexible to change! Yet another OOP principal that sealed tries to prevent! This might be true, but what's the difference with private etc.? Private is typically used in nearly every class, sealed in exceptional cases. At best. I meant regarding flexibility. Declaring a member private makes things also less flexible. The main difference is that private restricts visibility, It's not only not visible but neither accessible. And if something is not accessible, it affects flexibility. whilst sealed restricts extensibility. The former is usually a good thing, the latter not. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.422 / Virus Database: 270.14.22/2446 - Release Date: 10/19/09 14:33:00 There is a strange kind - from an academic point of view - of discussion going on here. - one part is confusing language syntax with compiler optimizations - another part is driven by not understanding why somebody invented sealed classes. The first is or maybe a side effect. The second should be understood to be restrictive on purpose, by design. I think a lot of people whom I highly regard are focussing in the wrong direction. Sealed has a purpose and a very good one: It prevents OO extensions by design, which is a good thing. see my example from two days ago. And, Marco, this is fully compliant with a true OOP philosofy ;) just my 2 c ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
2009/10/20 Alexander Klenin kle...@gmail.com: for-in is just a syntax sugar plus standard interface for the cost common usage of iterators. So they are not mutually exclusive at all. Another flaw in the for-in concept... What will this do: for y in MyList do begin if y = XXX then MyList.Add(YYY); if y = ZZZ then MyList.Insert(1, AAA); end; With my iterator implementation I can handle this with no problems, and ever make the resulting behaviour user-selectable with parameters to the MyList.GetIterator method. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, Oct 20, 2009 at 19:03, Graeme Geldenhuys graemeg.li...@gmail.com wrote: 2009/10/20 Alexander Klenin kle...@gmail.com: As an alternative to the very limited for-in, I have a better and more flexible design, using the Iterator design pattern. for-in is just a syntax sugar plus standard interface for the cost common usage of iterators. So they are not mutually exclusive at all. Well, with for-in you can only loop through a list is a specific order and direction. You can't peak forward, you can't move back, you can't filter returned content. So you, for-in is VERY LIMITED in my eyes, and a total waist of time. Well, I suggest you to read at least the link provided in the original post, and maybe also some documention about Delphi/C# enumerators. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Graeme Geldenhuys wrote: BTW: Java and .NET have such type of iterators on just about every list component and it's very handy (I can only comment here on Java implementation because I don't use .NET). Re .NET: Delphi Prism does have iterators. ( http://prismwiki.codegear.com/en/Iterators ) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
In our previous episode, Paul Ishenin said: It is obvious you are full of energy to discuss new language features. The next feature which we should think of is for-in loop: http://wiki.lazarus.freepascal.org/for-in_loop There you can find: 1. Delphi implementation details 2. Proposed extended syntax 3. Proposed compiler implementation While discussion please try to have delphi compatibility in the mind. I had a discussion with Marc W. about this on the last BBQ (Micha and Vincent might have been there too). IIRC we agreed that the set functionality is the most important by far, suggest to prioritize that btw the earlier discussions about D2005+ functionality are archived at: http://www.stack.nl/~marcov/delphilater.txt I wanted to use this for an article, so the log are sligtly processed and annotated. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
2009/10/20 Alexander Klenin kle...@gmail.com: Well, I suggest you to read at least the link provided in the original post, and maybe also some documention about Delphi/C# enumerators. I just read the docs in the lazarus wiki. The problems/limitations still hold true. For-in only goes in ONE direction and can't peak or filter returned results etc.. What good is an enumerator that only ever goes in one direction and visits all items. That's not a very flexible design. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
2009/10/20 Michael Schnell mschn...@lumino.de: Re .NET: Delphi Prism does have iterators. ( http://prismwiki.codegear.com/en/Iterators ) In all respects, Delphi Prism is not a Embarcadero product - except for the slapped on Delphi prefix, Embarcadero has nothing to do with Delphi Prism. But yes I know iterators exist in .NET, that's what I said in my previous post. Java .NET, but I have only every worked with the Java code. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Graeme Geldenhuys wrote: 2009/10/20 Alexander Klenin kle...@gmail.com: for-in is just a syntax sugar plus standard interface for the cost common usage of iterators. So they are not mutually exclusive at all. Another flaw in the for-in concept... What will this do: for y in MyList do begin if y = XXX then MyList.Add(YYY); if y = ZZZ then MyList.Insert(1, AAA); end; With my iterator implementation I can handle this with no problems, and ever make the resulting behaviour user-selectable with parameters to the MyList.GetIterator method. This is IMO similar to using a for loop vs. using a while loop. In a for loop you are not allowed to modify the loop variable. In this case I can imagine its not allowed to modify the list. If you want to, use a while and iterators. Yes I know iterators, I use them myself too on my own lists. As said I before, I think too that tose can be combined. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, Oct 20, 2009 at 19:22, Graeme Geldenhuys graemeg.li...@gmail.com wrote: 2009/10/20 Alexander Klenin kle...@gmail.com: Well, I suggest you to read at least the link provided in the original post, and maybe also some documention about Delphi/C# enumerators. I just read the docs in the lazarus wiki. The problems/limitations still hold true. For-in only goes in ONE direction Hm, did you read the about reverseEnumerators and various irders of tree traversals? and can't peak That is true, but this is required in maybe 1% of the cases, or even less. For these cases, certainly slightly longer while loop is justified. filter returned results etc.. Well, there is no such sample currently on the wiki, but it is still quite possible. What good is an enumerator that only ever goes in one direction and visits all items. That's not a very flexible design. Please read again with more attention ;-) -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
2009/10/20 Alexander Klenin kle...@gmail.com: I just read the docs in the lazarus wiki. The problems/limitations still hold true. For-in only goes in ONE direction Hm, did you read the about reverseEnumerators and various irders of tree traversals? --- // for basic type we will call only the apropriate function procedure TraverseString(S: String); var C: Char; begin for C in S using GetReverseStringEnumerator(S) do DoSomething(C); end; --- Now your for-in syntax changes because you want to use different enumerators. Why? It's not very elegant having to change your code, based on what you are iterating. That tells me it's not flexible enough. With the Iterators I wrote, you only have ONE interface you have to work with, no matter what type of list you are iterating or if the returned results are filtered or not. and can't peak That is true, but this is required in maybe 1% of the cases, or even less. For these cases, certainly slightly longer while loop is justified. Lets say you want to parse a UTF-8 string. Or you want to parse text for a documentation generator, or you want to strip text from an HTML file or Wiki page. All uses of where Peak is very often used. And that's just a short list of the top of my head. Please read again with more attention ;-) BTW: The wiki pages does not contain the word reverseEnumerators as you suggested earlier. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: And what is so special in the class type? First: For a for loop, you are guaranteed that the loop logic behaves correctly. A loop is equivalent to the following: I:=StartValue; E:=EndValue; While I=EndValue do begin // loop stuff Inc(I); end; And you cannot change I manually during the loop. You don't know this with an iterator since you depend on the implementation of the iterator. The loop could loop forever then... Yes. For-in loop is not a for-to loop. While and Repeat loops can also loop forever. You can't protect a developer if his hands grow from the wrong place. Secondly: You promote a certain class/interface to a language feature. The compiler then depends on the presence of a certain class with some 'known' methods in the RTL. Yes, I see this very bad too. That's why this discussion is started. But what can be suggested instead? Maybe new type? TSomeIterator = iterator(iterated type) ... end; or we can use some basic class: TIterator = class public function MoveNext: Boolean; property Current: what type to return? end; I don't like non-constructive criticism. If you don't like something please be ready to suggest something instead. And in this case something what can be used to implement for-in loop for classes and implements this delphi compatible (so 'for S in MyStringList do' will work). Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, Oct 20, 2009 at 19:40, Graeme Geldenhuys graemeg.li...@gmail.com wrote: // for basic type we will call only the apropriate function procedure TraverseString(S: String); var C: Char; begin for C in S using GetReverseStringEnumerator(S) do DoSomething(C); end; Now your for-in syntax changes because you want to use different enumerators. Why? It's not very elegant having to change your code, based on what you are iterating. That tells me it's not flexible enough. With the Iterators I wrote, you only have ONE interface you have to work with, no matter what type of list you are iterating or if the returned results are filtered or not. This is just one of the proposed syntax variants (and not the one I personally favor). Current Delphi iterators do it with the same syntax: for C in ReverseEnumerator(S) do DoSomething(C); and can't peak That is true, but this is required in maybe 1% of the cases, or even less. For these cases, certainly slightly longer while loop is justified. Lets say you want to parse a UTF-8 string. Or you want to parse text for a documentation generator, or you want to strip text from an HTML file or Wiki page. All uses of where Peak is very often used. And that's just a short list of the top of my head. Hm. I can not see where lookahead aka peeking is required in using any of the enumerators you mention. UTF8String enumerator is even among the samples on the wiki page. Please read again with more attention ;-) BTW: The wiki pages does not contain the word reverseEnumerators as you suggested earlier. My bad. I skipped space between words. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: On Tue, 20 Oct 2009, Paul Ishenin wrote: Michael Van Canneyt wrote: At least one of the reasons we never did implement for-in is the absolutely horrible and totally wrong idea to use classes/interfaces for this, to which I seriously objected. Reading this I conclude you are against 'for-in' implementation in fpc. No. I can understand for y in enumerated do or For y in set do or For Y in range do Because this seems a natural extension of loops to enumerates (and even then) But not ever the class-based one. So you are not against it but you want to allow them only for the base types? Yes. IMO too I hope you understand that ppl will use them for classes anyway? Those people should be re-educated to use iterators. Exactly. This all start to look a bit to much like the VB iterator magic. Where some under the hood functions (names) were used for iterating. If you didn't declare a container with the right function names you couldn't loop. var P: Pointer; begin for P in GetComponents(Component) do TComponent(P).DoSomething; end; And what is so special in the class type? First: For a for loop, you are guaranteed that the loop logic behaves correctly. A loop is equivalent to the following: I:=StartValue; E:=EndValue; While I=EndValue do begin // loop stuff Inc(I); end; And you cannot change I manually during the loop. You don't know this with an iterator since you depend on the implementation of the iterator. The loop could loop forever then... Secondly: You promote a certain class/interface to a language feature. The compiler then depends on the presence of a certain class with some 'known' methods in the RTL. Both points are simply wrong from a language point of view. Exactly. You extend a language construct with something defined with that language (i don't know how to explain better) It is bad enough that the second point is already so for interfaces and even TObject, (a very serious design flaw by Borland) but extending this even further to include actual language features such as the for loop is 2 bridges too far as far as I'm concerned. Especially when you can have perfectly the same functionality with iterators. I can see a use for using iterators in a for loop, however they should be declared with some keyword. Something like type TListIterator = iterator(TList, init_func, next_func, check_func) function init_func: Boolean; function next_func: element type function check_func: Boolean; end; begin for element in list using TListIterator do... IMO this is more pascal than using some interface or predefined function names. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, 20 Oct 2009, Paul Ishenin wrote: Michael Van Canneyt wrote: And what is so special in the class type? First: For a for loop, you are guaranteed that the loop logic behaves correctly. A loop is equivalent to the following: I:=StartValue; E:=EndValue; While I=EndValue do begin // loop stuff Inc(I); end; And you cannot change I manually during the loop. You don't know this with an iterator since you depend on the implementation of the iterator. The loop could loop forever then... Yes. For-in loop is not a for-to loop. While and Repeat loops can also loop forever. You can't protect a developer if his hands grow from the wrong place. Secondly: You promote a certain class/interface to a language feature. The compiler then depends on the presence of a certain class with some 'known' methods in the RTL. Yes, I see this very bad too. That's why this discussion is started. But what can be suggested instead? IMHO nothing. Maybe marc's proposal. Maybe new type? TSomeIterator = iterator(iterated type) ... end; or we can use some basic class: TIterator = class public function MoveNext: Boolean; property Current: what type to return? end; This is the same as what Borland does: you promote a certain class to a language feature... I don't like non-constructive criticism. If you don't like something please be ready to suggest something instead. And in this case something what can be used to implement for-in loop for classes and implements this delphi compatible (so 'for S in MyStringList do' will work). I did suggest something instead: implement iterators in the classes unit, as Graeme suggests. Yes, I know this is not Delphi compatible. But I'm OK with that. I think the importance and gain of the for in loop is far too small to spend time on it, since there are plenty of alternatives possible today. Of course, if you want to be 100% delphi compatible, then there is simply no way we can ever agree on this particular feature, no matter how constructive I am or you are. So then, in the end, someone will have to back down and put aside his wishes :-) But I really don't see the advantage of being able to type For F in Someclass.Iterator do F.Something over While SomeClass.HaveValue do SomeClasss.NextValue.Something; It's not clearer, at most it saves you a couple of keystrokes. Raping a clean language for this is simply not correct. It's not because Borland - in its desire to make money - implemented every idiots' request, that we should do the same. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, Oct 20, 2009 at 19:34, Michael Van Canneyt mich...@freepascal.org wrote: You don't know this with an iterator since you depend on the implementation of the iterator. The loop could loop forever then... Just as it can when using iterators explicitly. No difference here. Secondly: You promote a certain class/interface to a language feature. The compiler then depends on the presence of a certain class with some 'known' methods in the RTL. Both points are simply wrong from a language point of view. It is bad enough that the second point is already so for interfaces and even TObject, (a very serious design flaw by Borland) but extending this even further to include actual language features such as the for loop is 2 bridges too far as far as I'm concerned. Well, for better or worse, tight integration of language and RTL is an intrinsic feature of Pascal language since it's inception. Just look at the original spec: Write, Writeln, Read, Readln, Pred, Succ, Reset -- almost all standard functions are magic! Borland just continued the tradition started by Wirth. Now that is so ingrained in ObjectPascal that there is no point in resisting: arrays/SetLength, RTTI/GetXXXProp, the whole TObject, string/Copy, the list goes on... Almost every feature in modern Pascal is broken this sense. Still, this might not be such a bad thing -- see C++/STL for the opposite method driven to it's logical conclusion. So I guess a measured dose of language/RTL integration is actually good. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, 20 Oct 2009, Alexander Klenin wrote: On Tue, Oct 20, 2009 at 19:34, Michael Van Canneyt mich...@freepascal.org wrote: You don't know this with an iterator since you depend on the implementation of the iterator. The loop could loop forever then... Just as it can when using iterators explicitly. No difference here. The difference is that the language guarantees that the for loop will run OK. It makes no such guarantees with a while or repeat loop. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
In our previous episode, dmitry boyarintsev said: specially for minor features is more trouble then it is worth, since eventually the Delphi syntax will have to be supported anyway. Agreed, and that's quite sad, eventual Delphi syntax support makes FreePascal actually FreeDelphi. I don't measure FPC's identity on basis of the dialect alone. That is only a carte blanche for unbridled extensions. About FPC syntax and new feature: fpc packages (afaik not yet implemented). I'm wondering, what syntax would be used to define an external class. Would it follow obj-p (objc branch) style? (adding 'external' keyword after class declaration). Packages don't have external classes. A package is fully transparent to the program, IOW when linking to a package there are proper .ppu's and everything, and there is no external link step. See http://wiki.freepascal.org/packages for some explanation. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt schrieb: Secondly: You promote a certain class/interface to a language feature. The compiler then depends on the presence of a certain class with some 'known' methods in the RTL. The whole interface ref. counting depends on that as well as e.g. the as operator. My opinion about the for-in loop: - I won't implement it - if somebody else implements it in a delphi compatible manner: fine - if somebody else implements it in a delphi compatible manner solving the flaws: great - if somebody else has ideas how the existing classes can be extended without drawbacks by more sophisticated iterators, go ahead, this won't interfere with Paul's stuff ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, Oct 20, 2009 at 20:09, Michael Van Canneyt mich...@freepascal.org wrote: But I really don't see the advantage of being able to type For F in Someclass.Iterator do F.Something over While SomeClass.HaveValue do SomeClasss.NextValue.Something; It's not clearer, at most it saves you a couple of keystrokes. This is because the while you provided is not equivalent to the for loop above. The correct translation would be: var it: TSomethingIterator; ... it := SomeClass.Iterator; try while it.HaveValue do it.NextValue.Something; finally it.Free; end; Now, that is quite e few keystrokes to save, not to mention that if item value is used more than once in the loop, SomeClass.NextValue must be stored in a variable, further bloating code. Borland - in its desire to make money - implemented every idiots' request, that we should do the same. Well, I have the same attitude regarding sealed classes ;-) However, for..in is not like those. Let me provide a few over-generalized statements in support of for..in feature. 1) Convenient syntax matters -- otherwise we would be programming in C 2) Language level matters -- otherwise we would be programming in assembler language 3) for..in is both a convenient syntax and a very important high-level feature. It is actually more fundamental and important than for..to loop, and it is only a matter of weak compiler implementations that for..to loop was introduced first. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
Florian Klaempfl flor...@freepascal.org: It's not only not visible but neither accessible. For good reasons, usually. Either there's a way to access it (properties) or it really is an implementation detail that might change. And if something is not accessible, it affects flexibility. Yes. [That's one reason why C is so flexible, it doesn't have all this visibility shit... ;)] The feature is called information hiding. The times of every identifier is global are over, I suppose? Let me put it this way: private can be misused sometimes. sealed will be misused most of the times. The use-cases for sealed given so far were quite debatable, I think. Vinzent. -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
On Tue, Oct 20, 2009 at 1:22 PM, Marco van de Voort mar...@stack.nl wrote: Packages don't have external classes. A package is fully transparent to the program, IOW when linking to a package there are proper .ppu's and everything, and there is no external link step. So it would be like using delphi's dcu (without .pas files). Some class/vars/consts/functions are avaiable and declared in package file, but the only they to see a full declaration is via documention, rather than header-sources. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On 20/10/2009, Alexander Klenin kle...@gmail.com wrote: Hm. I can not see where lookahead aka peeking is required in using any of the enumerators you mention. UTF8String enumerator is even among the samples on the wiki page. I just completed a parser for a custom RichText component I wrote for fpGUI Toolkit. This will probably apply to HTML, XML etc as well. Say you have the following string Hello bWorld/b!: When I parse that and I get the the characters, I peak ahead to see if I am working with a actual styling tag, or if I am working with the actual character in the contents. So when I tokenize that string, with the help of peak ahead I know what token type to set. Please read again with more attention ;-) BTW: The wiki pages does not contain the word reverseEnumerators as you suggested earlier. My bad. I skipped space between words. Please pay more attention to the wiki article! :-) Neither reverse Enumerators nor reverseEnumerators are text in the for-in loop wiki page. At least that is what Firefox tells me when I do a Find. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, 20 Oct 2009, Florian Klaempfl wrote: Michael Van Canneyt schrieb: Secondly: You promote a certain class/interface to a language feature. The compiler then depends on the presence of a certain class with some 'known' methods in the RTL. The whole interface ref. counting depends on that as well as e.g. the as operator. I know, I said this also in my remark that they did this already for some interfaces (ref counting) and TObject... My opinion about the for-in loop: - I won't implement it - if somebody else implements it in a delphi compatible manner: fine - if somebody else implements it in a delphi compatible manner solving the flaws: great - if somebody else has ideas how the existing classes can be extended without drawbacks by more sophisticated iterators, go ahead, this won't interfere with Paul's stuff If the largest part of the compiler team has no problem with it, I will of course not refuse it. Although I would definitely request to allow the delphi-compatible solution only Delphi mode, and only to allow a *decent* implementation in ObjFPC mode. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Tue, Oct 20, 2009 at 20:29, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On 20/10/2009, Alexander Klenin kle...@gmail.com wrote: Hm. I can not see where lookahead aka peeking is required in using any of the enumerators you mention. UTF8String enumerator is even among the samples on the wiki page. I just completed a parser for a custom RichText component I wrote for fpGUI Toolkit. This will probably apply to HTML, XML etc as well. Say you have the following string Hello bWorld/b!: When I parse that and I get the the characters, I peak ahead to see if I am working with a actual styling tag, or if I am working with the actual character in the contents. So when I tokenize that string, with the help of peak ahead I know what token type to set. The iterator itself have to look ahead, yes, but this should be hidden from the caller -- i.e. the user of HTMLIterator have no need to know that the iterators looks ahead. Please pay more attention to the wiki article! :-) Neither reverse Enumerators nor reverseEnumerators are text in the for-in loop wiki page. At least that is what Firefox tells me when I do a Find. Ok, ok, I did not mean to search a literal string, just the topic. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Graeme Geldenhuys graemeg.li...@gmail.com: Well, with for-in you can only loop through a list is a specific order and direction. You can't peak forward, you can't move back, you can't filter returned content. At least you know it will terminate. That always was a guaranteed property of the for-loop. With being able to move back and forth as some iterator wishes, this property will be gone forever. Iterators:Good idea. Using for-loops for that: Bad idea. for-loops are for static things, be it enumerations, sets, or ranges. I would vote for that, but not for (disguised) iterators in for-loops. Those are more suited for while-loops. Vinzent. -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
In our previous episode, Paul Ishenin said: Yes, I see this very bad too. That's why this discussion is started. But what can be suggested instead? Does there need something to be suggested per se? What do you think of the DECAL solution ? It's ackward, but that is because it is pre-generics, and I think generics would solve many of the problems. I don't like non-constructive criticism. If you don't like something please be ready to suggest something instead. And in this case something what can be used to implement for-in loop for classes and implements this delphi compatible (so 'for S in MyStringList do' will work). I don't like for-in, but if sb wants to waste time on it, better do it Delphi compat. I don't see the need for anything else, and if people see it, it would be nice to hear what they think of the decal principle (but then fixed with generics) The Prism solution might be overly costly since it depends on a continuation concept. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On 20/10/2009, Paul Ishenin i...@kmiac.ru wrote: I don't like non-constructive criticism. If you don't like something please be ready to suggest something instead. And in this case something what can By no means to I suggest that my code should be the final product, but here I am attaching what I wrote for the Iterator article I previously mentioned. Please read the accompanied article as to why I did what I did. Due to the iterators not being part of the internal list classes and because I did not what to create descendant list classes for everything, I followed the following approach. I have used a Factory method to determine which Iterator should be returned, based on the class type in question. I have also not implement all suggested iterator interface methods - only a select few are currently implement. I also followed the Java iterator principle (different from Microsoft's idea) that the iterator pointer points between elements and NOT at elements. This make a lot more sense to me when you start the iteration (currently pointing at nothing because the list could be empty) and when you do things like inserting elements. Please see attached code. Note: If iterators get integrated with all list classes, then the factor method could disappear and a few other stuff could be simplified. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ iterator_source.tar.gz Description: GNU Zip compressed data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Marc Weustink marc.weust...@cuperus.nl: Graeme Geldenhuys wrote: Another flaw in the for-in concept... What will this do: for y in MyList do begin if y = XXX then MyList.Add(YYY); if y = ZZZ then MyList.Insert(1, AAA); end; [...] This is IMO similar to using a for loop vs. using a while loop. In a for loop you are not allowed to modify the loop variable. In this case I can imagine its not allowed to modify the list. But how's the compiler supposed to know which method modifies MyList and which one does not? Disallowing all calls to the methods of MyList doesn't seem a proper solution, if you're not allowed to do that what is the sense of iterating through it? Another option: Raise an exception if the code detects that the list changed during the loop? Can it be guaranteed that a changed list is detected (usually the answer is: No). At what run-time costs can it be detected at all? Etc. pp. There seems more to that than just syntactic sugar. Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Graeme Geldenhuys wrote: In all respects, Delphi Prism is not a Embarcadero product - except for the slapped on Delphi prefix, Embarcadero has nothing to do with Delphi Prism. They do sell it, so I suppose if they plan language extension (like iterators) for the native Delphi flavor, they will do it along the lines of Prism. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On 20/10/2009, Michael Schnell mschn...@lumino.de wrote: They do sell it, As a curtsey because they gave up on Delphi.NET. RemObjects are now in control of Delphi Prism. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Graeme Geldenhuys wrote: RemObjects are now in control of Delphi Prism. No wonder, as they created it :) I understand that Codegear or Embarcadero pay(ed) them for the license to sell it. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
In our previous episode, dmitry boyarintsev said: Packages don't have external classes. ?A package is fully transparent to the program, IOW when linking to a package there are proper .ppu's and everything, and there is no external link step. So it would be like using delphi's dcu (without .pas files). Yes. Linking to such units is not fundamentally different from linking to other precompiled code. But on Delphi this is in .dcp packages. (since packages can also have static parts) Some class/vars/consts/functions are avaiable and declared in package file, but the only they to see a full declaration is via documention, rather than header-sources. I don't understand this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Vinzent Höfler wrote: Marc Weustink marc.weust...@cuperus.nl: loop you are not allowed to modify the loop variable. In this case I can imagine its not allowed to modify the list. But how's the compiler supposed to know which method modifies MyList and which one does not? That's why I suggested the use of 'const functions' in other message in this thread. IIRC they are also part of C++; const functions are functions that never do an assignment (directly or indirectly) to a member field. Regards, Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
On Tue, Oct 20, 2009 at 11:26 AM, Marco van de Voort mar...@stack.nl wrote: Some class/vars/consts/functions are avaiable and declared in package file, but the only they to see a full declaration is via documention, rather than header-sources. I don't understand this. Delphi can compile a project with dcu present, but no .pas files. Any type or routine present in dcu can be used. The only problem of using them, is that there's no information in human-readable form about what actually presents in dcu. Most of commercial components use this strategy: They do not provide sources, but they provide compiled .dcus (for any delphi version). With .dcu files they provide documentation over the component, so the user can see what classes, methods, functions or types are available, without need of studying sources. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
dmitry boyarintsev wrote: Delphi can compile a project with dcu present, but no .pas files. ... Can the mail topic be changed for the unrelated thread? I still expect a new dose of criticism in every mail with the current topic. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class constants
On 19 Oct 2009, at 19:19, Alexander Klenin wrote: On Tue, Oct 20, 2009 at 01:12, Jonas Maebe jonas.ma...@elis.ugent.be wrote: Except if you want to use the constant in another constant expression (which is not possible with a function, inlined or not). Which, by the way, is another limitation that would be good to lift: No, this would cause completely unpredictable behaviour regarding whether or not a function can be used inside a const statement (since the compiler will never contain a full emulator that is able to interpret any arbitrary Pascal function). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
On Tue, Oct 20, 2009 at 12:03 PM, Paul Ishenin webpi...@mail.ru wrote: Can the mail topic be changed for the unrelated thread? I still expect a new dose of criticism in every mail with the current topic. You're right, i've been hijacking the thread to a wrong subject. Sorry, won't happen again. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
In our previous episode, dmitry boyarintsev said: file, but the only they to see a full declaration is via documention, rather than header-sources. I don't understand this. Delphi can compile a project with dcu present, but no .pas files. Any type or routine present in dcu can be used. The only problem of using them, is that there's no information in human-readable form about what actually presents in dcu. FPC also, but has .ppu/.o. (but harder to manage not giving source due a multitude of questions. But that is not related to the external question. The point is that the .ppu have a defined state of a compilation step, with all the information needed for the COMPILER. This is different from linking to C/Obj C or other external sources where you only have binary state after compiling the first part, enough for the LINKER. Most of commercial components use this strategy: They do not provide sources, but they provide compiled .dcus (for any delphi version). With .dcu files they provide documentation over the component, so the user can see what classes, methods, functions or types are available, without need of studying sources. No. .dcu is not a documentation format. The information is primarily for the compiler, and .ppu contains the complete state needed for the compiler to use that unit from another unit/prgram. Rougly Delphi .dcu folds in the actual object code (.o) together with the unit info (.ppu) into one file ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Marc Weustink wrote: It is bad enough that the second point is already so for interfaces and even TObject, (a very serious design flaw by Borland) but extending this even further to include actual language features such as the for loop is 2 bridges too far as far as I'm concerned. Especially when you can have perfectly the same functionality with iterators. I can see a use for using iterators in a for loop, however they should be declared with some keyword. Something like type TListIterator = iterator(TList, init_func, next_func, check_func) function init_func: Boolean; function next_func: element type function check_func: Boolean; end; begin for element in list using TListIterator do... IMO this is more pascal than using some interface or predefined function names. +1 using seems far better than a fixed name GetIterator procedure. IMHO the other option is to implement the feature for ase types (e.g. enum, array, maybe string) and allow operator overriding for all other types. Then you can specify an enum operator for classes, or even for simple/scalar types like integer, and define your for..in behaviour for them. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Marc Weustink wrote: I can see a use for using iterators in a for loop, however they should be declared with some keyword. Something like type TListIterator = iterator(TList, init_func, next_func, check_func) function init_func: Boolean; function next_func: element type function check_func: Boolean; end; begin for element in list using TListIterator do... IMO this is more pascal than using some interface or predefined function names. Good idea. What is iterator internally? Is this an object with the special header? Is it internall the same as: TListIterator = object function init_func(AList: TList): Boolean; function next_func: Pointer; function check_func: Boolean; end; Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Martin wrote: using seems far better than a fixed name GetIterator procedure. IMHO the other option is to implement the feature for ase types (e.g. enum, array, maybe string) and allow operator overriding for all other types. Then you can specify an enum operator for classes, or even for simple/scalar types like integer, and define your for..in behaviour for them. Yes, 'using' and 'operator GetEnumerator' are suggested in the wiki page here: http://wiki.lazarus.freepascal.org/for-in_loop#Proposed_extensions So at least here we are thinking the same :) The big problem question is what is enumerator : a) A new type very like to a specially defined object. If so then will we allow it usage outside for-in loop? b) A class with one magic method and one magic property c) something else Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Question about PDF PS documentation layout
Hi, In the PS or PDF versions of the RTL documentation, and then the reference information about the 'SysUtils' unit. In my docs it's chapter 37. The sysutils unit has related topics like the Date and Time formatting characters. I noticed that those related topics appear before the Used units and Overview sections. Is this correct? Shouldn't the Used units and Overview be first and then related topics following? I'm basing the IPF output on the structure of the PDF documents, and just want to be sure which order is preferred for the extra related topics In the HTML output the Uses units and unit Overview comes first, then the listing of related topics. And the PDF document is other way round... http://www.freepascal.org/docs-html/rtl/sysutils/index.html As far as I can see, the HTML output makes a bit more sense than the PDF ordering. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] New feature discussion: LAMBDA
Hi Based on discussion about for in I want to suggest my proposition. When we investigate some code, sometimes we found pattern: Pattern 1: / begin startfun; try ... finally stopfun; end; / end; Pattern 2: for i:= startfun to stopfun do begin end; Pattern 3: startfun; while stopfun do begin ... end; Common for all mentioned patterns are two connected functions, which controlled running of body source. First make all initializations, second helping with iterations and finalizations. My proposition is make possibility of join, those pair to one sentence. All patterns can be change to one common template: if startfun then repeat until stopfun; I You see we need two function with boolean result. Of course possibility of parameters give wide appliance. To preserve pascalish style I propose something like this: tMyObject = class(tObject) function startfun:boolean; function stopfun:boolean; property lambdafun; start startfun stop stopfun; end; and invoke: var t : tMyObject; begin .. t.lambdafun do begin end; end; because on declaration side is similar do properties (also two function) we can use the same syntax. Only keyword start and stop exchange read and write. To using i thought about WITH, but it may confusing bit, thus I propose omit, and only use keyword DO. Why lambda. Because is very similar to constructing no name procedures and use them as normal. We have few mechanism controlling runnig: IF, REPEAT, WHILE, FOR. They work well, but sometimes they are week. For example we don't have enough primitives do build own implementation FORIN method, on iterators also. But in Lisp any mechanism, any sequence of computing collection can be done and source is very readable lisp syntax: (lambda (formal parameters) body) This is not unusual, but we can send this declaration as argument of procedure. Of course syntax like this tlist.foreach( procedure (x : tObject);begin writeln(x) end) is ugly (thought I sow something similar in C++/boost) but when we change it a bit: tlist.foreach(x) do begin writeln(x); end; its not so strange Because my english is very poor I only show some application EXP. mutex (and patterns as RIAA) tMutex = class property makeatomic; start lock stop unlock; end; . begin tMutex.makeatomic do begin ... end; end; EXP: foreach tMyList = class function tMyList.start:boolean; begin current:=first; result:=currentnil; end; function tMyList.stop:boolean; begin current:=next(current); resutl:=currentnil; end; When attributes are added, or exception caching this will be more flexible. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Paul Ishenin пишет: Marc Weustink wrote: I can see a use for using iterators in a for loop, however they should be declared with some keyword. Something like type TListIterator = iterator(TList, init_func, next_func, check_func) function init_func: Boolean; function next_func: element type function check_func: Boolean; end; begin for element in list using TListIterator do... IMO this is more pascal than using some interface or predefined function names. Good idea. What is iterator internally? Is this an object with the special header? Is it internall the same as: TListIterator = object function init_func(AList: TList): Boolean; function next_func: Pointer; function check_func: Boolean; end; Don't comlicate it more than necessary: 1) An object (or record with methods, provided you implement it first :-) is preferable over class, since using it can help avoiding construction/destruction, memory allocations, and implicit try..finally. 2) Using objects/records also enables you to use operators to encode the iterator. This isn't possible for classes. 3) next_func and check_func above can be coalesced to a single function next(out obj: TItem): Boolean; 4) The syntax 'for element in list using TListIterator' is kind of redundant. I'd suggest: for element in list.GetForwardIterator do ..., or even for element in list.GetSubItems(arguments) do ... Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question about PDF PS documentation layout
On Tue, 20 Oct 2009, Graeme Geldenhuys wrote: Hi, In the PS or PDF versions of the RTL documentation, and then the reference information about the 'SysUtils' unit. In my docs it's chapter 37. The sysutils unit has related topics like the Date and Time formatting characters. I noticed that those related topics appear before the Used units and Overview sections. Is this correct? Shouldn't the Used units and Overview be first and then related topics following? I'm basing the IPF output on the structure of the PDF documents, and just want to be sure which order is preferred for the extra related topics In the HTML output the Uses units and unit Overview comes first, then the listing of related topics. And the PDF document is other way round... http://www.freepascal.org/docs-html/rtl/sysutils/index.html As far as I can see, the HTML output makes a bit more sense than the PDF ordering. It can be easily changed. I personally have no preference. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Again something inspired by Delphi-Prism ? ( http://prismwiki.codegear.com/en/Lambda_Expressions ) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Michael Schnell pisze:
Again something inspired by Delphi-Prism ?
( http://prismwiki.codegear.com/en/Lambda_Expressions )
No at all, I don't even see this before. I thing long about this. But
lately I see this in C++ (strange) and Lisp (beautiful)
In Prism have You:
c - c.Name = 'Smith'
which is very strange, special syntax, and need to be translate to method, and declaration longer
than one line is awful,
my proposition semantically is between properties (they consist also two function),
aspect programming and lambda
is very easy to translate to ordinal pascal( lambda invoke change to
repeat-while iteration,
similarly as in generics)
has wider application:
from FPC WIKI:
procedure StringLoop(S: String);
var
C: Char;
begin
for C in S do
DoSomething(C);
end;
my prop:
procedure stringloop(s :tMyString);
begin
{with} s.eachword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
end;
of course I can write
procedure stringloop(s :tMyString);
begin
s.firstWord;
try
while s.nexword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
except
s.exceptWord;
end;
end;
which can be equivalent
from compiler side invoke of lambda is translate to proper iteration before
main compilation
from developer side: its easy to use as properties,
fewer bugs caused forget of initialization or finalization, or use incompatible init and step
function in iterators
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Michael Schnell wrote: Again something inspired by Delphi-Prism ? ( http://prismwiki.codegear.com/en/Lambda_Expressions ) Wow, talk about unreadable code... I'm all for saving typing, but not at the expense of readability. This reminds me of C's oddball ? operator. One of the reasons I like Pascal is that you do usually have to spell out what you are doing. It makes reading the code months or years later, or reading someone else's code much easier. So it might not be the most efficient in terms of typing, or even compilation or execution, but the savings in maintenance more than make up for it. The examples given at that site would drive me crazy. I don't believe I'll be using Prism any time soon. Jeff. -- I haven't smoked for 3 years, 2 months and 3 days, saving $5,222.69 and not smoking 34,817.99 cigarettes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Pascal have something close to lambda, and it's nested functions/procedures
The original idea of lambda is to have sub process that takes parameters and
simple tasks.
For example (in Ruby):
def action(base)
expo = lambda { |by_num| base ** by_num}
x = something
a = expo(x)
end
I can do the same with the following:
procedure action(base : integer)
function expo(by_num)
begin
expo := base ** by_num
end;
var x,a : integer;
begin
x := something;
a := expo(x);
...
end;
Of curse it's one usage for it, but most of the real usage of lambda can be
made in pascal today. And please do not take ideas from C++, it's a language
that wrote on it's agenda to implement any possible technology out there
regardless of it's need or usage, and it's impossible to use that language
without some framework or ignoring this technologies.
Ido
http://ik.homelinux.org/
2009/10/20 Dariusz Mazur dar...@emadar.com
Michael Schnell pisze:
Again something inspired by Delphi-Prism ?
( http://prismwiki.codegear.com/en/Lambda_Expressions )
No at all, I don't even see this before. I thing long about this. But
lately I see this in C++ (strange) and Lisp (beautiful)
In Prism have You:
c - c.Name = 'Smith'
which is very strange, special syntax, and need to be translate to
method, and declaration longer than one line is awful,
my proposition semantically is between properties (they consist also two
function), aspect programming and lambda
is very easy to translate to ordinal pascal( lambda invoke change to
repeat-while iteration,
similarly as in generics)
has wider application:
from FPC WIKI:
procedure StringLoop(S: String);
var
C: Char;
begin
for C in S do
DoSomething(C);
end;
my prop:
procedure stringloop(s :tMyString);
begin
{with} s.eachword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
end;
of course I can write
procedure stringloop(s :tMyString);
begin
s.firstWord;
try
while s.nexword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
except
s.exceptWord;
end; end;
which can be equivalent
from compiler side invoke of lambda is translate to proper iteration before
main compilation
from developer side: its easy to use as properties, fewer bugs caused
forget of initialization or finalization, or use incompatible init and step
function in iterators
--
Darek
___
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
Re: [fpc-devel] New feature discussion: LAMBDA
In our previous episode, Jeff Wormsley said: ( http://prismwiki.codegear.com/en/Lambda_Expressions ) Wow, talk about unreadable code... I'm all for saving typing, but not at the expense of readability. This reminds me of C's oddball ? operator. (hmm, if I would name one feature I hate about C, that would be that if (x=y) goes unnoticed while legal. At least the ? operator doesn't bite you if you don't use it) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Marco van de Voort schreef: (hmm, if I would name one feature I hate about C, that would be that if (x=y) goes unnoticed while legal. At least the ? operator doesn't bite you if you don't use it) Off topic. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
2009/10/20 Jeff Wormsley dawor...@comcast.net: ( http://prismwiki.codegear.com/en/Lambda_Expressions ) Wow, talk about unreadable code... +1 That's all I can say. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
ik pisze:
Pascal have something close to lambda, and it's nested
functions/procedures
The original idea of lambda is to have sub process that takes
parameters and simple tasks.
You don't understand me. I know sub process, this is nice feature of
pascal, but i talk about something different.
Sometimes we have sub process and want to do with them rather
complicated task.
For example (in Ruby):
def action(base)
expo = lambda { |by_num| base ** by_num}
x = something
a = expo(x)
end
I can do the same with the following:
procedure action(base : integer)
function expo(by_num)
begin
expo := base ** by_num
end;
var x,a : integer;
begin
x := something;
a := expo(x);
...
end;
My example was different. Try to implement my example with the same
readability, error prove,
Of curse it's one usage for it, but most of the real usage of lambda
can be made in pascal today. And please do not take ideas from C++,
it's a language that wrote on it's agenda to implement any possible
technology out there regardless of it's need or usage, and it's
impossible to use that language without some framework or ignoring
this technologies.
I don't draw from C++, which is imperative language , rather try to use
some of the best of functional language.
I don't even know, that it should be name lambda. Its similar to
iterators, but also to aspect. It has the same syntax as properties.
thats all.
2009/10/20 Dariusz Mazur dar...@emadar.com mailto:dar...@emadar.com
Michael Schnell pisze:
Again something inspired by Delphi-Prism ?
( http://prismwiki.codegear.com/en/Lambda_Expressions )
No at all, I don't even see this before. I thing long about this.
But lately I see this in C++ (strange) and Lisp (beautiful)
In Prism have You:
c - c.Name = 'Smith'
which is very strange, special syntax, and need to be translate to
method, and declaration longer than one line is awful,
my proposition semantically is between properties (they consist
also two function), aspect programming and lambda
is very easy to translate to ordinal pascal( lambda invoke change
to repeat-while iteration,
similarly as in generics)
has wider application:
from FPC WIKI:
procedure StringLoop(S: String);
var
C: Char;
begin
for C in S do
DoSomething(C);
end;
my prop:
procedure stringloop(s :tMyString);
begin
{with} s.eachword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
end;
of course I can write
procedure stringloop(s :tMyString);
begin
s.firstWord;
try
while s.nexword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
except
s.exceptWord;
end; end;
which can be equivalent
from compiler side invoke of lambda is translate to proper
iteration before main compilation
from developer side: its easy to use as properties, fewer bugs
caused forget of initialization or finalization, or use
incompatible init and step
function in iterators
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Original-Nachricht Datum: Tue, 20 Oct 2009 13:38:40 +0200 Von: Micha Nelissen mi...@neli.hopto.org An: FPC developers\' list fpc-devel@lists.freepascal.org Betreff: Re: [fpc-devel] New feature discussion: for-in loop Vinzent Höfler wrote: Marc Weustink marc.weust...@cuperus.nl: loop you are not allowed to modify the loop variable. In this case I can imagine its not allowed to modify the list. But how's the compiler supposed to know which method modifies MyList and which one does not? That's why I suggested the use of 'const functions' in other message in this thread. Yes, I read that later on. Is that implemented in FPC? Actually I read of that feature the first time, but I like it already. ;) In that case this part of my argument may be ignored, of course. OTOH I've never stumbled upon source code using it, so it may seem not widespread enough yet to be useable (basic iterable classes like TList spring to mind)...? (Currently, I'm reading my mails online, so I answer one at a time at the risk of repeating somebody else's argument. Sorry if that causes inconviniences.) Vinzent. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Vinzent Höfler пишет: Sergei Gorelkin sergei_gorel...@mail.ru: 4) The syntax 'for element in list using TListIterator' is kind of redundant. I'd suggest: for element in list.GetForwardIterator do ..., or even for element in list.GetSubItems(arguments) do ... Wat's the return type of those functions? TIterator? Probably yes. A possibility to use any type which has certain methods/operators instead looks attractive, but I'm afraid it would be hard to fit that into existing compiler model. Sergei. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Sergei Gorelkin wrote: Probably yes. A possibility to use any type which has certain methods/operators instead looks attractive, but I'm afraid it would be hard to fit that into existing compiler model. Sorry, what is TIterator? Is this like to the previosly suggested TIterator = interator(Type, MoveNext, Current) end; Btw, we can use some new 'enumerator'/'iterator' directive to mark methods which return enumerators. And only in delphi mode we will search for the GetEnumerator method. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Marco van de Voort wrote: btw the earlier discussions about D2005+ functionality are archived at: http://www.stack.nl/~marcov/delphilater.txt I wanted to use this for an article, so the log are sligtly processed and annotated. There is no much threre regards 'for-in'. I would like if you/somebody else improve the current wiki 'for-in' article with your/somebody else ideas. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Paul Ishenin wrote: Sergei Gorelkin wrote: Probably yes. A possibility to use any type which has certain methods/operators instead looks attractive, but I'm afraid it would be hard to fit that into existing compiler model. Sorry, what is TIterator? Is this like to the previosly suggested TIterator = interator(Type, MoveNext, Current) end; I did not try to specify what exactly TIterator is. What I tried to say is: some type that is already known at the point of parsing the for..in. Btw, we can use some new 'enumerator'/'iterator' directive to mark methods which return enumerators. And only in delphi mode we will search for the GetEnumerator method. The question is, what advantage all this specific syntax could give over simple searching the methods by name? Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Sergei Gorelkin wrote: The question is, what advantage all this specific syntax could give over simple searching the methods by name? Some people need less compiler magic, some does not care. New directive can reduce the magic level :) Btw, we use similar compiler magic every day. Just think of: 1. functions which all have special 'Result' variable :) 2. message methods which calls 'TObject.DefaultHandler' when you call inherited inside. 3. tobject methods related to interfaces I suspect there are more examples. In all the listed examples compiler searches for the special identifier. Therefore GetEnumerator identifier looks as very native solution for pascal. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Paul Ishenin wrote: Marco van de Voort wrote: btw the earlier discussions about D2005+ functionality are archived at: http://www.stack.nl/~marcov/delphilater.txt I wanted to use this for an article, so the log are sligtly processed and annotated. There is no much threre regards 'for-in'. I would like if you/somebody else improve the current wiki 'for-in' article with your/somebody else ideas. The more I think about the more headaches it causes. Now I agree it needs to be done for delphi mode If you do it for objpas/fpc mode it starts the question how far? Let's start with the simpliest for-in, and add each next step, and someone please tell me how far for-in shopuld go... - for in for ranges [1..10], sets and enum types - for arrays - for strings - for any object via iterator - with reverse iteration... = Now reverse iteration can be done by a different iterator class, - with filtered iteration... = what if you want to iterate through all entries of a list (stringlist) that have length(entry) 10 ? To do that (and specify differnt filters) you need to instantiate the iterator yourself, and set the values for the filter condition. But if you pass an instantiated iterator to for-in = should it still auto destroy it? And if not, you are back to while (iterator) I don't think the last one is really desired... but where to draw the line? Except for the last one: does iterator have to be a class or object at all? I hadn't had time to think it all through = so I just throw some half finish thoughts in... maybe It could be done as an overloaded operator = a function with an additional var-param that is used for the state operator ITR = function IterateFoo(FooValue: TFooType; ItrState: Pointer; out ItrNoMoreValues: Boolean): FooEntryType for-in would call it the first time with a nil for ItrState = the function can then store a number, or create a StateObject, or whatever to remember it;s position. For all other calls to the function, the param would be passed back in, as it was set on the previous call. Just as if it was a local variable in the calling code) - It has a serious flaw in this version = if the loop is aborted early break, then there is no way to tell the iterator. If it was an object then it would just get destroyed. It would need the last param to be var as well, and be passed in true, for required stop - And of course this would reduce the possibilities a lot, and be far less elegant. (but then again where in the above list should the line be drawn?) - on the pro: - It is the simpliest solution. Some iterators do not need to be an object. - For Iterators that need to be an object, it can act as a wrapper and store it in pointer - using could still be done, but need to point to a function of this type - no hardcoded function/method names (see below) - compatible with how other operators are overloaded (as functions) The problem I have with the iterator being an object is that it would currently end up with having certain method names (such as next) hardcoded in the compiler = I dislike this idea. (actually dislike is understating it) So if the iterator was to be an class/object, there would first be a need to introduce keywords or modifiers, that allow the programmer to mark the correct methods for the operation. My 2 cent Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
