type checking

[Stephen Horne]

On Sun, 12 Oct 2003 20:27:50 GMT, Alex Martelli <aleaxit at yahoo.com>
wrote:

>Stephen Horne wrote:
>   ...
>>>> | language. Either Java, C# or Delphi may be a good option for you.
>   ...
>>>I'd like to second Donn's recommendation and express reservations
>>>on Stephen's.  Java &c just don't have a high enough semantic level
>>>to give you the same productivity as Python.
>> 
>> I suggested C# - _not_ C. That is a very different thing. C# is
>
>Sure.  "&c" stands for "etc", in this context "and all the others [which
>you had mentioned]".

Sorry - I wasn't aware of that abbreviation.

>> A good language can mean big gains, but not necessarily as big as
>> someone else having written key parts of your application for you in
>> the form of libraries - and testing them too.
>
>Definitely.  But SWIG often helps a lot -- if the library's around for C,
>it's not far from your favourite SWIG-supported language.

Good point. Having heard of but never used SWIG, it's not something
that I had considered.

>By the same token, Java and C# will give few benefits if you already
>master C++ -- perhaps a little help with memory management to be
>offset against losing templates, a HUGE loss to adjust to, and such
>niceties as the "resource allocation is construction" idiom.

Yes, that is very true. I believe MS are adding generics to C#, but
with such big changes being planned that just rubs in the fact that C#
is an immature language resting on an immature library.

I had assumed that the "resource allocation is construction" idiom
could be applied in any language with both constructors and
exceptions. There are only two issues that I can think of that would
seriously affect it...

1.  If the language still tries to call a destructor for an object
    when its constructor raised an exception.

2.  The lack of automatic destruction of member and base components of
    an object if a later part of the objects constuctor propogates an
    exception.

3.  If the libraries do not consistently apply the idiom.

I assume it's mainly the second and third part where this is an issue.

It hasn't really been an issue so far, but I guess C# constructors
should be written so that they never propogate an exception - the
object should always be constructed in a self-consistent state even if
that state flags an error. Which immediately defeats the whole point
of exceptions.

I guess this might be less serious in a language with full garbage
collection - member fields which were initialised will still get
garbage collected, for instance, and any resources they reference will
get freed when that happens. But that seems like a dangerous system to
rely on. For instance, what happens if you need to access one of those
resources before the GC frees it.

This is one issue I already have with Java/C# style garbage collection
- if you need to ensure that resources are available when needed, you
still end up doing explicit 'deletes' anyway. Fortunately, it's only
in this particular case when that becomes impossible.

In Python, it doesn't seem to be an issue - presumably because Pythons
garbage collection is based on reference counting so destruction
happens immediately when the last reference has gone. I'm not sure
what happens when there are reference cycles, though - I know Python
handles them, but I'm not sure if they delay the garbage collection.

Hmmm - a thought provoking issue. Thanks for pointing it out.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk