According to the docs the with statement when used with mulltiple objects only works with the last parameter.

The statement
With A,B,C,D do Statement;
is equivalent to
With A do
 With B do
  With C do
   With D do Statement;

El 13/09/14 20:13, vfclists . ha escrit:

I thought all the 3 labels would have the caption set, but only Label3's caption is set. Is this a difference between Delphi's Object Pascal and FreePascal, or has Delphi's Object Pascal always worked in the same manner?

The "with" syntax comes from plain old pascal and it has always worked this way.

http://books.google.co.uk/books?id=xXSZbSLFTM8C&lpg=PP1&hl=ca&pg=PA73#v=onepage&q&f=false

Bye

It has always worked in this manner. It's just for abbreviating typing, not for combining properties. (and then the with-variant with multiple elements is even more seldomly used than the single-element one...)

Regards,
Sven

What then is the nesting for if the command will only apply to the last item with the property? Is each nested element supposed to be a property of the enclosing element?

What is the rationale for such a statement, ie using multliple elements?

Consider this example:

=== code begin ===

type
   TTest1 = class
     procedure Foo;
   end;
   TTest2 = class
     proceduer Bar;
   end;
// implementation of TTest1 and TTest2
var
   t1: TTest1;
   t2: TTest2;
begin
   with t1, t2 do begin
     Foo; // calls t1.Foo
     Bar; // calls t2.Bar
   end;
   // same as:
   with t1 do begin
     with t2 do begin
       Foo;
       Bar;
     end;
   end;
end.

=== code end ===

"with" simply allows you to avoid some typing and evaluatios the expression between the "with" and "do" only once (take a function for example instead of "t1"). So mostly it's merely syntactic sugar.

Regards,
Sven

[...] What then is the nesting for if the command will only apply to the last item with the property?

The compiler searches the identifier in the last With, then in the second last With, ..., then in the local variables, then in the parameters and so forth.

Is each nested element supposed to be a property of the enclosing element? What is the rationale for such a statement, ie using multliple elements?

Less typing.

Mattias

Mattias Gaertner wrote

Less typing.

Just some generic comments in general.

Its also much harder to understand in the long run and it can even be dangerous as stuff migh be refactored over time. All seasoned programmers know that and try to avoid the with statement.

Mattias Gaertner wrote

> What is the rationale for such a statement, ie using multliple elements? Less typing.

...and increases grey hair growth (due to lots more trouble debugging). :-)

Regards,
- Graeme -

Marius wrote

programmers know that and try to avoid the with statement.

+1

Regards,
- Graeme -

Marius wrote

Mattias Gaertner wrote: All seasoned programmers know that and try to avoid the with statement.

Realy? I love it. Consider these two varianst of code from one of my programs:

---------------------------------------------------------
with TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^ do
    begin
    DirLogged             := true;
    DirHatFocus           := false;
    SubDirsExpanded       := true;
    NonLoggedDirsInBranch := 0;
    LastSubDirIndex       := -1;
    ErrorString           := '';
    fillchar(StatistikOfFiles,sizeof(StatistikOfFiles),0);
    fillchar(StatistikOfDirs ,sizeof(StatistikOfDirs) ,0);
    Verzeichnis           := Form1.Verzeichnisbaum.RootNode;
    DirName               := DirectorySeparator;
    DirNameLowerCase      := LowerCase(DirName);
    TRightMostPeriod      := 0;
    DirSize               := 0;
    TFileAttributes       := 0;
    fillchar(TDateWritten,sizeof(TDateWritten),0);
    TFlagSet              := [];
    SubDirs               := nil;
    Files                 := nil;
    end;
---------------------------------------------------------

and

---------------------------------------------------------
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.DirLogged             := true;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.DirHatFocus           := false;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.SubDirsExpanded       := true;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.NonLoggedDirsInBranch := 0;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.LastSubDirIndex       := -1;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.ErrorString           := '';
fillchar(TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.StatistikOfFiles,sizeof(TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.StatistikOfFiles),0);
fillchar(TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.StatistikOfDirs ,sizeof(TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.StatistikOfDirs) ,0);
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.Verzeichnis           := Form1.Verzeichnisbaum.RootNode;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.DirName               := DirectorySeparator;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.DirNameLowerCase      := LowerCase(DirName);
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.TRightMostPeriod      := 0;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.DirSize               := 0;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.TFileAttributes       := 0;
fillchar(TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.TDateWritten,sizeof(TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.TDateWritten),0);
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.TFlagSet              := [];
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.SubDirs               := nil;
TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^.Files                 := nil;
---------------------------------------------------------

Which one would you prefer?
The first one is *much* less error prone because it is easier to read and makes it therefore clearer than the second example. Also, the calculation of the pointer is done multiple times in the second example which makes the code slower.

I love Pascal also because of the WITH statement.
The risks are the same as when using multiple units which define identical named identifiers.

Am 2014-09-13 22:31, schrieb Marius: > Mattias Gaertner wrote: > All seasoned programmers know that and try to avoid the with statement.

The quote is from Marius, not from me.

and

---------------------------------------------------------
d:=TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]; // local var d
d^.DirLogged             := true;
d^.DirHatFocus           := false;
d^.SubDirsExpanded       := true;
[...] ---------------------------------------------------------

Mattias

Mattias Gaertner wrote

> > All seasoned programmers know that and try to avoid the with statement. The quote is from Marius, not from me.

Correct. I deleted the wrong reference. ;-(

Long-winded and still not the same clarity as in the with statement.

Do you also prepent *all* function and variable names with the unit name they come from?
Do you realy *always* write

LazUTF8.UTF8Delete
instead of
UTF8Delete
?

Nested WITH statements and the unit concept share the same problem but still the benefits outweigh the drawbacks IMO (once you get used to it and keep possible problems in mind).

Am 14.09.2014 09:36 schrieb "Graeme Geldenhuys" <

: On 2014-09-13 21:04, Mattias Gaertner wrote: >> What is the rationale for such a statement, ie using multliple

elements?

> Less typing. ...and increases grey hair growth (due to lots more trouble debugging).

:-)

Though to be honest Lazarus handles with-statements in context of debugging much more gracefully than Delphi...

Regards,
Sven

El 14/09/14 12:22, Jürgen Hestermann ha escrit:

As I say every time this discussion comes up ;-), TI pascal had the best of both worlds: you could either use the naked with or a named with, which removed ambiguity, i.e.

with a=Label1,b=Label2 do
  a.caption:=b.caption;

(OK, it's a contrived example but you get the drift).

Bye

Jürgen Hestermann wrote

Realy? I love it. Consider these two varianst of code from one of my programs:

This is a simpler example than the one with with the 4 levels deep (which can be quite a puzzle if there are multiple records containing the same fieldname(s)). And yes you may love them but please read on..

Which one would you prefer?

The second, but not for readability or typing, I would suggest a third solution by using a variable (like Matthias also showed).

The point is you are very likely to run into refactoring problems. Suppose your routines are in 2 different methods in a class and there is class inheritance and one of the base class has a property errorstring. Suppose you decide to refactor the errorstring in you record structure to something else (and forget to adjust it properly which is human). Your first solution will compile but it would reset the wrong errorstring, your second solution will simply not compile because it has been prefixed (hence my preference to pick that one). You can argue its the fault of the programmer but why create an unsafe situation in the first place (and that just what the with statement does)...

We have spend weeks (if not months) off hunting down this kind of bugs. And its this kind of bug what showed up frequently in teams of programmers and that made us decide to ban the with statement as much as possible. Sooner or later the with stament is going to bite you, I just hope you wont have to spend that much time on resolving it ;(

Marius

Good point, as far as i know there is not a solid solution for units unless those global procedures like utf8delete where rewritten as class procedures.

Marius

In our previous episode, J?rgen Hestermann said:

But the important part is that it forces each property/field to be a member of T, or get a compiler error.

WITH doesn't, and you risk that if your class or one of its ancestor has such property, and your error goes unnoticed.

+1. With statement was banned at my old job as well for exactly the reasons stated (by everyone :) )

Mike

-1. !!!

I like "with"!!!! ... even it may give trouble times to times!!! ... but I work alone on my programs ...

as always ... nothing
perfect! .... always should consider the conditions!!

Michael Thompson wrote

> We have spend weeks (if not

months) off hunting down this kind of bugs.

> And its this kind of bug

what showed up frequently in teams of

> programmers and that made us

decide to ban the with statement as much

> as possible. Sooner or later

the with stament is going to bite you, I

> just hope you wont have to

spend that much time on resolving it ;(

+1. With statement was

banned at my old job as well for exactly the reasons stated (by everyone :) )

fpc-pascal maillist -

http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal [1]

Links:
------
[1]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Hello All,

My two cents. The with statement is crystal clear for me. If newbies prefer to use different manners to code the things, that are free to do it. Using some kind of intermediate variable ? That's make to code difficult to understand, need do open begin/end blocks in some situations. With make the code very clear, probably helps the compiler a lot. Well used, it's 100% safe - I *never* encountered any problems with it in 25+ years of intensive programmation.

So, they with statement has at least one aficionados: me. Was the with statement present if the first versions designed by Wirth himself ?

Cheers, Ched'

The consensus is that it has to be used with caution. You get one vote, less a bit for calling those that disagree with you "newbies" :-)

I tend to use it if it will save more than around three repeated prefixes, but I'd be far happier if there were provision for declaring a temporary "shortcut" symbol:

with shortcut: TSomething= TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^ do
    begin
    shortcut.DirLogged             := true;
    shortcut.DirHatFocus           := false;
    shortcut.SubDirsExpanded       := true;
..

So, they with statement has at least one aficionados: me. Was the with statement present if the first versions designed by Wirth himself ?

I believe so, and he also overlooked the "dangling else" problem.

There's also this usage, which has plenty of pitfalls for the unwary or busy:

with TSomething.Create do begin
..
   Free
end;

WITH was present in the first PASCAL versions,
and it was used in the PASCAL compilers designed by Wirth et al. written in PASCAL in the late 60s and early 70s.

The possible dangers of using WITH are only very limited, compared to other languages, for example PL/1, where

- you don't need to declare variables, like in FORTRAN
- you can omit structure qualifiers, if the the structure components alone are unique
- if the structure component is A.B.C, you can write A.C, B.C or simply C, if it is unique in the program
- if there is both a simple variable C and a structure component A.C (C in an outer block),
I guess, A.C will be used, if you write only C (but I am not sure on this; hopefully there will be
a compiler warning)
- if you have a combination of vectors and structures, the order of structure components
and vector indices is not fixed, that is: A.C(N,M) is the same as A(N).C(M) is the same as
A(N,M).C ... regardless of the definition of the structures / vectors A and C.

You may read some old articles from Dijkstra and C.A.R. Hoare on this topic,
covering PL/1 ... it is very hard to write reliable programs using this language,
but it is still in use until today in very large banks and insurance companies.
I am using it in my everyday work.

So: I would use the PASCAL WITH statement with care, knowing its problems. PASCAL is far less dangerous than PL/1.

The other language which I use much is C. There you have other problems that PASCAL (and PL/1) don't have, that is: vector indices out of range, leading to
storage overwrites, and storage leaks, due to heavy use of dynamic memory allocation ...
which needs careful testing. Both PASCAL and PL/1 can be used with options that
control the vector indices, which is IMHO a great help in the early stages of program
development.

Kind regards

Bernd

Cheers, Ched'

In our previous episode, Ched said:

So, they with statement has at least one aficionados: me. Was the with statement present if the first versions designed by Wirth himself ?

Yes, but the problems are mostly because of the scoping complexity that OO extensions like classes add. Specially because it is almost custom to use a lot of the same named properties in classes.

Something that Wirth couldn't (and didn't have to) forsee.

In the past I had the same opinion about with (WITHs evilness is exaggerated) as many others, but once I bumped my head a few times while using OO frameworks that were either not of my design or very large, I basically stopped using it.

Hi,
 
once I came to troubles with "with":
 
procedure TForm1.StringGrid1SelectEditor(Sender: TObject; aCol, aRow: Integer; var Editor: TWinControl); begin
  with StringGrid1 do
    begin
      ...
      Editor:= ...;
      ...
    end;
end; 

because Editor is also public property of TStringGrid. Here would be solution to rename parameter to "AEditor".  
Vojtěch

The reason why I made these comparisons to PL/1:

PL/1 was designed in the mid 60s, and Wirth of course knew about PL/1, because he was at IBM at the time, and of course he was aware of the problems
and pitfalls of PL/1. By including the WITH statement into PASCAL, he probably
wanted to give the coders some possibilities for an abbreviation (similar to PL/1,
but avoiding most of the problems). As we look at it today, not all problems have been
avoided.

Of course, most inspirations for PASCAL came from ALGOL 60. But ALGOL 60 had no structures, so PL/1 was the natural source of inspiration, at that time.

Kind regards

Bernd

Marco van de Voort wrote

WITH doesn't, and you risk that if your class or one of its ancestor has such property, and your error goes unnoticed.

+1

Not to mention that you can't use tooltip debugging when it comes to the WITH statement - at least this was the case last time I tried (I don't use WITH, so it could have been a long time ago).

Regards,
- Graeme -

Sven Barth wrote

Though to be honest Lazarus handles with-statements in context of debugging much more gracefully than Delphi...

We all know Lazarus is way better that Delphi - so that's always good to know. :)

As already mentioned, human refactoring of WITH statements can, and has, caused lots of debugging issues afterwards. Two or more classes used in a with statement, both classes have the same property name - how the hell must the developer know (and the compiler for that matter) which one is meant where. Bottom line (for me), WITH gives more trouble than its worth, so I avoid it at all costs.

Regards,
- Graeme -

Why does Free Pascal not invent a safe "with" similar as the "with" of MSElang? If I would be cynical I could write "because one must wait until Delphi has it?". ;-)

Martin

Vojtěch Čihák wrote

because Editor is also public property of TStringGrid. Here would be solution to rename parameter to "AEditor".

Yes, that is a classic issue I have often come across.

Regards,
- Graeme -

In our previous episode, Martin Schreiber said:

> basically stopped using it. Why does Free Pascal not invent a safe "with" similar as the "with" of MSElang?

The primary question is of course if there is a need for a new construct at all. I don't know MSELang, but many new languages try to add new baroque constructs in a desperate attempt to draw users. I always found that doubtful.

If I would be cynical I could write "because one must wait until Delphi has it?". ;-)

Well, then if I were cynical, I would conclude that you don't read compatibility discussions carefully enough. A shame for somebody who wants to implement languages.

main problem seems to be using property whose name is common within 2 objects of the same "with" (or code within several "with")

could it
be controlled by a compiler option?

in that case compiler may return a
hint or warning or even an error depending of the choosen configuration ...

does this turn it safe, or safer?

Philippe

Martin Schreiber wrote

On Sunday 14 September 2014

Marco van de Voort wrote

> In the past I had the same

opinion about with (WITHs evilness is exaggerated) as many others, but once I bumped my head a few times while using OO frameworks that were either not of my design or very large, I basically stopped using it.

Why does Free Pascal not invent a safe "with" similar as the "with"

of

MSElang? If I would be cynical I could write "because one must

wait until

Delphi has it?". ;-) Martin

El 14/09/14 17:20, Marco van de Voort ha escrit:

I replied this morning about TI pascal (ca.1979), but for some reason I don't see it in the list.

Anyway

https://archive.org/stream/bitsavers_titm990100_41473222/MP351_MPP_UsersManual#page/n183/mode/2up

Bye

someone wrote about a better performance using "with". is that true? even with a simple pointer as in:

with ptr^ do
begin
prop1 := ...
prop2 := ...
end;

which should be faster then

ptr^.prop1 := ...
ptr^.prop1 := ...

others wrote it is just usefull to save writing
time ...

Luca Olivetti wrote

El 14/09/14

17:20, Marco van de Voort ha escrit:

> In our previous episode,

Martin Schreiber said:

> >>> basically stopped using it. >> Why

does Free Pascal not invent a safe "with" similar as the "with" of MSElang?

> The primary question is of course if there is a need for a

new don't know MSELang, but many new languages try to add new baroque constructs in a desperate attempt to draw users. I always found that doubtful.

I replied this morning about TI pascal

(ca.1979), but for some reason I

don't see it in the list.

Anyway

https://archive.org/stream/bitsavers_titm990100_41473222/MP351_MPP_UsersManual#page/n183/mode/2up [1]

Bye

Links:
------
[1]
https://archive.org/stream/bitsavers_titm990100_41473222/MP351_MPP_UsersManual#page/n183/mode/2up

Sven Barth wrote

It has always worked in this manner. It's just for abbreviating typing, not for combining properties. (and then the with-variant with multiple elements is even more seldomly used than the single-element one...)

In the Turbo Pascal days, WITH allowed for some user-directed compiler optimization. From the TP7 manual:

"In certain situations, Turbo Pascal's code generator can eliminate redundant pointer-load instructions, shrinking the size of the code and allowing for faster execution. When the code generator can guarantee that a particular pointer remains constant over a stretch of linear code (code with no jumps into it), and when that pointer is already loaded into a register pair (such as ES:DI), the code generator eliminates additional redundant pointer-load instructions in that block of code.

A pointer is considered constant if it's obtained from a variable parameter (variable parameters are always passed as pointers) or from the variable reference of a WITH statement. Because of this, using WITH statements is often more efficient (but never less efficient) than writing the fully-qualified variable for each component reference."

Take this example:

=== code begin ===

program twithtest;
type
   TTest = object
     procedure SetProp1(aValue: Integer);
     procedure SetProp2(aValue: Integer);
     property Prop1: Integer write SetProp1;
     property Prop2: Integer write SetProp2;
   end;
   PTest = ^TTest;
procedure TTest.SetProp1(aValue: Integer);
begin
end;
procedure TTest.SetProp2(aValue: Integer);
begin
end;
procedure TestWith;
var
   p: PTest;
begin
   New(p);
   with p^ do begin
     Prop1 := 42;
     Prop2 := 21;
   end;
   Dispose(p);
end;
procedure TestWithout;
var
   p: PTest;
begin
   New(p);
   p^.Prop1 := 42;
   p^.Prop2 := 21;
   Dispose(p);
end;
begin
end.

=== code end ===

This is the relevant code generated for TestWith:

=== asm begin ===

# [28] with p^ do begin
movl -4(%ebp),%ebx
# [29] Prop1 := 42;
movl %ebx,%eax
movw $42,%dx
call P$TWITHTEST_TTEST_$__SETPROP1$SMALLINT
# [30] Prop2 := 21;
movl %ebx,%eax
movw $21,%dx
call P$TWITHTEST_TTEST_$__SETPROP2$SMALLINT

=== asm end ===

and this for TestWithout:

=== asm begin ===

# [42] p^.Prop1 := 42;
movl -4(%ebp),%eax
movw $42,%dx
call P$TWITHTEST_TTEST_$__SETPROP1$SMALLINT
# [43] p^.Prop2 := 21;
movl -4(%ebp),%eax
movw $21,%dx
call P$TWITHTEST_TTEST_$__SETPROP2$SMALLINT

=== asm end ===

As you can see the expression p^ is only evaluated once in the TestWith case while it's evaluated twice in the TestWithout one. So it's only minimally faster in this example (one less memory access), but if you use enough members of TTest it a more or less tight loop it might even be noticeable.

Regards,
Sven

FPC optimizes this as well (because the with-expression is only evaluated once). Though it's arguable in how far that is a micro optimization with today's CPUs.

Regards,
Sven

Or if the reference is calculated for example in an array of record or a getter function.

Martin

Sven Barth wrote

On 14.09.2014 18:05, Philippe wrote: > someone wrote about a better performance using "with". is that true? > even with a simple pointer as in:

.
.

Have you tried to enable optimizations? Diff of the two code fragments generated with 2.6.4 and -O3:

--- t_with_o3.s Mon Sep 15 08:59:07 2014
+++ t_without_o3.s Mon Sep 15 08:59:32 2014
@@ -1,18 +1,14 @@
-# [26] New(p);
+# [40] New(p);
movl $0,%eax
call fpc_getmem
movl %eax,%ebx
-# [28] with p^ do begin
- movl %ebx,%esi
-# [29] Prop1 := 42;
- movl %esi,%eax
+# [42] p^.Prop1 := 42;
movw $42,%dx
call P$TWITHTEST_TTEST_$__SETPROP1$SMALLINT
- movl %esi,%eax
-# [t.pas]
-# [30] Prop2 := 21;
+# [43] p^.Prop2 := 21;
+ movl %ebx,%eax
movw $21,%dx
call P$TWITHTEST_TTEST_$__SETPROP2$SMALLINT
-# [33] Dispose(p);
+# [45] Dispose(p);
movl %ebx,%eax
call fpc_freemem

Note that there are actually more instructions generated for version using 'with' in this case (obviously depending on the context). In other words, the remark about micro-optimizations (which may not necessarily lead to expected results) applies here...

Tomas

Graeme Geldenhuys wrote

As already mentioned, human refactoring of WITH statements can, and has, caused lots of debugging issues afterwards.

If Dijkstra had written a letter to the CACM cautioning against the With statement, I wonder whether Wirth would have headlined it "With Statement Considered Harmful"? [Ref: EWD-1308]

Am 15.09.2014 09:08 schrieb "Graeme Geldenhuys" <

With Lazarus this works, which is what I meant in my other mail ;) In Delphi this AFAIK still does not work... (at least it did not in Delphi 2007)

Regards,
Sven

Bernd Oppolzer wrote

PL/1 was designed in the mid 60s, and Wirth of course knew about PL/1, because he was at IBM at the time, and of course he was aware of the problems and pitfalls of PL/1.

I didn't know that Wirth had been directly associated with IBM. I did know that while at Stanford he'd supervised Larry Breed who was writing the first fairly-complete computerised APL implementation, but my recollection is that they used FORTRAN since it was the only language that ran on the various computers that the involved parties had available.

http://infolab.stanford.edu/TR/CS-TR-66-47.html

I have to believe the WITH statement is more efficient than the C language equivalent where an extra
convenience pointer is declared as a variable and
allocated. The WITH statement allows the compiler to generate the same code as a fully qualified variable name without extra overhead in the form of a dummy pointer.

Just as the GOTO statement needs to be used with careful, close locality of scope, the WITH statement should be used when the fields will all come from the same record definition and ideally have distinct names. The safe approach would be to qualify all field references that are potentially ambiguous even while using a WITH statement.

The danger of surprises in scope evaluation for a simple and short variable name within a WITH statement scope are not that different from the danger of unit global
variables. Each unit creates its own local name space, which usually does the programmer a favor, but not always. Now the order units are referenced in the USES statement of each individual unit matters. What do you think happens when the programmer is casual about the USES order for helper utility units with duplicate global variable names?

Unit FooUtil1;
var ErrorString : string;

Unit BarUtil2

var ErrorString : string;
Unit CodeSection;
uses FooUtil1, BarUtil1;
procedure Main
begin
   ErrorString := ''; {Clears error string in last unit}
   .
   .
end;

This is a fragment I was using with multiple elements. So it means that all this time it was only working because all of them had been set at design time and the command was only applied to the last one.

I wonder where I got the impression that because they all shared the property the command applied to all of them.

  with qrySCParameters, qrySavedCommands, qryTemplateParameters,
    qryLiveCommands, qryLCParameters do
  begin
    Connection := dmCentral.localCommandsConnection;
  end;
    dmCentral.localCommandsConnection.Connected := True;

I am happy with the use of 'with' on a single element, but using it with multiple elements is plainly evil.

2014-09-14 16:23 GMT+02:00 Mark Morgan Lloyd <

Yes, something close to alias in SQL, instead of plain elision which "with" currently performs. This would allow for a clearer writing without the pitfalls of the Pascal "with".

could the compiler avoid "with" pitfalls?

now the compiler attach
a property to the closest "with" where it finds it.

the compiler could
check if the property appears in another "with" of the "with" stack and produce a message (hint, warning or error, which may be configurated).

is not it a way to make the "with" safe?

Frederic Da Vitoria wrote

2014-09-14 16:23 GMT+02:00 Mark Morgan

Lloyd :

> I'd be far happier if

there were provision for declaring a temporary "shortcut" symbol:

> >

with shortcut: TSomething= TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]^ do

> begin > shortcut.DirLogged := true; > shortcut.DirHatFocus :=

false;

> shortcut.SubDirsExpanded := true; Yes, something close to

alias in SQL, instead of plain elision which "with" currently performs. This would allow for a clearer writing without the pitfalls of the Pascal "with".

l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org [2]

2014-09-16 12:26 GMT+02:00 Philippe :

I don't think it would make it safe, only slightly safer. Imagine: you are using 2 nested "with" which have a field with the same name. The compiler would tell you so. You'd check and decide that it's OK because you really intended to mean the internal "with". Then, later, you remove or rename the field which is used in the internal "with". The compiler won't send you any warning since you will have removed a danger. But the meaning of your code will have changed and will now be wrong. Will you remember that there was a warning before and will you realize that the fact this warning disappeared means trouble?

How to get rid of the hint?

Mattias

2014-09-16 12:36 GMT+02:00 Frederic Da Vitoria :

Your suggestion would be safe if the option was configured to "error". Then, in such a situation, the developer would have to fully qualify each ambiguous field which should remove any chance of error.

Il 16/09/2014 12:26, Philippe ha scritto:

could the compiler avoid "with" pitfalls?

The "with" construct can be very handy, but should be used with caution, like a lot of other constructs, declarations, etc. E.g. for symbols present with the same name in different units, depending on the order of the uses declaration the one or the other will be picked up.

The IDE codetools provide already a powerful checking tool: you stop with the cursor on a symbol, and it tells you which reference will be taken. More than that would be an overkill: if you don't take the time to verify that your "with" does what you expect, you can't blame neither the construct nor the compiler.

Just my 5 cents

Giuliano

Either get rid of the "with" or use a compiler directive to disable it ;)

Regards,
Sven

2014-09-16 14:42 GMT+02:00 Sven Barth :

... or rewrite the offending reference so that the compiler won't complain.

I imagine that who really want to get rid from the hint ... don´t use Pascal anyway! or do have strong test tools!!!

one point is that
(many?) people use "with" ... and compiler can make it safer. may be as described Frederic Da Vitoria ... producing error when may be confused. (but let configure it!)

Philippe

Frederic Da Vitoria wrote

2014-09-16 14:42 GMT+02:00 Sven Barth

:

> Am 16.09.2014 12:37 schrieb

"Mattias Gaertner" :

> > > > On Tue, 16 Sep

2014 07:26:24 -0300

where it finds it.

> > > > > > the compiler could > > > check if the

property appears in another "with" of the "with" stack and

> > >

produce a message (hint, warning or error, which may be configurated).

> > > > > > > > > is not it a way to make the "with"

safe?

> > > > How to get rid of the hint? > > Either get rid of

the "with" or use a compiler directive to disable it ;)

> >

Regards,

> Sven ... or rewrite the offending reference so that the

compiler won't complain.

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org [2]

The issue is that when you introduce this hint, it is almost certain that someone will ask `how to disable that hint?` on this list.

IMO it would be a waste of time to implement such a thing. If I were a developer (hmm, actually I am one :-) ), and I would work on a project like FPC (meaning: in my free time, not getting paid to do the job), I would invest my time in something that actually means something, like fixing a bug, optimizing the RTL for a specific target, writing documentation, etc... We are programmers after all, not end users who want to be treated with silken gloves.

You've only got 10 choices really: either you like the `with` statement, or you don't. In the latter case don't use it. Remember that the original question was about functionality, what this thread has now evolved into is, in my opinion, off-topic.

(...)

(...)

I expected FPC would optimize this (with just -O1) :-(

-Flávio

on compiler implementation:

I read in this list that the group
lost months due a "with" problem.

People use "with", and I guess lot
of people use it!

I checked the reference
http://www.freepascal.org/docs-html/ref/refsu58.html#x155-16500013.2.8 and there is not any warning ... just:

The statement
With A,B,C,D do
Statement;
is equivalent to
With A do
 With B do
 With C do
 With
D do Statement;

without any warning ...

(and there is noting about
the syntax with xxx[ nn]^ = A do ... describe by someone earlier)

I am
not telling that an implementation in the compiler should be of higher priority!!! I appreciate a lot the great job that has been done, and is still going on! I know I won't be able to do it!!! I'ld really like to contribute ... but ... my age and qualification ... won't help very much!!!

But I am pretty sure that this implementation could have saved many time to many people (as one of the developper wrote) ... and still may save.

But as it has been written ... we may be out of subject!

Philippe

Ewald wrote

On 09/16/2014

Philippe wrote

> I imagine that who really want to get

rid from the hint ... don´t use Pascal anyway! or do have strong test tools!!! one point is that (many?) people use "with" ... and compiler can make it safer. may be as described Frederic Da Vitoria ... producing error when may be confused. (but let configure it!)

The issue is

that when you introduce this hint, it is almost certain

that someone

will ask `how to disable that hint?` on this list.

IMO it would be

a waste of time to implement such a thing. If I were a

developer (hmm,

actually I am one :-) ), and I would work on a project

like FPC

(meaning: in my free time, not getting paid to do the job), I

would

invest my time in something that actually means something, like

fixing

a bug, optimizing the RTL for a specific target, writing

documentation, etc... We are programmers after all, not end users who

want to be treated with silken gloves.

You've only got 10 choices

really: either you like the `with` statement,

or you don't. In the

latter case don't use it. Remember that the

original question was

about functionality, what this thread has now

evolved into is, in my

opinion, off-topic.

(...)

Why would it? As people replied in your thread, this has always been the behavior (at least in TP and Delphi), so if anything the only thing lacking is some minor documentation.
Also please don't hijack threads.

-Flávio

sorry ... hijacking is not my intention ... sorry.

Flávio Etrusco wrote

On Tue, Sep 16, 2014 at 8:09 PM,

Philippe wrote

> on compiler

implementation: I read in this list that the group lost months due a "with" problem. People use "with", and I guess lot of people use it! I checked the reference
http://www.freepascal.org/docs-html/ref/refsu58.html#x155-16500013.2.8 [1] and there is not any warning ... just: The statement With A,B,C,D do Statement; is equivalent to With A do With B do With C do With D do Statement; without any warning ...

(...) Why would it? As

people replied in your thread, this has always been

the behavior (at

least in TP and Delphi), so if anything the only

thing lacking is some

minor documentation.

Also please don't hijack threads. -Flávio

2014-09-17 3:11 GMT+02:00 Flávio Etrusco :

I guess different communities have different rules, but I don't understand (and I'd better understand if I don't want to do the same mistake): in what way was Philippe's post hijacking? This question goes to Philippe too, as he wrote "we may be out of subject" which shows he felt something wrong.

The mistake was actually mine :-$ I had deleted part of the thread and didn't realize this was the old thread.
Sorry Phillippe, and sorry for the noise everybody.

-Flávio

(tout excusé!) ....

Flávio Etrusco wrote

On Wed, Sep 17, 2014 at 4:38 AM, Frederic Da Vitoria

> 2014-09-17 3:11 GMT+02:00 Flávio

Etrusco :

> >> On Tue, Sep 16, 2014 at

Philippe wrote

>> >>> on compiler

implementation: I read in this list that the group lost months due a "with" problem. People use "with", and I guess lot of people use it! I checked the reference
http://www.freepascal.org/docs-html/ref/refsu58.html#x155-16500013.2.8 [1] and there is not any warning ... just: The statement With A,B,C,D do Statement; is equivalent to With A do With B do With C do With D do Statement; without any warning ...

>> (...) Why would it? As people

replied in your thread, this has always been the behavior (at least in TP and Delphi), so if anything the only thing lacking is some minor documentation. Also please don't hijack threads.

> I guess different

communities have different rules, but I don't understand (and I'd better understand if I don't want to do the same mistake): in what way was Philippe's post hijacking? This question goes to Philippe too, as he wrote "we may be out of subject" which shows he felt something wrong. -- Frederic Da Vitoria (davitof)

The mistake was actually mine :-$ I

had deleted part of the thread and

didn't realize this was the old

thread.

Sorry Phillippe, and sorry for the noise everybody.

-Flávio

_______________________________________________ fpc-pascal

maillist -

http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal [2]

Links:
------
[1]
http://www.freepascal.org/docs-html/ref/refsu58.html#x155-16500013.2.8 [2]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal