Board index » delphi » Re: One good argument against using "with"

Re: One good argument against using "with"


2006-02-08 04:14:13 PM
delphi155
marc hoffman writes:
Quote
Jake,

>One good argument against using "with"

Every single use if "with" i have ever seen was a self-contained
argument as to why "with" is evil ;)
Ok, have a look at this then:
with TIniFile.Create(InifileName) do
try
Somevariable := ReadString('APPDATA', 'name', 'Foo');
finally
Free;
end;
I use this all the time, but maybe my code is evil then :)
--
Ingvar Nilsen
www.ingvarius.com
 
 

Re: One good argument against using "with"

Eric Grange writes:
Quote
>[..] can not inspect that instance either.

Just use Ctrl+Alt+C (CPU View), then you will be able to inspect
everything ;)
lol, a good one
--
Ingvar Nilsen
www.ingvarius.com
 

Re: One good argument against using "with"

Ender writes:
Quote
CB>with X.Y.Something(blah).X[I].First.Parent do

Yeah. And somewhere between X and Parent, some property usually returns
NIL. Voila! EAccessViolation at this line in best case.
I also didn't place a begin and end after that line either - going to
pick up on that one as well.
Not to mention the variables are not declared, nor a program or unit
declaration, you didn't pick up on that one either.
 

Re: One good argument against using "with"

Hello, Yannis!
You wrote on 8 Feb 2006 00:24:12 -0700:
Y>Thats what depricated is for. You do not just rename a method that has
Y>been used in an application. This is as "evil" as using/not using with.
Why? Modification of a class or a method is typical part of refactoring
process, which should happen on regular basic.
Y>As always anyone can make his life easier or harder based on his/her
Y>understanding. The only evil I accept is the lack of choise everything
Y>else I either know how to use or not.
One may write applications which able to survive even after moderate
changes, other one may write applications so fragile that any minor change
or enhancement will render it unusable. To be first one, applications at
least should avoid unclear or tricky solutions.
With best regards, Ender. E-mail: XXXX@XXXXX.COM
 

Re: One good argument against using "with"

Roger Lascelles writes:
Quote
"Robin" <Robin@.com>writes
news:43e9606c$XXXX@XXXXX.COM...
>I know that it doesn't make much sense in a query this small, but it
>makes it seem neat and tidy to me to construct larger ones this
>way. Is it really that evil?

Lately I had to unravel some freeware source - a nightmare of WITH.
Just as I was swearing off WITH for life (again), I saw a nice little
data structure populated using WITH and thought maybe WITH has its
place. On further thought, even that is bad, because I could get a
clash with a simple variable name defined outside the WITH.

WITH is pure evil because it gives the compiler freedom to roam
around and find anything that fits : like a shoddy detective who fits
in the frame any old suspect.


A similar evil is short if..then statements :

if a=b then x=6;

instead of

if a=b then begin
x=6;
end;

Once some genius starts nesting these, you have to be careful. My
first step is to add begin..end pairs to make the structure clear.


I include overloaded functions as dangerous too.


The huge Delphi productivity boost is partly due to a language which
says almost exactly what it means. We have to avoid some remaining
flaws.

Roger Lascelles
May I add that programming languages are dangerous tools and not toys.
Hell, even the spoken language contains words and clauses that should
be used with caution. That, of course, is not always evident on this
newsgroup.
:)
--
 

Re: One good argument against using "with"

Kevin writes:
Quote
Aren't all objects implicit "with" statements? :)
WTF! The evil has crept in. OOP is evil! I will from now on write all
code inside the begin...end. block of the first and (from now on only)
unit. :))
--
 

Re: One good argument against using "with"

"Ender" <XXXX@XXXXX.COM>wrote in
Quote
Hello, Yannis!
You wrote on 8 Feb 2006 00:24:12 -0700:

Y>Thats what depricated is for. You do not just rename a method that
has Y>been used in an application. This is as "evil" as using/not
using with.

Why? Modification of a class or a method is typical part of
refactoring process, which should happen on regular basic.
At the desing and even implementation state of a class yes.
If you need to do it after used on an application it is a sign
of fealure in varius steps (requirement gathering, design etc)
Unless you design your classes to be used on single applications
I would say that after the proccess of design and implementation
any removal of public/published properties is evil since you do not
know how it has been used from the varius developers that used it.
Quote
Y>As always anyone can make his life easier or harder based on
his/her Y>understanding. The only evil I accept is the lack of
choise everything Y>else I either know how to use or not.

One may write applications which able to survive even after moderate
changes,
Moderate change a removal of a method? No not in my book.
Moderate change will be the addition of new methods or functionality
even the fine tunning of existing methods but removal is a magor change.
Quote
other one may write applications so fragile that any minor
change or enhancement will render it unusable. To be first one,
applications at least should avoid unclear or tricky solutions.
The removal of a method or property will render an application
unusable in any way you cut it. You need to recompile in order
to make it work again after changing the code. It is easier to
deprecate a method or property before removal leaving the decision
on when to remove it to the application not the library.
It makes better bussiness sense IMHO.
Regards
Yannis.
 

Re: One good argument against using "with"

Roger,
Quote
A similar evil is short if..then statements :

if a=b then x=6;

instead of

if a=b then begin
x=6;
end;
or worse, mixed ones:
if a=b then
c := d
else begin
e := f;
end;
--
marc hoffman
Chief Architect, .NET
RemObjects Software
www.chromesville.com
and the fifty-two daughters of the revolution
turn the gold to chrome
 

Re: One good argument against using "with"

John,
Quote
It has it is moments, but I want an IDE refactoring that undoes "with"
statements.
Ouch. i think that would potentially be the one thing that is more
dangerous with with itself ;)
--
marc hoffman
Chief Architect, .NET
RemObjects Software
www.chromesville.com
and the fifty-two daughters of the revolution
turn the gold to chrome
 

Re: One good argument against using "with"

Ingvar,
Quote
Ok, have a look at this then:

with TIniFile.Create(InifileName) do
try
Somevariable := ReadString('APPDATA', 'name', 'Foo');
finally
Free;
end;

I use this all the time, but maybe my code is evil then :)
Ok, and what happens if the next version of TIniFile introduces a
SomeVariable property (assuming "SomeVariable" is a placeholder for a
more generic real name)?
--
marc hoffman
Chief Architect, .NET
RemObjects Software
www.chromesville.com
and the fifty-two daughters of the revolution
turn the gold to chrome
 

Re: One good argument against using "with"

marc hoffman writes:
Quote
Ingvar,

>Ok, have a look at this then:
>
>with TIniFile.Create(InifileName) do
>try
>Somevariable := ReadString('APPDATA', 'name', 'Foo');
>finally
>Free;
>end;
>
>I use this all the time, but maybe my code is evil then :)


Ok, and what happens if the next version of TIniFile introduces a
SomeVariable property (assuming "SomeVariable" is a placeholder for a
more generic real name)?
You are getting hypothetic here :)
Point is - the use (*my* use) of variable names would prevent that.
I use "with" not much, but in some cases I do. Also for TStringList,
TMemoryStream etc.
If that is the only objection you have, I am on safe ground!
--
Ingvar Nilsen
www.ingvarius.com
 

Re: One good argument against using "with"

When New Borland (R) is established, maybe we can get this:
function Foo: Integer;
begin
if (x = y) then
Exit with 1;
Result := 0;
end;
That would lift Delphi up to the C# convenience regarding this.
The tip is free, provided I get some shares in New Borland (R) <g>
--
Ingvar Nilsen
www.ingvarius.com
 

Re: One good argument against using "with"

In article <43e9606c$XXXX@XXXXX.COM>, Robin@.com says...
Quote
with MyIBDataSet.SelectSQL do
begin
Add('SELECT STUFF');
Add('FROM SOMETABLE');
Add('WHERE SOMECONDITION = :SOMEPARAM');
Add('ORDER BY STUFF');
end;
The bigger problem with this is that repeated calls to "Add" strings to
SQL can incurr overhead as each modification to the SQL may trigger the
data set to attempt to locate parameters.
There are ways of turning this behaviour off, but imho it is better to
define your SQL in a local const and assign to SQL.Text in one hit
where-ever possible.
This also keeps your code cleaner and encourages you to describe what
your SQL is doing (by it is const name), e.g:
MyQuery.SQL.Text := SELECT_CustomersWithOverdueOrders;
+0.02
--
Jolyon Smith
 

Re: One good argument against using "with"

Roger Lascelles writes:
Quote

I encounter these issues when working with other programmers, during
maintenance and when using code samples from the internet. First job is to
remove "with", begin/end the "if" then start work.

Roger Lascelles
<snip lots>
Ahh, thanks Roger!
--
Robin.
<disclaimer>Not an expert </disclaimer>
 

Re: One good argument against using "with"

Jolyon Smith writes:
Quote
The bigger problem with this is that repeated calls to "Add" strings to
SQL can incurr overhead as each modification to the SQL may trigger the
data set to attempt to locate parameters.

There are ways of turning this behaviour off, but imho it is better to
define your SQL in a local const and assign to SQL.Text in one hit
where-ever possible.

This also keeps your code cleaner and encourages you to describe what
your SQL is doing (by it is const name), e.g:

MyQuery.SQL.Text := SELECT_CustomersWithOverdueOrders;
Hi Jolyon,
Thanks for the tips!
I have started having a 'query' unit, and having functions which build
TStrings and I then assign that to the query. Similar idea, but
substantially more overhead I'd emagine then your method :-)
--
Robin.
<disclaimer>Not an expert </disclaimer>