Re: [fpc-pascal] generics class hierarchy
On 19.12.2010 02:51, David Emerson wrote: Sven Barth wrote: I've now looked at your example code in more detail (I was working the last time I wrote you). Where did you define "_t_point"? I only found a "t_point" in your second mail. _t_point is part of the template list. Eh... yes, I've missed that one... so much about "looked at in more detail" ^^ Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CDDB unit
On Saturday 18 December 2010 23:56:24 Andrew Haines wrote: > Does anyone have the cddb unit that was on the wiki once upon a time? > http://wiki.lazarus.freepascal.org/CDDB > > The link on that page is now dead. is this one not useful ? fpc/packages/cdrom/src/fpcddb.pp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
On 19.12.2010 08:34, Honza wrote: 2010/12/19 David Emerson: type generic gt_box<_t_point,_num> = class (_t_point) // FAILS :-( f_width, f_height : _num; end; I think it should fail according to the docs, see: http://www.freepascal.org/docs-html/ref/refse42.html "There is a single placeholder _T. It will be substituted by a type identifier when the generic class is specialized. The identifier _T *may not be used for anything else than a placehoder*. " According to the documentation I'd say that it should succeed, because in "class(BaseClass)" "BaseClass" is a type identifier. But of course that has its own set of problems... see the second last paragraph of this mail. The bold part is IMO violated by the declaration. Anyway, it could be perhaps (not tested) written as: type TBoxProxy = class(_t_point); generic gt_box<_t_point, _num> = class(TBoxProxy) f_width, f_height : _num; end; No, this won't work, because "_t_point" won't be defined when "TBoxProxy" is parsed. Another strange point is, that the declaration of gt_box doesn't use the formal specialization paramater `_t_point` at all (in the posted code), so the same the other way around should also work: It IS used, because David wants to influence the class the generic class gt_box inherits from when specializing the class. E.g.: type TIntPoint = class x, y: Integer; end; TFloatPoint = class x, y: Single; end; generic gt_box<_t_point, _num> = class(_t_point) width, height: _num; end; TFloatBox = specialize gt_box; TIntBox = specialize gt_box; type generic gt_box<_num> = class<_t_point> f_width, f_height : _num; end; This won't compile because of the "<...>" around "_t_point". Also it's not what Daniel intends. A 3rd note is that your code can't compile as _t_point is not declared when gt_box is declared, but the declaration wants to inherit from _t_point, so IMO also for this the code is rightfully rejected the compiler. The question is whether this should be rejected if "_t_point" is a template parameter... on the other hand this would violate compile time checks of the generic class... I'm still thinking how David's idea could be achieved in another way which is supported by the compiler... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
On Sat 18 Dec 2010, Honza wrote: > 2010/12/19 David Emerson : > > type > > generic gt_box<_t_point,_num> = class (_t_point) // FAILS :-( > > f_width, f_height : _num; > > end; > > I think it should fail according to the docs, see: > > http://www.freepascal.org/docs-html/ref/refse42.html > > "There is a single placeholder _T. It will be substituted by a type > identifier when the generic class is specialized. The identifier _T > *may not be used for anything else than a placehoder*. " Well, IMO the docs are a bit vague as to the definition of "placeholder". However, according to experience: - a placeholder _can_ be used for a type identifier that is used as a field within the class - a placeholder can't be used for a type identifier that is used to specify the ancestor class to inherit from Maybe "placeholder" is also referring to something that's going on internally to the compiler -- when the generic is defined, its class structure and VMT and everything must be known. I'm no compiler writer, but I guess it makes sense from that perspective. I was thinking of "placeholder" from the other perspective, in terms of words: the specialization substitutes these words into those places, and those places can by any type identifiers. More like what I'd expect from e.g. a scripting language. But it doesn't work like that. > The bold part is IMO violated by the declaration. Anyway, it could be > perhaps (not tested) written as: > > type > TBoxProxy = class(_t_point); > generic gt_box<_t_point, _num> = class(TBoxProxy) > f_width, f_height : _num; > end; no, this is completely not right at all. _t_point is a placeholder. I want to use a placeholder to specify the ancestor class. In your example here you're treating _t_point as an already-defined class which TBoxProxy can inherit from. _t_point doesn't exist, it never exists, it's just a placeholder for a proper type identifier. > Another strange point is, that the declaration of gt_box doesn't use > the formal specialization paramater `_t_point` at all (in the posted > code) yes it does. It is used to specify the ancestor class. But I think I have now beaten the issue to death. I am curious, though, if e.g. delphi allows this syntax? Cheers, David > , so the same the other way around should also work: > > type > generic gt_box<_num> = class<_t_point> > f_width, f_height : _num; > end; > > A 3rd note is that your code can't compile as _t_point is not declared > when gt_box is declared, but the declaration wants to inherit from > _t_point, so IMO also for this the code is rightfully rejected the > compiler. > > HTH > -- > bflm > freepascal-bits.blogspot.com > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
2010/12/19 Sven Barth : >> "There is a single placeholder _T. It will be substituted by a type >> identifier when the generic class is specialized. The identifier _T >> *may not be used for anything else than a placehoder*. " >> > > According to the documentation I'd say that it should succeed, because in > "class(BaseClass)" "BaseClass" is a type identifier. But of course that has > its own set of problems... see the second last paragraph of this mail. The type parameter in the inheritance part clause, i.e. class(T) part of the generic class declaration has nothing to do with the placeholder formal parameter. The placeholder formal arg list are given inside the sharp brackets <> as a kind of macro parameters. And the docs explicitly states that a placeholder identifier may not be used elsewhere in the generic declaration except for identifying the place where the "macro" expansion should substitute the instantiation/specialization parameter. So using it in the inheritance clause is invalid. IMO the docs are clear on this and my experiments seems to confirm this behaviour. I have excersised generics a lot to get heLib compiled and working. Still the latest changes in the compiler broke the published code as I realized very recently and not yet uploaded the remedy which sits on my local disk. >> The bold part is IMO violated by the declaration. Anyway, it could be >> perhaps (not tested) written as: >> >> type >> TBoxProxy = class(_t_point); >> generic gt_box<_t_point, _num> = class(TBoxProxy) >> f_width, f_height : _num; >> end; >> > > No, this won't work, because "_t_point" won't be defined when "TBoxProxy" is > parsed. Yes it's not defined and that was my 3rd note, you can't base a generic declaration on a not yet specialized ancestor. >> Another strange point is, that the declaration of gt_box doesn't use >> the formal specialization paramater `_t_point` at all (in the posted >> code), so the same the other way around should also work: > It IS used, because David wants to influence the class the generic class > gt_box inherits from when specializing the class. It is not used *anywhere except* in the invalid place of the ancestor type. > type > TIntPoint = class > x, y: Integer; > end; > > TFloatPoint = class > x, y: Single; > end; > > generic gt_box<_t_point, _num> = class(_t_point) > width, height: _num; > end; > > TFloatBox = specialize gt_box; > TIntBox = specialize gt_box; > >> type >> generic gt_box<_num> = class<_t_point> >> f_width, f_height : _num; >> end; >> > > This won't compile because of the "<...>" around "_t_point". Also it's not > what Daniel intends. Yes, that's just a typo, round parenthesis are what I've meant and should wrote there. >> A 3rd note is that your code can't compile as _t_point is not declared >> when gt_box is declared, but the declaration wants to inherit from >> _t_point, so IMO also for this the code is rightfully rejected the >> compiler. > > The question is whether this should be rejected if "_t_point" is a template > parameter... on the other hand this would violate compile time checks of the > generic class... > > I'm still thinking how David's idea could be achieved in another way which > is supported by the compiler... I've not yet got time to look at his goal at all, so I don't know. I just spotted the invalid constructs presented. -- bflm freepascal-bits.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
2010/12/19 David Emerson : Please see my just sent reply to Sven. -- bflm freepascal-bits.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
On 19.12.2010 13:03, Honza wrote: 2010/12/19 Sven Barth: "There is a single placeholder _T. It will be substituted by a type identifier when the generic class is specialized. The identifier _T *may not be used for anything else than a placehoder*. " According to the documentation I'd say that it should succeed, because in "class(BaseClass)" "BaseClass" is a type identifier. But of course that has its own set of problems... see the second last paragraph of this mail. The type parameter in the inheritance part clause, i.e. class(T) part of the generic class declaration has nothing to do with the placeholder formal parameter. The placeholder formal arg list are given inside the sharp brackets<> as a kind of macro parameters. And the docs explicitly states that a placeholder identifier may not be used elsewhere in the generic declaration except for identifying the place where the "macro" expansion should substitute the instantiation/specialization parameter. So using it in the inheritance clause is invalid. IMO the docs are clear on this and my experiments seems to confirm this behaviour. I have excersised generics a lot to get heLib compiled and working. Still the latest changes in the compiler broke the published code as I realized very recently and not yet uploaded the remedy which sits on my local disk. While I DO agree with you (after some thinking about the consequences) that a base class should not be allowed to be specified by a template parameter (and this is the way it already is), I don't agree with you that the documentation states this as clearly as you propose it. The documentation says that every occurrence of a template parameter will be replaced by a type identifier (e.g. Integer, String, TObject). Now the documentation of a normal class declaration ( http://www.freepascal.org/docs-html/ref/refse31.html#x67-770006.1 ) states that the heritage clause contains a "class type identifier" which is just a special case of a type identifier. So when one reads the documentation of generics one CAN (!) come to the (wrong) conclusion that you can also put a template parameter into the heritage clause of a class. Here the documentation of generics should state more clearly that "class(T)" is not allowed, neither in the main class nor in sub classes. I'm still thinking how David's idea could be achieved in another way which is supported by the compiler... I've not yet got time to look at his goal at all, so I don't know. I just spotted the invalid constructs presented. @David: Maybe you can restructure your class hierarchy to something like this (you'll need to be a bit creative here ^^): generic gt_box<_num> = class type t_point = specialize gt_point<_num>; var f_position: t_point; f_width, f_height : _num; end; or this generic gt_box<_t_point, _num> = class f_position: _t_point; f_width, f_height: _num; end; I don't really see another possibility. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
2010/12/19 Sven Barth : > While I DO agree with you (after some thinking about the consequences) that > a base class should not be allowed to be specified by a template parameter > (and this is the way it already is), I don't agree with you that the > documentation states this as clearly as you propose it. I admit, that it looks clear to me only now - after/because of several hours bouncing my head against the keyboard when I struggled to get generics make what I wanted, so I'm not anymore unbiased when looking at the docs :-) > Here the documentation of generics should state more clearly that "class(T)" > is not allowed, neither in the main class nor in sub classes. I believe any reasonable improvement patch of the docs would be welcome by the dev team. You can then get into the chapter text exactly those words you would like to read there - a nice compensation for a little effort I think :-) Best regards, -- bflm freepascal-bits.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpGUI powered by OpenGL
Today after tinkering a few hours I managed to get an fpGui hello world app running with OpenGL and GLut as back-end. It seemed even easier than anticipated to switch the back-end. I'm happy to share code, although due to implementation differences it will never be possible to have a clean solution which could be merged with the original source. Cheers, Darius PS. fonts are rendered using freetype, used font is Ubuntu-R <>___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGUI powered by OpenGL
On Sun, 19 Dec 2010, Darius Blaszyk wrote: Today after tinkering a few hours I managed to get an fpGui hello world app running with OpenGL and GLut as back-end. It seemed even easier than anticipated to switch the back-end. I'm happy to share code, although due to implementation differences it will never be possible to have a clean solution which could be merged with the original source. What does that mean ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGUI powered by OpenGL
On Sun, 2010-12-19 at 19:15 +0100, Michael Van Canneyt wrote: > > On Sun, 19 Dec 2010, Darius Blaszyk wrote: > > > Today after tinkering a few hours I managed to get an fpGui hello world > > app running with OpenGL and GLut as back-end. It seemed even easier than > > anticipated to switch the back-end. I'm happy to share code, although > > due to implementation differences it will never be possible to have a > > clean solution which could be merged with the original source. > > What does that mean ? This means that a modified (fork?) FPGui could be made available on probably most platforms where FPC and OpenGL are available at (win/*nix/mac but also mobile targets/platforms like iPhone and other through OpenGL ES). This could potentially be useful for game developers that would like to use a toolkit out of the box instead of developing one themselves from scratch. Regards, Darius ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
> @David: Maybe you can restructure your class hierarchy to something like > this (you'll need to be a bit creative here ^^): heh, no, my solution is to abandon generics :-) I used a find/replace script to make alternate classes with real values. Thanks for all your input, though. Thanks to you, too, Honza ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
