Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Vincent Snijders het geskryf: > > Is there a patch to review, so I can see what this discussion is all > about? I posted some example code earlier in a reply to Marco (sorry, it's somewhere between all the noise). > I wonder if something like class helpers is able to solve this, > like Matt s

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Sent from my iPhone On 19 May 2010, at 23:02, Graeme Geldenhuys wrote: maybe some of you don't even know what Design Patterns are - this doesn't make them less useful. In my experience, often badly implemented and regularly abused. Patterns take extreme discipline. Either you FORCE pr

Re: [fpc-devel] Parameters must match exactly?

Alexander Klenin het geskryf: > Look at r21318 of Lazarus (tachart: fixed compilation with fpc 2.5.1, > by Vincent). > > I think it is a typical sample of change required to production code Good example, and a terrible code change. That code change has no benefits [compared to the old code] as f

Re: [fpc-devel] Parameters must match exactly?

Vinzent Höfler het geskryf: > > : Those are brilliant. I love the Java one. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ __

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Am 20.05.10 01:27, schrieb Graeme Geldenhuys: On 20/05/2010, Marco van de Voort wrote: Yeah. Studying means neither. Well lets see: I have written numerous technical papers/articles on the subject, been using it in commercial software for almost 10 years and presented technical and t

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Sent from my iPhone On 20 May 2010, at 07:52, Graeme Geldenhuys wrote: Matt Emson het geskryf: Patterns are faddy - you are not going to please everyone. Please explain and give examples where Observer will not be useful. Also, I do not know what "faddy" means. Having used it a lo

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Matt Emson het geskryf: > > In my experience, often badly implemented and regularly abused. Then whoever wrote that code you looked at has no clue what they were doing and has a near zero understanding of design patterns or OOP. > Patterns take extreme discipline. On the contrary, design patte

Re: [fpc-devel] Parameters must match exactly?

Graeme Geldenhuys : > Vinzent Höfler het geskryf: > > > > : > > Those are brilliant. I love the Java one. :) Thinking about it, with all those typecasts involved, this one fits much better to the current discussion: -- 8< .-- Object Oriented

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Wed, 19 May 2010, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: So - let's try another approach which may prove more constructive: What are your proposals to get some kind of observer pattern implemented so it can be applied consequently throughout the classe

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

In our previous episode, Michael Van Canneyt said: > > the state of the object) and also keeps no state (the list is also in > > Observable) > > Observable and Observer go hand in hand. We're talking about both. > Specifically, I want to add observable to TPersistent. People having object framewo

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Thu, 20 May 2010, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: the state of the object) and also keeps no state (the list is also in Observable) Observable and Observer go hand in hand. We're talking about both. Specifically, I want to add observable to TP

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Helmut Hartl het geskryf: > Patterns are super - but not if you are coding something performance > critical. Then you are still struggling to understand design patterns. I'll say it again: They are a design guide for solving a common found problem. How you implement it, is up to you! Design patt

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...? (fwd)

Forwarded here, so everyone can see it. I mistakenly replied to Marco alone. Michael. -- Forwarded message -- Date: Thu, 20 May 2010 09:39:29 +0200 (CEST) From: Marco van de Voort To: Michael Van Canneyt Cc: Marco van de Voort Subject: Re: [fpc-devel] Interface delegation fix

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

In our previous episode, Michael Van Canneyt said: > >> Observable and Observer go hand in hand. We're talking about both. > >> Specifically, I want to add observable to TPersistent. > > > > People having object frameworks based on that class will really thank you > > for slowing their systems. >

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

In our previous episode, Graeme Geldenhuys said: > Helmut Hartl het geskryf: > > Patterns are super - but not if you are coding something performance > > critical. > > Then you are still struggling to understand design patterns. I'll say it > again: They are a design guide for solving a common f

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...? (fwd)

In our previous episode, Michael Van Canneyt said: It's not because you don't see a need, that others don't have it; there is no point in discussing that, we will never agree on that. Just like I don't discuss religion with people. Well, there's your precedent problem, right there. Those ar

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Thu, 20 May 2010, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: Observable and Observer go hand in hand. We're talking about both. Specifically, I want to add observable to TPersistent. People having object frameworks based on that class will really thank y

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Matt Emson het geskryf: > > Having used it a lot recently, I'd prefer MVC to be used with in a > class library. MVC often uses Observer! Model-GUI-Mediator (MGM) that I implemented in tiOPF and use daily in our current software is very similar to MVC without the need of creating descendant "vie

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Marco van de Voort het geskryf: > > Yes. But nobody has said you have to stuff each and everyone of them in each > piece of software and have support for all of them in your library. Nobody suggested that either. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Fr

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Wed, 2010-05-19 at 18:59 +0200, Graeme Geldenhuys wrote: > On 19 May 2010 16:20, Michael Van Canneyt wrote: > > I have an implementation in place, which doesn't affect too much the > > existing classes: it adds 1 public property and one private method; There is > > no impact on code efficiency.

Re: [fpc-devel] Should TAutoIncField be read only?

On Wed, 2010-05-19 at 14:14 -0300, Luiz Americo Pereira Camara wrote: > Joost van der Sluis escreveu: > > On Wed, 2010-05-19 at 00:32 -0300, Luiz Americo Pereira Camara wrote: > > > >> Until a few moments ago i would say yes because it seems logical and fpc > >> raises an exception when trying

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On 19 May 2010 23:57, Graeme Geldenhuys wrote: > On 20/05/2010, Henry Vermaak wrote: >>  Anyway, I do hope that there is a feasible to implement this, because >>  the observer pattern is very powerful. > > I'm confused. One minute it sounds like you are saying no it's a bad > idea, then the next p

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Joost van der Sluis het geskryf: > >> 1) Ignore Marco and implement it any way. I think you have just as >> much say as Macro on what goes into the FPC. > > thread yet. But here you are going too far. Way too far. Imho we don't Well my statement was true wasn't it? Michael's opinion should coun

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Wed, 2010-05-19 at 19:52 +0200, Graeme Geldenhuys wrote: > On 19 May 2010 19:24, Michael Van Canneyt wrote: > > > > that I actually need and why I implemented observer in the first place: to > > be able to observe for instance the changes in TMemo.Lines or > > TCombobox.Items. (and these are fro

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Am 20.05.10 10:29, schrieb Graeme Geldenhuys: Joost van der Sluis het geskryf: 1) Ignore Marco and implement it any way. I think you have just as much say as Macro on what goes into the FPC. thread yet. But here you are going too far. Way too far. Imho we don't Well my statem

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Thu, 20 May 2010, Helmut Hartl wrote: Am 20.05.10 10:29, schrieb Graeme Geldenhuys: Joost van der Sluis het geskryf: 1) Ignore Marco and implement it any way. I think you have just as much say as Macro on what goes into the FPC. thread yet. But here you are going too far. Way too far.

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Am 20.05.10 11:01, schrieb Michael Van Canneyt: There is no change to TObject. Thank you very much for your clarification. That satisfies my personal needs full. helmut ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.

Re: [fpc-devel] Parameters must match exactly?

Alexander Klenin schrieb: > I would like to return the discussion to the original question, > now with the real code sample ;-) > Look at r21318 of Lazarus (tachart: fixed compilation with fpc 2.5.1, > by Vincent). > > [BTW, is there any web-interface for browsing Lazarus SVN?] > > I think it is

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On 20 May 2010, at 10:46, Helmut Hartl wrote: But fundamential changes in an stability release ? All changes are always committed first to trunk. It is indeed unlikely that a change like the one under discussion currently, if performed, would still be added to 2.4.2 (as also indicated in

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Thu, 20 May 2010, Jonas Maebe wrote: On 20 May 2010, at 10:46, Helmut Hartl wrote: But fundamential changes in an stability release ? All changes are always committed first to trunk. It is indeed unlikely that a change like the one under discussion currently, if performed, would still

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

michael.vancann...@wisa.be schrieb: > > I need a solution that works with current GUI, current libraries and > whatnot. What you propose is re-doing the work of 10 years, which is > obviously not feasable. Can you give a real world example what you want to do with it? I've no opinion if it's use

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Graeme Geldenhuys wrote: Matt Emson het geskryf: In my experience, often badly implemented and regularly abused. Then whoever wrote that code you looked at has no clue what they were doing and has a near zero understanding of design patterns or OOP. No. The problem with Patterns i

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

2010/5/19 Graeme Geldenhuys : > On 19/05/2010, Inoussa OUEDRAOGO  wrote: >> >> Agreed. This mechanism exists in Delphi and is called "class helper", >>  see http://docwiki.embarcadero.com/RADStudio/en/Class_and_Record_Helpers > > Ah yes, the famous "class helper" which makes designing a class > str

Re: [fpc-devel] Parameters must match exactly?

On Thu, 2010-05-20 at 16:57 +1100, Alexander Klenin wrote: > I would like to return the discussion to the original question, > now with the real code sample ;-) > Look at r21318 of Lazarus (tachart: fixed compilation with fpc 2.5.1, > by Vincent). > > [BTW, is there any web-interface for browsing

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Thu, 20 May 2010, Florian Klaempfl wrote: michael.vancann...@wisa.be schrieb: I need a solution that works with current GUI, current libraries and whatnot. What you propose is re-doing the work of 10 years, which is obviously not feasable. Can you give a real world example what you want

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Joost van der Sluis het geskryf: > > This is what Marco is afraid about: that people want to alter the > base-design, because 'their design is better'. That's certainly not what > we should do. Well luckily that is of no concern to FPC developers. Such changes would be discussed in the Lazarus or

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Matt Emson het geskryf: > > No. The problem with Patterns is that you need to embrace or reject. > There's no middle ground. DESIGN PATTERNS ARE NOT CODE TEMPLATES. YOU decide how to implement them, and if you did a s**t job it's your fault. > Patterns take extreme discipline because unless yo

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

In our previous episode, Matt Emson said: > Patterns take extreme discipline because unless you adhere to them, your > code gets incredibly convoluted. Been there, seen it. When applying any algorithm or technique, you need to see if it fits, and if it is no overkill, patterns are no different t

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Michael Van Canneyt schrieb: > > > On Thu, 20 May 2010, Florian Klaempfl wrote: > >> michael.vancann...@wisa.be schrieb: >>> >>> I need a solution that works with current GUI, current libraries and >>> whatnot. What you propose is re-doing the work of 10 years, which is >>> obviously not feasabl

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Graeme Geldenhuys wrote: Matt Emson het geskryf: Having used it a lot recently, I'd prefer MVC to be used with in a class library. MVC often uses Observer! And? I've never said the observer pattern was bad. I've only ever said that retrofitting it is bad. If I advocated a new framew

Re: [fpc-devel] Should TAutoIncField be read only?

Joost van der Sluis escreveu: On Wed, 2010-05-19 at 14:14 -0300, Luiz Americo Pereira Camara wrote: I'm just confused by the exception that is raised ("autoinc fields are read only") when trying to set a value and by the code in the TAutoIncField constructor that initializes FReadOnly to t

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Thu, 2010-05-20 at 09:18 +0200, Helmut Hartl wrote: > *EXPLICIT WARNING : "ACADEMIC VIEWPOINT"* > (this means worthless in practice :-)) (or I have read many books, > understood something and I am able to impress > people with wrong mathematical proofs) ;) Nice. To avoid the idea that some

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On Thu, 20 May 2010, Florian Klaempfl wrote: Michael Van Canneyt schrieb: On Thu, 20 May 2010, Florian Klaempfl wrote: michael.vancann...@wisa.be schrieb: I need a solution that works with current GUI, current libraries and whatnot. What you propose is re-doing the work of 10 years, whi

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Florian Klaempfl het geskryf: > > Can you give a real world example what you want to do with it? * This applies to fpGUI's implementation. TfpgAction can be observer by other components like TfpgButton, TfpgMenuItem etc.. The Action instance is changed, and the observers are notified about this

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Graeme Geldenhuys wrote: OK we just confirmed that you have no clue about OOP or design patterns, HAHAHAHAHAHAHAHAHAHA!! Wow. Your ego is too much for me. so I'll stop replying to your posts. Good. Please stop replying to the entire thread at the same time. None of us understand design patte

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On 20/05/2010 12:19, Matt Emson wrote: Graeme Geldenhuys wrote: OK we just confirmed that you have no clue about OOP or design patterns, HAHAHAHAHAHAHAHAHAHA!! Wow. Your ego is too much for me. so I'll stop replying to your posts. Good. Please stop replying to the entire thread at the same t

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On 20 May 2010, at 13:22, Paul van Helden wrote: Another message that doesn't add valuable content! (This one). Are there rules or guidelines for what gets discussed here and how? Not really, other than about the "what": things related to the development of FPC. You're right that this th

Re: [fpc-devel] Parameters must match exactly?

On Thu, May 20, 2010 at 20:35, Joost van der Sluis wrote: > On Thu, 2010-05-20 at 16:57 +1100, Alexander Klenin wrote: >> I would like to return the discussion to the original question, >> now with the real code sample ;-) >> Look at r21318 of Lazarus (tachart: fixed compilation with fpc 2.5.1, >>

Re: [fpc-devel] Parameters must match exactly?

On Thu, May 20, 2010 at 19:31, Florian Klaempfl wrote: > Alexander Klenin schrieb: >> I think it is a typical sample of change required to production code >> by the restriction we are discussing. >> Looking at the diff, I'd argue that: >> 1) Old version was cleaner. >> 2) New version is _not_ any

Re: [fpc-devel] Parameters must match exactly?

On 20 May 2010, at 13:57, Alexander Klenin wrote: the safe version would be var tmp: TFPCanvasHelper; ... InitHelper(tmp, TFont); tmp := FFont as TFont; I guess you mean "FFont := tmp as TFont" here. I suggest that compiler should generate the code equivalent to the third version based on

Re: [fpc-devel] Parameters must match exactly?

Alexander Klenin het geskryf: > > I do not usually need it, but if I post a link like > http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/tachart/tatypes.pas?root=lazarus&r1=21318&r2=21317&pathrev=21318 > it may be more convenient to readers than just mentioning r21318 True, and that

Re: [fpc-devel] Parameters must match exactly?

On Thu, May 20, 2010 at 23:03, Jonas Maebe wrote: > > On 20 May 2010, at 13:57, Alexander Klenin wrote: > >> the safe version would be >> >> var tmp: TFPCanvasHelper; >> ... >> InitHelper(tmp, TFont); >> tmp := FFont as TFont; > > I guess you mean "FFont := tmp as TFont" here. Yes, sorry. > It w

[fpc-devel] Class extension

Okay, so the whole Observer Pattern discussion this morning went way off track after I mentioned this idea, but a few people expressed interest in my proposal: I'd rather see a mechanism for injecting first class extensions to existing classes. That way, it really doesn't matter what pattern is

Re: [fpc-devel] Class extension

On 20 May 2010, at 14:29, Matt Emson wrote: In Objective-C, the Category often seems a lot like the Partial class in a superficial way. It is the same kind of idea - a breaking up of a class in to sections. Sections can be added and removed in a similar way. However the category goes furth

Re: [fpc-devel] Class extension

Jonas Maebe wrote: Having implemented support for Objective-C/Pascal categories in the compiler, I don't think that this concept can be translated to the (Delphi-compatible) Object Pascal model/implementation. It only works in Objective-C/Pascal because there all dispatching is based on the na

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Graeme Geldenhuys schreef: Vincent Snijders het geskryf: Is there a patch to review, so I can see what this discussion is all about? I posted some example code earlier in a reply to Marco (sorry, it's somewhere between all the noise). I am sorry, but I cannot find the code changes in the cl

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

In our previous episode, Vincent Snijders said: > >> I wonder if something like class helpers is able to solve this, > >> like Matt suggested. > > > > As I mentioned in another reply, class helpers are a pretty useless feature > > in Delphi and will not solve much. So the other message for reason

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Vincent Snijders schreef: Graeme Geldenhuys schreef: Vincent Snijders het geskryf: Is there a patch to review, so I can see what this discussion is all about? I posted some example code earlier in a reply to Marco (sorry, it's somewhere between all the noise). I am sorry, but I cannot find

[fpc-devel] Arm9 V5

I am trying a Hello World program on a embedded Linux board but get the error Illegal instruction when I try to run the program When I make the compiler I use these lines export PATH=$PATH:/pp/bin export PATH=$PATH:/Fpc/ArmBin/218 make clean all OS_TARGET=linux CPU_TARGET=arm PP=/pp/bin/fpc BIN

Re: [fpc-devel] Arm9 V5

On 20 May 2010, at 15:53, Carsten Bager wrote: Should I add something, to the make line to tell that it is an ARMV5 No, FPC's default is ARMv4. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/lis

[fpc-devel] TDataModule doesn't call inherited

Hi The following two methods in TDataModule do not call inherited in their implementation. So if anything gets introduced in TComponent and lower, that code will not execute. TDataModule = class(TComponent) ... public Procedure AfterConstruction; override; Procedure BeforeDestructi

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Vincent Snijders het geskryf: > > I found it, it got misclassified in my email client. In the archives > unreadable > unfortunately: > http://lists.freepascal.org/lists/fpc-devel/2010-May/020032.html This link is readable. http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg17168

Re: [fpc-devel] Arm9 V5

On 20 May 2010 14:53, Carsten Bager wrote: > I am trying a Hello World program on a embedded Linux board but get the error > Illegal instruction > when I try to run the program > > When I make the compiler I use these lines > > export PATH=$PATH:/pp/bin > export PATH=$PATH:/Fpc/ArmBin/218 > make c

[fpc-devel] http://freepascal.org/develop.var is outdated (points to 2.2 branch)

Hello, The FPC "Development" page (http://freepascal.org/develop.var) still links to 2.2 releases and branch, no mention of 2.4... Best regards, Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinf

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Michael Van Canneyt escreveu: On Thu, 20 May 2010, Florian Klaempfl wrote: I've no opinion if it's usefull to add or not, I use TPersistent+ too little but my concern is: if I create an observer for an instance, I'd expect to get notified about every change to the instance. But I cannot see h

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

> Michael Van Canneyt escreveu: >> >> >> On Thu, 20 May 2010, Florian Klaempfl wrote: >> >>> I've no opinion if it's usefull to add or not, I use TPersistent+ too >>> little but my concern is: if I create an observer for an instance, I'd >>> expect to get notified about every change to the instance

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Graeme Geldenhuys wrote: >> Patterns are faddy - you are not going to please everyone. >Please explain and give examples where Observer will not be useful. Also, I >do not know what "faddy" means. one of the first rules when using GoF book/patterns is: use them wisely/appropriately. that said,

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

On 20 May 2010 17:40, Dimitri Smits wrote: > one of the first rules when using GoF book/patterns is: > use them wisely/appropriately. Which is what we want to do. > that said, I've encountered many design pattern noobs who made it a fetish Neither Michael or myself are new to design patterns. I