RetroSearch Browse

Fri Apr 20 12:15:53 EDT 2001 · http://mail.python.org/pipermail/python-list/2001-April/110897.html

On Fri, 20 Apr 2001 00:59:35 -0300, Carlos Ribeiro
<cribeiro at mail.inet.com.br> wrote:

>At 16:11 18/04/01 +0000, David C. Ullrich wrote:
>>It's in Delphi all right. Now find five Delphi experts and ask them
>>whether they think it's a good idea.
>
>I dont know if the expression "Delphi expert" applies to myself; however, I 
>did happen to be a beta tester of Delphi 1 (when it was distributed in 
>floppies :-). In Delphi, "with" is a good idea, but not so in Python. Why 
>it is different? Because both languages have different type models.
>
>Delphi uses static types. So it is possible to know, in a unambiguous way, 
>what member is being assigned in a "with" clause. This is important for 
>both the compiler *and* the programmer. In fact, some Delphi experts may 
>argue that the "with" construct should be avoided. I believe it is a matter 
>of personal taste, because a careful read will always reveal wich variable 
>(or member of) is getting assigned.
>
>Python uses dynamic types. It is impossible to know in advance which 
>attribute will be referenced at runtime. Member attributes may be added or 
>removed from objects on the fly. This would make it impossible to know, 
>from a simple reading, what attribute is being read - a local one, a global 
>one, or a member attribute.
>
>The same argument also applies to the use of self, that is mandatory on 
>Python, but not on Delphi. In Delphi all you have is a implicit "with" 
>clause on self on the beginning of every method implementation.

Yes of course "with" in Delphi is nothing like what "with" would be in
Python, because of the static typing. The argument against it
in Delphi has to do with that Self thing: If you say

function AnObjectType.AMethod;
begin
  with AnotherObject do
    begin
      SomeMethod;
    end;
end;

you cannot tell _just_ from that snippet whether SomeMethod refers
to AnotherObject.SomeMethod or Self.SomeMethod. You need to
know whether AnotherObject _has_ a SomeMethod method to
determine this. (What it comes to is that _any_ "with" is actually
a _nested_ "with" - seems like nested withs were regarded as
the final salvo elsewhere in this thread, totally demolishing the
advocates of with in Python.)

I used to think this was an extremely silly objection - if the 
programmer doesn't know what sort of objects he's dealing
with it's not going to work anyway. It doesn't seem so silly
to me anymore. When I'm dealing with a simple record or
something I use with, but dealing with components with
millions of methods I've come to think that the guys who
argue against with here have a point. The more errors 
caught by the compiler the better - if you say
AnotherObject.SomeMethod explicitly the compiler can
let you know if there's no such thing. With with, if you
mean to call AnotherObject.SomeMethod, there's no
such thing, but AnObjectType does have a SomeMethod
method the thing compiles but does not do what you
expect; since you "know" that AnotherObject does
have a SomeMethod method it can be hard to find the
problem.

Explicit is better than implicit, or so I've heard said.

>Carlos Ribeiro
>
>
>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-list/2001-April/110897.html below:

With or Using