Graeme Geldenhuys wrote:
Because many of the classes we want to observe descend from
TPersistent. So it make sense to put the basic workings of Observer
there, and then descendant components will decided what must trigger
notifications.
Also we couldn't implement Observer earlier in FPC
On 20 May 2010 23:27, Sergei Gorelkin wrote:
While current FPC implementation does not have this ugliness, it is
Delphi-compatible only to certain extent, and may change in the future. So
I'd avoid to rush and rely on it in the base classes.
I agree that your solution seems better than the
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.
I'd rather see a mechanism for injecting first class extensions to
existing classes.
* Interfaces
Sent from my iPhone
On 19 May 2010, at 22:42, Graeme Geldenhuys graemeg.li...@gmail.com
wrote:
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,
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
Sent from my iPhone
On 19 May 2010, at 23:02, Graeme Geldenhuys graemeg.li...@gmail.com
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
Am 20.05.10 01:27, schrieb Graeme Geldenhuys:
On 20/05/2010, Marco van de Voortmar...@stack.nl 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
Sent from my iPhone
On 20 May 2010, at 07:52, Graeme Geldenhuys graemeg.li...@gmail.com
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.
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
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
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 frameworks
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
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
...@stack.nl
Subject: Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?
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
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.
Why would
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 found
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
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
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 view
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 Free
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.
1)
On 19 May 2010 23:57, Graeme Geldenhuys graemeg.li...@gmail.com 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,
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 count too.
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 from
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
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.
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
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
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
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
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
2010/5/19 Graeme Geldenhuys graemeg.li...@gmail.com:
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
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
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
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 you
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
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 feasable.
Can you give
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
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 something
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,
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
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
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
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
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
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 why.
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
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.
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
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
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
On Wednesday 19 May 2010 12:20:23 Graeme Geldenhuys wrote:
Hi,
Is the following bugfix (original target was 2.4.0) going to make it into
FPC 2.4.2?
I'm about to implement something in fpGUI and would really like to use the
Observer pattern and interface delegation to attach the Observer
In our previous episode, Graeme Geldenhuys said:
Is the following bugfix (original target was 2.4.0) going to make it into
FPC 2.4.2?
I'm about to implement something in fpGUI and would really like to use the
Observer pattern and interface delegation to attach the Observer function
to
Marco van de Voort het geskryf:
http://bugs.freepascal.org/view.php?id=12778
Did you verify that it works when you insert this fix into 2.4.1? Does it
work with 2.5.1 currently?
I haven't tried to port that fix to 2.4.1 myself. It does work in current
2.5.1 though - just tried. I am
Martin Schreiber het geskryf:
Maybe
http://bugs.freepascal.org/view.php?id=16365
must be fixed too until you can use interface delegation to a class?
That seems to be a bug only in COM interfaces. I want to use Corba
interfaces which do not AV.
The same example as the one in the bug report,
In our previous episode, Graeme Geldenhuys said:
way to go. Today it is observers, tomorrow it is iterators etc.
Observer has been around for ages, it's not a today's flavour feature.
It's minimal addition with huge benefits.
So are iterators and umpteen other patterns. (like e.g. using
Marco van de Voort het geskryf:
I'm against. This is a sliding slope. Michael agreeing to this surprises me
a bit.
Michael was the one that suggested it to Joost and myself. :) The usage of
Observer in base classes might even completely eliminate the need for
DB-aware components.
After I
In our previous episode, Graeme Geldenhuys said:
Marco van de Voort het geskryf:
I'm against. This is a sliding slope. Michael agreeing to this surprises me
a bit.
Michael was the one that suggested it to Joost and myself. :) The usage of
Observer in base classes might even completely
On Wed, 19 May 2010, Marco van de Voort wrote:
In our previous episode, Graeme Geldenhuys said:
Marco van de Voort het geskryf:
I'm against. This is a sliding slope. Michael agreeing to this surprises me
a bit.
Michael was the one that suggested it to Joost and myself. :) The usage of
Marco van de Voort het geskryf:
Note that I was mainly talking about any object types that are designed to
be Delphi compatible.
Like I said, they will not interfere with Delphi compatibility at all
because Delphi doesn't have such a feature. [yet many other
toolkits/frameworks do] The usage
On Wed, 2010-05-19 at 16:21 +0200, Graeme Geldenhuys wrote:
Marco van de Voort het geskryf:
Note that I was mainly talking about any object types that are designed to
be Delphi compatible.
I really don't see a the problem here. FPC often implements things that
have far greater chances
On Wed, 2010-05-19 at 16:43 +0200, Graeme Geldenhuys wrote:
Joost van der Sluis het geskryf:
That wasn't a new feature, but a bug-fix. Which was abused (used without
seeing the consequences) a lot.
Well as far as I know it never worked, so I cannot see how it could every
have been
In our previous episode, Michael Van Canneyt said:
I don't care about such schemes being used in code that is not Delphi compat
(fpgui, fpweb etc). I wouldn't like it for the database components or LCL
components though.
The problem is that this pretty much rules out the use of the
On Wed, 2010-05-19 at 16:59 +0200, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
I don't care about such schemes being used in code that is not Delphi
compat
(fpgui, fpweb etc). I wouldn't like it for the database components or LCL
components though.
Marco van de Voort het geskryf:
System quo what where? The current libs are mainly about compatibility, and
because of that e.g. many language extensions from D4+ were never introduced
You are totally over exaggerating. If FPC's only design goal is to be
compatible with Delphi, there is NO
In our previous episode, Joost van der Sluis said:
System quo what where? The current libs are mainly about compatibility, and
because of that e.g. many language extensions from D4+ were never introduced
into the system (which is why e.g. the LCL uses TStrings instead of a
minimal
On 19 May 2010 17:36, Marco van de Voort wrote:
I don't see why the observer pattern is needed at such low level any more
than 20 other little handy features that each would be a lot easier if they
just had a field/property in the baseclasses.
Marco, not trying to be rude, but please take a
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.
Michael, I have two options to solve this:
1) Ignore Marco and
On Wed, 19 May 2010, Joost van der Sluis wrote:
On Wed, 2010-05-19 at 16:59 +0200, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
I don't care about such schemes being used in code that is not Delphi compat
(fpgui, fpweb etc). I wouldn't like it for the
On 20 Mei 2010, at 24:24, Michael Van Canneyt wrote:
there must be progress in FPC; we don't want to keep running behind Delphi
forever.
Compatibility: absolutely. But also: progress and enhancements !
Just to give some supports... I'm with Michael and Graeme here. I don't know
about the
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 from real-world examples).
And my prototype implementation of TActions
In our previous episode, Graeme Geldenhuys said:
I don't see why the observer pattern is needed at such low level any more
than 20 other little handy features that each would be a lot easier if they
just had a field/property in the baseclasses.
Marco, not trying to be rude, but please
In our previous episode, Michael Van Canneyt said:
about compatibility. But if I want to replace
TComponent/TControl/TPersistent with newer versions, I would start
copy-pasting them. And there would be only a few changes. (I can't think
of any now, expect for adding the ability to use the
Sent from my iPhone
On 19 May 2010, at 17:52, Graeme Geldenhuys graemeg.li...@gmail.com
wrote:
On 19 May 2010 17:36, Marco van de Voort wrote:
I don't see why the observer pattern is needed at such low level
any more
than 20 other little handy features that each would be a lot easier
Sent from my iPhone
On 19 May 2010, at 17:59, Graeme Geldenhuys graemeg.li...@gmail.com
wrote:
Michael, I have two options to solve this:
1) Ignore Marco and implement it any way. I think you have just as
much say as Macro on what goes into the FPC.
2) Do something similar to what we
Graeme Geldenhuys schreef:
@Michael van Canneyt
Have we come to a decision about Observer support in FPC base classes?
This would obviously help what I am doing now as well - but I guess
something like that will not make it into FPC 2.4.2 even if the answer is
yes for Observer in base
Matt Emson wrote:
I don't think so. I'd hate to see any specific pattern being implemented
at a base level. Why? Exactly what Marco said. Patterns are faddy - you
are not going to please everyone. I'd rather see a mechanism for
injecting first class extensions to existing classes. That way,
19.05.2010 23:56, Sergei Gorelkin:
Matt Emson wrote:
I don't think so. I'd hate to see any specific pattern being
implemented at a base level. Why? Exactly what Marco said. Patterns
are faddy - you are not going to please everyone. I'd rather see a
mechanism for injecting first class
Le 19 mai 2010 19:33:14 UTC, Matt Emson memson.li...@googlemail.com a écrit :
Sent from my iPhone
On 19 May 2010, at 17:52, Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 19 May 2010 17:36, Marco van de Voort wrote:
I don't see why the observer pattern is needed at such low level any
In our previous episode, Vincent Snijders said:
@Michael van Canneyt
Have we come to a decision about Observer support in FPC base classes?
This would obviously help what I am doing now as well - but I guess
something like that will not make it into FPC 2.4.2 even if the answer is
yes
On Wed, 19 May 2010, Marco van de Voort wrote:
While that solves at least the worst compatibility issues. I still think it
is a weak and redundant attempt.
If the current situation is so horribly dire that you can't really do
without it, such a bandaid is not enough.
IMHO this is some not
On Wed, 19 May 2010, Marco van de Voort wrote:
In our previous episode, Vincent Snijders said:
@Michael van Canneyt
Have we come to a decision about Observer support in FPC base classes?
This would obviously help what I am doing now as well - but I guess
something like that will not make
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
structure way more complex because their is no
On 19 May 2010 16:26, Graeme Geldenhuys graemeg.li...@gmail.com wrote:
would be like rewriting the whole RTL and FCL! To quote the famous Florian
saying: you have no clue what you are talking about.
I feel the need to disagree here, since Marco does know what he's
talking about (in my
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
classes of the FCL and LCL, without duplicating all
On 19 May 2010 23:02, Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 19/05/2010, Henry Vermaak wrote:
not qualified to add to this discussion, but I feel we can reach a
good solution without feeling the need to hit each other upside the
head.
Well, seeing that Marco and Florian are
On 19/05/2010, Marco van de Voort wrote:
First: I don't see an urgent need for such draconic measures.
So Michael having to wait 10 years to see it implemented is called
urgent in your eye? :)
Second: I don't see a good solution, exactly because the whole framework was
not designed for
In our previous episode, Graeme Geldenhuys said:
Marco might know the RTL, but so do others. I also know class design
and design patterns very well - both are my passion in programming. So
I believe I know what I am talking about as well when I say the
Observer is very useful in the base
On 20/05/2010, Henry Vermaak wrote:
enough technical basis, you will convince people. Like Linus says,
talk is cheap, show me the code.
You are welcome to look at the tiOPF code.
http://sourceforge.net/projects/tiopf/
I also attached a simplified example to my previous reply to Macro and
On 20/05/2010, Marco van de Voort wrote:
I've an own copy of GoF btw.
Owning a copy doesn't meant you read it or understood it. ;-)
However knowing and even appreciating a certain
pattern doesn't automatically mean it should be implemented at all costs.
I believe Michael and I have listed
In our previous episode, Graeme Geldenhuys said:
I've an own copy of GoF btw.
Owning a copy doesn't meant you read it or understood it. ;-)
Yeah. Studying means neither.
However knowing and even appreciating a certain
pattern doesn't automatically mean it should be implemented at all
On 20/05/2010, Marco van de Voort mar...@stack.nl 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 training workshops on the subject. I think
92 matches
Mail list logo
