type checking
Stephen Horne
$$$$$$$$$$$$$$$$$ at $$$$$$$$$$$$$$$$$$$$.co.uk
Mon Oct 13 06:55:52 EDT 2003
More information about the Python-list mailing list
Mon Oct 13 06:55:52 EDT 2003
- Previous message (by thread): type checking
- Next message (by thread): type checking
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): type checking
- Next message (by thread): type checking
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list