Re: Good Dungeon Mapping e-Tool?

On Thu, 12 Jun 2008 12:55:43 GMT, Keith Davies
<keith.davies@xxxxxxxxxxxx> wrote:

Kyle Wilson <kyle@xxxxxxxxxxxxx> wrote:
On 12 Jun 2008 12:13:36 GMT, "Bradd W. Szonye" <bradd+news@xxxxxxxxxx>
wrote:

Keith Davies <keith.davies@xxxxxxxxxxxx> wrote:
Using a GCed language, especially one that purports to be Object
Oriented, and having to explicitly close files annoys me. Quite a
bit, actually.

I think most of the C-like languages squander garbage collection.
Actually, I'd say that they (or their designers) don't really get what
GC is about. This might sound weird, but GC isn't really about
resource management. Rather, it's an implementation detail to support
a style of programming that wouldn't work otherwise.* While it's great
for that, it (1) doesn't extend well to other resources, and (2) isn't
all that helpful to a careful programmer working in procedural style.

This sounds reasonable. It unfortunately seems to have become trendy
of late to add it to every programming environment that gets created.
I am particularly amused by Microsoft where there are so many
nonmemeory resources involved in a UI program (and finalization isn't
generally an option for them) and so most objects seem to require an
explicit dispose call even though the GC would clean up the purely
memory aspect. It feels a bit like a retreat to my old-time C
programming days.

The disgusting thing is, I suspect it wouldn't be *that* hard to keep
proper lifetime behavior. If it goes out of scope, reap it immediately.
Keep GC around just in case (i.e. to cover for sloppy programmers), but
don't make it the mandatory cleanup.

Microsoft actually does something like this in the newer version of
managed C++. The allow synchronous destructors to fire automatically
when a local passes out of scope.

So,

{
FileClass file( "filepath");
FileClass heapfile = new FileClass( "heapfilepath");
// operate on file
}
// file is out of scope, it's the only reference to that object, nuke
// time! heapfile, OTOH, is on the heap, keep it around.
// Probably need to either
// 1. disallow assignment of &file to a reference variable (ick)
// 2. make it so that assignment sets ownership appropriately (if file
// goes out of scope before the reference goes away, reference
// becomes owner. Considered file remaining owner forever, but
// that can lead to a bogus reference, which some programmers can't
// handle. Pussies.)

Considering the other hoops the language builders are jumping through, I
wouldn't expect this to be *too* much harder.

Now closures and objects actually have a lot in common, so it does
make sense to use GC for object-oriented programming. However, the
conceptual model of GC is that the closures/objects still /logically/
live forever, we just revoke their storage when we notice that they
don't need it anymore. Unfortunately, that doesn't translate well to
other resources, where lifetimes are logically finite and, often,
must be tightly bounded.

Yep, and adding in GC makes it harder for the language design to
provide synchronous destruction/finalization for objects and thus
makes the management of those other resources significantly harder. I
like much of what I see in C# and Java, but I really find these
implication of the GC to be painful for the sorts of work that I do.

Nondeterminate finalization, I hate it.

The really funny thing with all of this (to me at least) is that in a
large system with lots of abstract interfaces (where you don't know
whether the interface that you're using points to a disposable object
(to use Microsoft's term)) you must always explicitly dispose of any
object whose interface you hold (through some well known interface)
just in case someone created an object that implements that interface
that uses non-memory resources (for caching or data or lazy updates or
such). This needs to be set as an administrative/architectural
detail, because you can't really fix it retroactively. As far as I
can see, this pretty much removes any value from finalizers in larger
systems (as everything winds up needing to be explicitly
closed/disposed/freed).

The abstraction that interfaces and polymorphism provides forces this
(you call a factory method on some object that returns an interface
appropriate to your needs...when you're done with the factory created
object you must check to see whether it needs disposal and dispose of
it if it does or risk a resource leak). In the end, we're essentially
back to malloc and free for practical purposes.

In fact, in some ways this reminds me of the 3.5e/4e issues. They
seem to have done some interesting things in 4e (and I'd like to take
advantage of them) but in the process they also appear to have removed
tools that I found to be valuable. It becomes a catch-22 situation,
especially if the world seems to be careening towards the shiny new
stuff...
--

Kyle Wilson
email: kylewilson@xxxxxxxxxxxxx
.

Loading