On Wed, 19 May 2010, 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 to set the value programatically.
But while investigating why TAutoIncField.ReadOnly always returns false, i
found that, regardles
Florian Klaempfl het geskryf:
>
> At least we try to avoid it to make it people too easy to shoot themself
> into the foot.
Developers should be free to shoot themselves wherever they want! It should
be their choice, not yours. :-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform
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 to set the value programatically.
>
> But while investigating why TAutoIncField.ReadOnly always returns false,
> i fo
On 2010-05-19 10:33, Graeme Geldenhuys wrote:
Florian Klaempfl het geskryf:
At least we try to avoid it to make it people too easy to shoot themself
into the foot.
Developers should be free to shoot themselves wherever they want! It should
be their choice, not yours. :-)
Graeme,
In our previous episode, Graeme Geldenhuys said:
> > At least we try to avoid it to make it people too easy to shoot themself
> > into the foot.
>
>
> Developers should be free to shoot themselves wherever they want! It should
> be their choice, not yours. :-)
You can shoot yourself in the foot
Adem het geskryf:
> overlooking the fact that there are special/edge cases where your spouse
> (or significant other) may fiercely object to.
Ah yes, I forgot about exception handling! :-/
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://openso
On 05/18/2010 06:51 PM, Den Jean wrote:
> Note how I say c-functions and not c++ functions.
OK, But your code is
procedure of object;CDecl;
i.e. using a C ABI for a class function.
If the compiler does digest this, the meaning supposedly is that the
procedure gets an additional, supposedly firs
On 19 May 2010, at 03:35, Vinzent Höfler wrote:
Jonas Maebe :
Then again, for
some 10 or more years nobody thought of how the old behaviour allowed
subverting the complete type checking model of the compiler either
(which is why "useless restriction from Delphi" probably wasn't
implemented in
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 function
to existing classes. Without this fix, it's not possible.
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 Observ
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 a
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 repo
Hi Michael,
* Shouldn't Specifiers be mentioned in the Language Reference doc chapter
1? Similar to modifiers - they are not reserved words, but also not
encouraged to use as identifiers.
* Properties, section 4.6, of the Language Reference documentation doesn't
mention the 'implements' specifier
Graeme Geldenhuys het geskryf:
>
> * Properties, section 4.6, of the Language Reference documentation doesn't
> mention the 'implements' specifier in the diagram (page 54). Its got read,
> write and default, but not implements.
Sorry, I see this chapter is related to global variables, and 'implem
On 19 May 2010, at 14:34, Graeme Geldenhuys wrote:
BTW: I actually learnt something new now. I never new you could have a
property outside a class. I can't say that in the many years I have
been
programming with object pascal that I have ever seen properties used
as a
global variable. Umm?
Jonas Maebe het geskryf:
>
> It's an FPC-specific extension. It's mainly used to implement the
> "port" construct from Turbo Pascal in the ports unit for Dos and Linux.
And you answered by next question before I could even ask it. :) I was
looking for syntax help on that in the Kylix 3 help an
In our previous episode, Jonas Maebe said:
> > BTW: I actually learnt something new now. I never new you could have a
> > property outside a class. I can't say that in the many years I have
> > been
> > programming with object pascal that I have ever seen properties used
> > as a
> > global var
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. usi
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 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 co
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
Obs
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 usag
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
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 called implemented/completed. That "bug-fix" actually made it
work, a
On 19 May 2010, at 16:21, Graeme Geldenhuys wrote:
I really don't see a the problem here. FPC often implements things
that
have far greater chances of breaking existing code - I just pointed
out
another such example a few days ago.
I don't have an opinion on the current discussion, but yo
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
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
Graeme Geldenhuys schrieb:
> Florian Klaempfl het geskryf:
>> At least we try to avoid it to make it people too easy to shoot themself
>> into the foot.
>
>
> Developers should be free to shoot themselves wherever they want! It should
> be their choice, not yours. :-)
Then you should switch to
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
> > > component
On Wed, May 19, 2010 at 12:16 PM, Florian Klaempfl
wrote:
> Graeme Geldenhuys schrieb:
>> Florian Klaempfl het geskryf:
>>> At least we try to avoid it to make it people too easy to shoot themself
>>> into the foot.
>>
>>
>> Developers should be free to shoot themselves wherever they want! It shou
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 i
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
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 im
Michael Van Canneyt escreveu:
On Wed, 19 May 2010, 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 to set the value programatically.
But while investigating why TAutoIncField.ReadOnly always returns
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 to set the value programatically.
But while investigating why TAutoIncField.ReadOnly a
2010/5/19 Flávio Etrusco :
>
> Sometimes I just don't when Graeme is kidding.
The rules are simple. If there is some form of "smiley face", then I
am just kidding.
[..but clearly some developers here in the FPC & Lazarus mailing list
have some or other "smiley face filter" in their email clients,
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 database
Florian Klaempfl :
> This was *never* possible as far as I remember, so nothing changed here
> and no reason to complain that existing code gets havoc as Graeme
> feared.
If my memory doesn't play nasty tricks on me, I was using this pattern in the
past, so I'd say it was possible somewhere betw
Graeme Geldenhuys :
> Florian Klaempfl het geskryf:
> >
> > At least we try to avoid it to make it people too easy to shoot
> > themself into the foot.
>
> Developers should be free to shoot themselves wherever they want! It
> should be their choice, not yours. :-)
In that respect I'm 100% wi
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 s
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 ple
On Wed, May 19, 2010 at 2:37 PM, "Vinzent Höfler"
wrote:
> Graeme Geldenhuys :
>
>> Florian Klaempfl het geskryf:
>> >
>> > At least we try to avoid it to make it people too easy to shoot
>> > themself into the foot.
>>
>> Developers should be free to shoot themselves wherever they want! It
>> sho
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 u
Sent from my iPhone
On 19 May 2010, at 17:52, Graeme Geldenhuys
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
if they
just had a fi
Sent from my iPhone
On 19 May 2010, at 17:59, Graeme Geldenhuys
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 did with tiOPF and Interfa
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 classes?
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, i
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 extensions
Le 19 mai 2010 19:33:14 UTC, Matt Emson a écrit :
>
>
> Sent from my iPhone
>
> On 19 May 2010, at 17:52, Graeme Geldenhuys 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
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
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 t
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 it
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
On 19 May 2010 16:26, Graeme Geldenhuys 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 experience), not least as one
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
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 very quick to call people
clueless and bash them in public - I thought
On 19 May 2010 23:02, Graeme Geldenhuys 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 very quick to
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
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 cl
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 an
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 liste
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
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 training workshops on the subject. I think
I have a good
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 a typical sample of change required to pro
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
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, the famous "class help
69 matches
Mail list logo
