Graeme Geldenhuys wrote:
Simple one liners like the following:
inc(FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots,
itm.CountSlots);
or
FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots += itm.CountSlots;
now has to change to this ugly line...
FDayList[itm.WeekDayN
Jonas Maebe wrote:
Indeed. I've checked the code and properties are explicitly not allowed
for the C-style operators. The reason is that the x+=y is translated
into "x:=x+y" at the parser level rather than at the lexical level. This
So I guess the obvious question is: would it be risky to cha
On 17 Jul 2008, at 08:41, Graeme Geldenhuys wrote:
Simple one liners like the following:
inc(FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots,
itm.CountSlots);
or
FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots +=
itm.CountSlots;
now has to change to this ugly line
Op Thu, 17 Jul 2008, schreef Micha Nelissen:
Graeme Geldenhuys wrote:
Simple one liners like the following:
inc(FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots,
itm.CountSlots);
or
FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots +=
itm.CountSlots;
now has to ch
On 17 Jul 2008, at 08:48, Graeme Geldenhuys wrote:
On Wed, Jul 16, 2008 at 5:37 PM, Jonas Maebe <[EMAIL PROTECTED]
> wrote:
Indeed. I've checked the code and properties are explicitly not
allowed for
the C-style operators. The reason is that the x+=y is translated into
"x:=x+y" at the parser
On 17 Jul 2008, at 09:09, Daniël Mantione wrote:
Even shorter:
with itm do
with FDayList[WeekDayNum].Rows[Timeslot] do
AvailableSlots:=AvailableSlots+CountSlots;
Even shorter:
with itm, FDayList[WeekDayNum].Rows[Timeslot] do
AvailableSlots:=AvailableSlots+CountSlots;
But nested or c
On Thu, Jul 17, 2008 at 9:05 AM, Micha Nelissen <[EMAIL PROTECTED]> wrote:
>> Simple one liners like the following:
>>
>> inc(FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots,
>> itm.CountSlots);
>> or
>> FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots +=
>> itm.CountSlots;
On Thu, Jul 17, 2008 at 9:07 AM, Micha Nelissen <[EMAIL PROTECTED]> wrote:
> Jonas Maebe wrote:
>>
>> Indeed. I've checked the code and properties are explicitly not allowed
>> for the C-style operators. The reason is that the x+=y is translated into
>> "x:=x+y" at the parser level rather than at t
On Thu, Jul 17, 2008 at 9:09 AM, Jonas Maebe <[EMAIL PROTECTED]> wrote:
> Or
>
> with FDayList[itm.WeekDayNum].Rows[itm.Timeslot] do
> AvailableSlots:= AvailableSlots+itm.CountSlots;
No that's one language construct I wish Object Pascal could do
without! I personally hate the 'with' statement,
On Thu, Jul 17, 2008 at 9:38 AM, Graeme Geldenhuys
<[EMAIL PROTECTED]> wrote:
> At least FPC with mode objfpc had the common sense NOT to allow the
> following (which I believe is still allowed in Delphi). Also tooltip
> evaluation/debugging doesn't work with 'with' statements in Lazarus or
> Delp
2008/7/17 Jonas Maebe <[EMAIL PROTECTED]>:
> Even shorter:
>
> with itm, FDayList[WeekDayNum].Rows[Timeslot] do
> AvailableSlots:=AvailableSlots+CountSlots;
Arg [grinding my teeth]
Nested with statements are even worse than my previous complaint! ;-)
Regards,
- Graeme -
__
Op Thu, 17 Jul 2008, schreef Graeme Geldenhuys:
On Thu, Jul 17, 2008 at 9:09 AM, Jonas Maebe <[EMAIL PROTECTED]> wrote:
Or
with FDayList[itm.WeekDayNum].Rows[itm.Timeslot] do
AvailableSlots:= AvailableSlots+itm.CountSlots;
No that's one language construct I wish Object Pascal could do
wi
Graeme Geldenhuys wrote:
My question too Would somebody be so kind as to explain the
difference to me? As I mentioned before, I'm not a compiler
developer.
Very rudimentary:
source --lexer--> tokens --parser--> tree --code gen--> code
- source is the .pas file etc.
- tokens are things
This is if you like the risk of using "with" ;-)
This works until somebody changes the FDayList[WeekDayNum].Rows[Timeslot] to
contain CountSlots property, and all your code is broken ;-) .
If you want stable code, never use the "with" or else ... ;-)
With best regards,
Boian Mitov
If you want stable code, never use the "with" or else ... ;-)
I did learn this even in the early Delphi days ;)
Moreover AFAIK, even the newest Delphi does not show the value of
variables that are qualified using a "with". So you even can't debug the
broken code decently.
-Michael
There are a lot of fans of "with" ;-) . I have been burned however long time
ago. Now when I get a new code from somebody, my first task is to remove any
"with" from it ;-). As far as I am concerned "with" is a Pascal design bug.
May the guy who invented "with" track "with" bugs for eternity ;-)
Boian Mitov wrote:
There are a lot of fans of "with" ;-) . I have been burned however
long time ago. Now when I get a new code from somebody, my first task
is to remove any "with" from it ;-). As far as I am concerned "with"
is a Pascal design bug. May the guy who invented "with" track "with"
You will hardly find any in our components ;-) . Not as long as I run the
company, and do most of the work. I even plan to add preprocessor to catch
missed "with" during the build process.
With best regards,
Boian Mitov
M
Or Add a Method to the target object. (as long as it is part of your
code base, or can be modified by you)
and then do
FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlotsInc(itm.CountSlots);
In the class that defines
property AvailableSlot;
you can add
procedure AvailableSlotsInc(n : I
From my understanding ( the fpc team probably can to more exact):
* lexical level
This would be like a simple "Find and Replace" on the text. This would
work with anything, as it doesn't know what it is translating.
(It is very similar to a (non-buildin) C-preprocessor)
* parser level
The pars
Graeme Geldenhuys wrote:
So is what you mentioned above by design, or an oversight? In normal
code like "x := x+y" you are allowed to use properties or variables.
So surely the += operator which translates to "x := x+y" should also
be allowed to use properties.
Except that, when using variabl
Sean McIlwain schrieb:
The following code fails to compile in Delphi mode but successfully
compiles in objfpc mode:
type
TEnum = (a, b, c);
var
AValue: TEnum;
AObject : TObject;
implementation
initialization
AObject := TObject(AValue);
Could this be supported in the Delphi mode as well?
Sean McIlwain wrote:
initialization
AObject := TObject(AValue);
Could this be supported in the Delphi mode as well?
Forgot to take your pills today? ;)
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mail
This needs to be applied from the trunk directory. All very minor changes...
Changes include
* Minor classname adjustment
* Query.SQL.Text ---> Query.SQLText otherwise the setter method is
bypassed, which could contain custom code.
* uses clause cleanup
Regards,
- Graeme -
__
> Matthias Gaertner wrote:
I'm getting a Error: Incompatible Types: got "untyped" expected
" when
compiling the following code. This happens when using default
parameter values.
Use mode objfpc and CallBack:[EMAIL PROTECTED]
Is there some reason why this can't be handled automatically in D
Craig Peterson wrote:
Use mode objfpc and CallBack:[EMAIL PROTECTED]
Is there some reason why this can't be handled automatically in Delphi
mode? In the example (and every case where it's an issue in our code),
the callback is a procedure and doesn't return anything, so "Callback :=
Proc" i
Micha Nelissen wrote:
Ambiguity depends on whether it takes parameters or not. Return value
would be context sensitive. One doesn't want a context sensitive language.
The code presented is perfectly valid in Delphi, so it apparently *is* a
context sensitive language, and I'm sure we're not the
Craig Peterson wrote:
Micha Nelissen wrote:
Ambiguity depends on whether it takes parameters or not. Return value
would be context sensitive. One doesn't want a context sensitive
language.
The code presented is perfectly valid in Delphi, so it apparently *is* a
context sensitive language, an
> Yes but this has got nothing to do with original poster's problem :-).
Sean (the original poster) is my coworker, so his problem and mine are
one and the same. ;-) I'm having a little trouble parsing your
responses though, so to clarify:
In Delphi, the following code works:
procedure Bt
> > Yes but this has got nothing to do with original poster's problem :-).
>
> Sean (the original poster) is my coworker, so his problem and mine are
> one and the same. ;-) I'm having a little trouble parsing your
> responses though, so to clarify:
>
> In Delphi, the following code works:
>
>
El Thu, 17 Jul 2008 09:15:46 +0200
Jonas Maebe <[EMAIL PROTECTED]> escribió:
> But nested or combined with-statements can be dangerous in case
> there are multiple fields with the same name in the different
Many, many years ago, I programmed in texas instruments' pascal for the
9995. Of course it
On Thu, 17 Jul 2008, Florian Klaempfl wrote:
> Sean McIlwain schrieb:
> > The following code fails to compile in Delphi mode but successfully compiles
> > in objfpc mode:
> >
> > type
> > TEnum = (a, b, c);
> > var
> > AValue: TEnum;
> > AObject : TObject;
> > implementation
> >
> > initiali
On Thu, 17 Jul 2008, Graeme Geldenhuys wrote:
> This needs to be applied from the trunk directory. All very minor changes...
>
> Changes include
>
> * Minor classname adjustment
> * Query.SQL.Text ---> Query.SQLText otherwise the setter method is
> bypassed, which could contain custom code
Michael Van Canneyt wrote:
>>> AObject := TObject(AValue);
>>>
>>> Could this be supported in the Delphi mode as well?
>> Please submit a bug report.
>
> Eh ?
> As far as I'm concerned this should not compile in Objfpc mode as well ?
It's a typecast, so then almost anything is allowed, except p
ik schrieb:
> In hebrew (at least) the punctuation is a different char that comes
> after the letter, but painted like it was part of the letter, so you
> can parse each word and ignore non letter value (it arrives in
> different range in the unicode table).
>
>
>
Yes, the question is: which are
On Wed, Jul 16, 2008 at 4:09 PM, theo <[EMAIL PROTECTED]> wrote:
> Is there a better way to do what I need?
I think that writing such a routine which compares the char to a table
will be the best solution.
--
Felipe Monteiro de Carvalho
___
fpc-devel m
Felipe Monteiro de Carvalho schrieb:
>
> I think that writing such a routine which compares the char to a table
> will be the best solution.
>
>
Yes, I've done this today. http://www.theo.ch/lazarus/woprsplitwords.pas
It seems to work. Do you see any problems?
Thanks
Theo
Micha Nelissen wrote:
Michael Van Canneyt wrote:
AObject := TObject(AValue);
Could this be supported in the Delphi mode as well?
Please submit a bug report.
Eh ?
As far as I'm concerned this should not compile in Objfpc mode as well ?
It's a typecast, so then almost anything is allowed, ex
Now only if we can go ~15 years back in time and tell that to the original
developers of VCL and things like TStrings and their data type ;-) .
Unfortunately they take TObject only, and there are a lot of cases when
casting other data types to it is needed. I wish it was not the case, but it
is
Boian Mitov wrote:
Now only if we can go ~15 years back in time and tell that to the
original developers of VCL and things like TStrings and their data type
;-) . Unfortunately they take TObject only, and there are a lot of cases
when casting other data types to it is needed. I wish it was not
40 matches
Mail list logo
