[fpc-devel] Some Generics inspirations
Some Generics inspirations: http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dndotnet/html/BestPractices.asp http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dndotnet/html/ToolSupport.asp http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dndotnet/html/NetFramework.asp http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dndotnet/html/Fundamentals.asp ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Marco van de Voort wrote: Florian Klaempfl [EMAIL PROTECTED] wrote: Is this correct so far? Ok. So, FPC will follow chrome/Delphi? Afaik there is no need to. Chrome is as relevant as C++, since it is a different language, and Delphi implements .NET stuff, and maybe provides a backwards compat kludge for win32 at best. For us, native is the core platform, and how they twist themselves to achieve compat between .NET and win32 (and how much .NET syntax they borrow) is not our problem. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Delphi incompatibility is a NoGo for FPC. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Vincent Snijders wrote: LOL. Then they have to publish their specs real soon now. And I mean not something in a blog, but more something like documentation. We can't wait another 5 years, until they finally make up their mind. Generics are already standardized. Which standard is that ? C++ ? C# ? VB ? According to Borland, the Win32 Gernerics syntax will be a subset of the .Net sytanx. And do they have .Net generics in Delphi ? If they don't, the syntax is still open. Michel. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Michael Van Canneyt wrote: On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Vincent Snijders wrote: LOL. Then they have to publish their specs real soon now. And I mean not something in a blog, but more something like documentation. We can't wait another 5 years, until they finally make up their mind. Generics are already standardized. Which standard is that ? C++ ? C# ? VB ? ECMA Standard 334 According to Borland, the Win32 Gernerics syntax will be a subset of the .Net sytanx. And do they have .Net generics in Delphi ? In Delphi 2007. Delphi.Net Generics syntax is defined by the .Net syntax. If they don't, the syntax is still open. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Michael Van Canneyt wrote: On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Vincent Snijders wrote: LOL. Then they have to publish their specs real soon now. And I mean not something in a blog, but more something like documentation. We can't wait another 5 years, until they finally make up their mind. Generics are already standardized. Which standard is that ? C++ ? C# ? VB ? ECMA Standard 334 But this is a standard for C#, so totally useless for Pascal syntax-wise. Have you seen the VB syntax on the website you recommend ? It may be 'only' VB, but it's at least a more clear syntax than the C#/C++ one. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 08 Nov 2005 21:06:10 +0100 [EMAIL PROTECTED] wrote: [...] ECMA Standard 334 But this is a standard for C#, so totally useless for Pascal syntax-wise. Why useless? You can do exactly the same in a Pascal-styled way. We need just a minor part from the standard for the FPC compiler. Why do you think, that Borland will use ECMA Standard 334 for C# for the Delphi generics? Is there any official page, document, statement? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Mattias Gaertner wrote: Why do you think, that Borland will use ECMA Standard 334 for C# for the Delphi generics? Is there any official page, document, statement? Why should Borland reinvent the wheel? http://bdn.borland.com/article/0,1410,33383,00.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] File locations
On Tue, 8 Nov 2005, Vincent Snijders wrote: Paul Davidson wrote: Latest (more or less) versions of 2.1.1 and 2.0.1 seems to have changed file locations for generated files. This breaks the FPC XCode integration kit. I think this has been caused by a fix in the -o option handling. Before it ignored the extension. Now it cannot be used in combination with -FE. I think Michael van Canneyt is working on a fix for this: -FE is not ignored if the -o options doesn't include a path. This is correct. Revision 1698 contains this fix. The behaviour is now: - If -o contains a path, it overrides any previous -FE. If -o does not contain a path, it leaves any -FE setting intact. - If -FE is specified after -o, it will override the output path. So -FEdir1 -odir2/binfile outputs in dir2 -FEdir2 -obinfile outputs in dir2 -odir1/binfile -FEdir2 outputs in dir2 Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: Why do you think, that Borland will use ECMA Standard 334 for C# for the Delphi generics? Is there any official page, document, statement? Why should Borland reinvent the wheel? http://bdn.borland.com/article/0,1410,33383,00.html That they will not invent new functionality is clear. But absolutely nothing is said about pascal _syntax_ for generics. How this is translated to the underlying CLI is something else, but that need not concern us. No-one is questioning the possibilities of generics. We're questioning the syntax to be used. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] File locations
Thank you Michael On Nov 8, 2005, at 14:16, Michael Van Canneyt wrote: This is correct. Revision 1698 contains this fix. The behaviour is now: - If -o contains a path, it overrides any previous -FE. If -o does not contain a path, it leaves any -FE setting intact. - If -FE is specified after -o, it will override the output path. So -FEdir1 -odir2/binfile outputs in dir2 -FEdir2 -obinfile outputs in dir2 -odir1/binfile -FEdir2 outputs in dir2 Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel P Davidson http://CoraxNetworks.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics Basics
On Tuesday 08 November 2005 21:33, L505 wrote: Hello, I am trying to understand what exactly generics are. I read the wiki page, but there are lot's of code examples and very few explanations. Can someone explain it to me in a (relatively) simple way? What problem is it trying to solve? And how do generics relate to interfaces? I had the same problem for a few years. It took me a few months/years to first diagnose what the fudge templates/generics actually were, and what problem they exactly solved. All the information about generics is pretty non-real world and non-case study on the internet. It is also hyped by programmers who again seem to show no real world or case studies. But I can see how they can be useful in theory, nevertheless. I'm not going to give you a technical explanation on what they are, because someone else can do that (and I don't have experience with generics, so I'm not qualified to do so). Here is a vague non-technical explanation: Basically generics helps you save some Typing and syntax in your units. You can address several things at once with the same Type. Supposedly, this encourages code reuse. You can address and create things via a shortcut syntax sort of way. The Very Big Advantage (Tm), is that you get syntax checking, while still using a type diversely. That's impossible to do (at compile-time) without generics. Probably the best example of this is something like TList: Without generics: TOrange = class ... end; TApple = class ... end; var T: TList; begin T := TList.Create(); T.Add(TApple.Create()); T.Add(TOrange.Create()); // Whoops, what was that? Now our program might crash. end; Of course, we could create a specialized TAppleList that only accepts Apples, but that's boring and hard work. A much cleaner way is generics: var T: TListTApple; begin T := TListTApple.Create(); T.Add(TApple.Create()); T.Add(TOrange.Create()); // This wont compile! The problem is prevented at compile-time! end; I hope that answers your question as to why it's a good idea :-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
[EMAIL PROTECTED] wrote: You stated that we could know already what the delphi-syntax will be, if they add generics over two years. But we can't, since we don't know what 'pascal-styled' way they will choose. I would say that a pascal-way is adding the 'interface' keyword. Like in array's and such. This is already mentioned. The chances that Borland will choose another pascal-styled-syntax is huge. Besides of that, I don't find that delphi-incompatibility is a no-go-area. Especially if we (or they - the core team) are the first ones who implement this feature. And incompatibilities can be solved in Delphi mode. And in general: If we can do something better then Delphi, I choose for loosing the compatibility. Joost. You have my absolutly insignificant voice on that one. I fully agree. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics Basics
L505 wrote: The Very Big Advantage (Tm), is that you get syntax checking, while still using a type diversely. That's impossible to do (at compile-time) without generics. Probably the best example of this is something like TList: Without generics: TOrange = class ... end; TApple = class ... end; var T: TList; begin T := TList.Create(); T.Add(TApple.Create()); T.Add(TOrange.Create()); // Whoops, what was that? Now our program might crash. end; Of course, we could create a specialized TAppleList that only accepts Apples, but that's boring and hard work. A much cleaner way is generics: var T: TListTApple; begin T := TListTApple.Create(); T.Add(TApple.Create()); T.Add(TOrange.Create()); // This wont compile! The problem is prevented at compile-time! end; I hope that answers your question as to why it's a good idea :-) -- Regards, Christian Iversen Sort of, but I don't see why people use TApple and TOrange examples all the time ;-) I mean when was the last time you actually programmed a software application that was organizing Apples and Oranges? I use things like strings, databases, integers, FTP, CGI, stringlists, etc. Sure apples and oranges can represent a sort of metaphor for ANYTHING, but I'd prefer just to cut straight to the real world example instead. I assume that when ever you wrote some piece of software you needed a list of something, say a list of integers and a list of objects. (at least I need them a lot) you can solve this in various ways. 1) --- you can use an instance of TList and use a lot of casting. I guess you understand this is pretty unsafe. It requires a lot of dicipline from you as programmer (and from your co coders) example 1a (objects in a list): list := TList.Create; obj := TMyObject.Create; list.add(obj); obj := TMyObject.Create; list.add(obj); if you need an object form yuor list, you need obj := TObject(List[1]); //unsafe cast. example 1b (integers in a list): list := TList.Create; list.add(Pointer(someint));//typecast needed to add list.add(Pointer(anotherint)); if you need an integer form yuor list, you need yourint := Integer(List[1]); //unsafe cast. 2) --- To make things safer, you can create dedicated classes for them with TList as base class. Since you need specific tipes, you need to override all methods where TList uses a pointer. This means write a wrapper for Add, Insert, IndexOf, Get, Set, etc. This means a lot of coding TMyIntList.Add(value: Integer) begin inherited Add (Pointer(Value)); end; etc. 3) --- Use generics. Now you code your TListT once like (I assume some syntax here) type TList_T is class(TObject) procedure Add(item: _T); end; Now, when you need a list of intgers, you can declare it as type TMyIntList = TListinteger; ... list := TMyIntList.Create; list.Add(someInt); or even when you need a list of TSomeObject: type TMySomeObjectList = TListTSomeObject; ... list := TMySomeObjectList.Create; obj := TSomeObject.Create; list.Add(obj); --- You understand now ? I only defined/coded one generic list class, and I can use it to store all kinds of types in a typesafe manner. The advantage is that I can reuse the (in this case) list code, so I only have to solve problems in one place, it reduces time, since I don't have to copy/paste/find/replace existing classes etc. I guess the real world examples are hard to display unless you have actually used generics in a software program, and you are willing to offer code snippets from the program. I cannot give you a real world generic example, since it doesn't exist yet for delphi. And thats where I write programs with. And yes, I've coded several similar list with all different types. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics Basics
dannym wrote: Hi, Am Dienstag, den 08.11.2005, 18:10 -0200 schrieb Felipe Monteiro de Carvalho: Hello, I am trying to understand what exactly generics are. I read the wiki page, but there are lot's of code examples and very few explanations. Can someone explain it to me in a (relatively) simple way? What problem is it trying to solve? It makes types parametrizable. For example, if you write a list class, traditional delphi has TList. However, this TList can only contain TObject, no double/integer/... . Moreover, you can put objects of *differing* (i.e. unrelated) classes in the same list, which is most of the time a bad bad idea. Excuse me for resorting to an example again, but it's just easiest to see: 1) without generics type TAppleList = TList; TApple = class end; TOrange = class end; var apples: TAppleList; apple: TApple; begin apples.Add(TApple.Create); // works apples.Add(TOrange.Create); // works, and is stupid apple := apples[0]; // compile error apple := apples[1]; // compile error apple := apples[0] as TApple; // manual cast, works apple := apples[1] as TApple; // compiles, breaks at runtime end; Generic types, on the other hand, define just the TList, but do not fix the contained type in it, but leave it as a parameter to specify later. 2) with generics type TListItem = generic(T) record Data: T; Next: TListItem(T); end; PListItem = ^generic(T) TListItem(T); TList = generic(T) class private fHead: PListItem(T); fTail: PListItem(T); published procedure Add(Item: T); end; procedure TList.Add(Item: T); var node: PListItem(T); begin New(node); node^.Data := Item; node^.Next := nil; if Assigned(fTail) then begin fTail^.Next := node; end else begin fHead := node; end; fTail := node; end; type TApple = class end; TOrange = class end; TAppleList = TList(TApple); var apples: TAppleList; apple: TApple; begin apples.Add(TApple.Create); // works apples.Add(TOrange.Create); // compile error apple := apples[0]; // works apple := apples[1]; // not applicable apple := apples[0] as TApple; // works, but unneccessary apple := apples[1] as TApple; // not applicable end; And how do generics relate to interfaces? interfaces in pascal are mostly runtime-bound. Generics are mostly resolved at compile time. Otherwise quite similar, with the exception that there is no mother of everyone class, that is, a class which is the base class of all other types, also of i.e. Integer. i.e. Integer = class(TAll, IUnknown); Double = class(TAll, IUnknown); Boolean = class(TAll, IUnknown); TObject = class(TAll, IUnknown); TFoo = class(TObject); note that I'm not advertising that there should be one, just noting the facts. The fact being, if there were one, interfaces would do the same as generics, just at runtime. Without one, interfaces do nearly the same as generics (just don't work for simple types), but still work only at runtime (at huge cost). Doing stuff at runtime slows the program down, and also note that the more you do at runtime, the more stuff the compiler has to compile in at each place just in case something x or y happens at runtime, at every place. Worse, if the language is not really designed for stuff to be determined at runtime (i.e. late bound stuff), it sucks. Therefore you have to add as TApple. Because the language just doesn't expect that you want it to automagically upcast back to what it was. If it were a language designed for stuff to be determined at runtime too (late bound), from the line apple := apples[0]; it would automagically generate (invisible for the programmer, but in the executable): var temp: TObject; temp := apples[0]; if apple is TApple then apple := temp as TApple else raise ETypeError.Create...; that is, it would add code for runtime type inference. (Note that the is TApple and as TApple are the destination type of the variable apple, i.e. the compiler still wouldn't know what type is _in_ the list, it just knows you _want_ to have an TApple. If you instead specified orange: TOrange; and accessed: orange := apples[0];, fine, it will cast to TOrange, you asked for it, you get it) Which would be a little better than now, but slower. (as a side note, note the only reason why anybody bothers with type safe compiled languages is strong type checking, that is total _compile time_ strong type checking, also known as if it compiles, it works (mostly). If it weren't for that advantage (ok, and the speed advantage when done right), nobody would use strongly typed languages) Generics, therefore, move the complexity into the type checker of the compiler instead, the benefit being generation of faster code, compile-time (automatically) verifyable code, but at the cost of a larger executable size. thanks, Felipe Monteiro de Carvalho I hope I didn't commit major blunders in the explaination, but it should be about right :) cheers,
Re: [fpc-devel] Generics Basics
I´m starting to like generics, specially for this: (as a side note, note the only reason why anybody bothers with type safe compiled languages is strong type checking, that is total _compile time_ strong type checking, also known as if it compiles, it works (mostly). If it weren't for that advantage (ok, and the speed advantage when done right), nobody would use strongly typed languages) Sounds very pascal to do compile time checkings. This increases the efficiency of the programmer, diminishing the errors. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Why should Borland reinvent the wheel? http://bdn.borland.com/article/0,1410,33383,00.html That they will not invent new functionality is clear. But absolutely nothing is said about pascal _syntax_ for generics. How this is translated to the underlying CLI is something else, but that need not concern us. No-one is questioning the possibilities of generics. Of the .NET generics for native use? Yes I am :_) I had a thread about this in borland.delphi.non-technical, and the base problem seems to be that generics can be only applied to a class using an interface. Of course in .NET nearly everything is an object. I haven't seen anything about native implementation yet. We're questioning the syntax to be used. So I think even if some Delphi.NET2 syntax is revealed, we still can't do anything with it, till we know for sure if the native implementation is not some awful non-optimal kludge to allow .NET generics using code to compile on delphi/native. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Generics Basics
Hello all, I didn't discuss about this idea but now I would say something. Is it really important, to integrate templates support into compiler? Maybe an external preprocessing utility should be better? I think, an integrated complex preprocessor can slow the compiling process very much even if a source code doesn't contain these syntax extensions. Very rapid compiling was always a great pascal advantage over c++. This improvement can kill this advantage. -- Best regards, Pavelmailto:[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Re[2]: [fpc-devel] Generics Basics
I didn't discuss about this idea but now I would say something. Is it really important, to integrate templates support into compiler? Yes. Otherwise they are no templates. Maybe an external preprocessing utility should be better? IMHO this can't be done. E.g. the avoiding of multiple instantiation of the same code using the type system requires this. I think, an integrated complex preprocessor can slow the compiling process very much even if a source code doesn't contain these syntax extensions. Very rapid compiling was always a great pascal advantage over c++. This improvement can kill this advantage. An external preprocessor is a nono. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics Basics
Op Wed, 9 Nov 2005, schreef Pavel V. Ozerski: Hello all, I didn't discuss about this idea but now I would say something. Is it really important, to integrate templates support into compiler? Maybe an external preprocessing utility should be better? I think, an integrated complex preprocessor can slow the compiling process very much even if a source code doesn't contain these syntax extensions. Very rapid compiling was always a great pascal advantage over c++. This improvement can kill this advantage. Ok, lets put it blunt. It is absolutely not important to have templates at all. We've been able to develop top class code of the best kind without templates. There's a big risk involved with templates; code bloat. Namely, with templates, you can instantiate classes without realising that you are adding tens of kilobytes of code. I.e. in C++ if you instantiate a vectorclass_a *, vectorclass_b *, vectorclass_c *, you have three implementations of the vector in your code, which are all an array of pointers! Surely Pascal's Tcollection/Tlist is much more efficient. But... Templates can save typing. People are demanding them, because there is a hype. Lack of templates is seen as a deficiency of Pascal against C++. So we should support them. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
