On Wed, 24 Oct 2001 06:43, you wrote:
> On Tuesday 23 October 2001 13:25, you wrote:
> > Eric Lee Green wrote:
> > > 10. Reference counting works hand-in-hand with Python's destructors to
> > > handle resource cleanups in a real-time manner that's difficult with
> > > Ruby (where you can set up destructors of a sort but they only run at
> > > garbage collection time, which may be some time later, in the meantime
> > > you still have some open files and files on disk hanging around that
> > > are not getting cleaned up).
> >
> > Use the block paradigm instead. E.g.
> >
> > DBI.connect do | dbh |
> >   # do something with dbh
> > end
>
> While nice in its context, this does not work for many paradigms. For
> (hypothetical) example, I have a class which maintains some state
> information in a database. When an instance is destroyed, I want the
> corresponding state deleted out of the database. But I don't know
> beforehand when an instance is going to be destroyed, because I am one
> programmer on a team of 50 programmers working on this product. It is clear
> that a destructor is the most useful way of handling this situation.
>
What about Ruby's Observer Library? A snip from "The Book" says:

Library: observer
The Observer pattern, also known as Publish/Subscribe, provides a simple 
mechanism for one object to inform a set of interested third-party objects 
when its state changes. In the Ruby implementation, the notifying class mixes 
in the Observable module, which provides the methods for managing the 
associated observer objects.

> > > Java. I would not, however, relish attempting to manage 100K+ lines of
> > > Ruby code for a project, while Python proved to be quite usable for
> > > 100K+ lines of code.
> >
> > I'd hold against your last sentence, but I never tried it out.
> > But maybe 100K lines in Python are just 50K in Ruby ;-)
>
> Destructors are just another one of those features of Python which are
> oriented towards making 100K+ line programs with multiple programmers
> managable in Python. I like Ruby for one-programmer projects, but I just
> can't see how it could scale well to multi-programmer multi-100K-line
> projects. I've used Python in such large projects and it works quite well.
> The compartmented namespace in particular was extremely useful for
> partitioning tasks between programmers -- I could give them total freedom
> over how they were to implement their part of the program without worry
> about whether they'd tromp over one of my global configuration variables or
> etc.
>
> Finally, regarding verboseness of Python vs. Ruby, I haven't noticed any
> real difference there. Both are fairly terse. There is at most a few
> percent advantage to Ruby here, mostly because the backtick syntax and
> regular expresson syntax is tighter. There just isn't anything compelling
> about the verboseness issue that would make a Python programmer switch to
> Ruby. Other issues (such as, e.g., the 1-1 mapping between many Ruby and
> Java features, which makes prototyping Java programs in Ruby quite easy)
> are probably more important here.

-- 
Nigel S. Ball
Enesbe Sales Pty Ltd
Ph: 61 3 9909-7970
Fx: 61 3 9909-7971
Mob: 0417 341 300