dynamic classes and duck typing

[Leandro Lucarella]

Walter Bright, el  1 de diciembre a las 17:31 me escribiste:
> Leandro Lucarella wrote:
> >It looks like you can (not as easily) according to bearophile example, but
> >this is besides the point, you only want to use malloc() for performance
> >reasons, and I already said that D is better than Python on that.
> >I mentioned ctypes just for the point of easy C-interoperability.
> 
> To me C interoperability means being able to connect with any C
> function. That means handling pointers, structs, etc.

Well, you can. It's a *little* more verbose than D, but since you almost
*never* need to interoperate with C in Python, it's not so bad.

> >>>It's simpler, because you only have one obvious way to do things,
> >>No, Python has try/catch/finally as well.
> >I said *obvious*. try/catch/finally is there for another reason (managing
> >errors, not doing RAII). Of course you can find convoluted ways to do
> >anything in Python as with any other language.
> 
> try/catch/finally is usually used for handling RAII in languages
> that don't have RAII, so I don't think it's really justifiable to
> argue that Python only gives one obvious way to do it.

It's obvious when you code in Python.

> D has three: RAII, scope guard, and try-catch-finally. As far as I'm
> concerned, the only reason t-c-f isn't taken out to the woodshed and
> shot is to make it easy to translate code from other languages to D.

I think code translation from other languages is not a good reason for
adding complexity...

> >>>Maybe you are right, but the with statement plays very well with the
> >>>"explicit is better than implicit" of Python :)
> >>>
> >>>Again, is flexibility vs complexity.
> >>Another principle is abstractions should be in the right place. When
> >>the abstraction leaks out into the use of the abstraction, it's user
> >>code complexity. This is a case of that, I believe.
> >
> >Where is the code complexity here, I can't see it.
> 
> The code complexity is suppose I create a mutex object. Every time I
> get the mutex, I want the mutex to be released on all paths. With
> RAII, I build this into the mutex object itself.

But you can do that with the 'with' statement!

> Without RAII, I have to add in the exception handling code EVERY place
> I use the object. If I change the abstraction, I have to go and change
> every use of it. To me, that's code complexity, not flexibility.
> 
> A proper abstraction means that if I change the design, I only have
> to change it in one place. Not everywhere its used.

We agree completely :)

> >The thing is, I never used them and never had the need to. Don't ask me
> >why, I just have very few errors when coding in Python. So it's not really
> >*needed*.
> 
> I agree that static analysis isn't needed. The better statement is
> is there a benefit to it that exceeds the cost?

Maybe in very big projects with an heterogeneous team, I don't know.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si pensas que el alma no se ve
el alma sí se ve en los ojos