James Mastros wrote:
> On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote:
> > Huh? What delete are you thinking of? This is Perl, not C++.
> Umm, perldoc -f delete?
>
> Come to think of it, this doesn't mesh purticularly well with the current
> meaning of delete. It does, however, with undef. In fact, it /is/ the
> current meaning of undef, except for the GC part. And perhaps the GC
should
> be explicit or automatic, but not implicit.
>
As I wrote in the last post, this isn't what I'm talking about. I'm talking
about destroying the object before the GC does.
> > > ...and trigger a GC that will get rid of the arg.
> > No. Perl decides for itself when to do GC.
> That's almost certianly a mistake.
Yeah, what about a nasty module that decides not to call the GC and blow
your memory??? That's IMO the best thing about programming in Perl compared
to C: not having to keep track of the memory!!! RFC 28!!!
> The programmer often /does/ know the
> expectations of the end-user better then the interpreter.
We must not count on the programmer for almost nothing. Most (Perl)
programmers want to forget about housekeeping details and expect Perl to do
the magic for them. And I think they're right! If Perl can do it, why would
they bother? Why write more code to do things Perl can do for you? Why write
C if you can write Perl?
> If the programmer
> can GC when /he/ wants to, he can do so when the pause will have the least
> effect.
>
I agree the programmer should have how to explicitly call the GC, but that
wouldn't be required from him.
> Think of a program that you want to run near-realtime most of the time,
Write C. With no GC below it. Probably, with no OS (or a realtime one) below
it.
> but
> where you have a bit of downtime every now and again. A game comes
> immedetly to mind.
>
Even if you want to write games in Perl (I would definitely want to), you
should use C extensions to do the screen update (at least for speed...), and
those would definitely not be constrained to GC pauses.
> Or, for that matter, a program that spawns an external process that might
> take a lot of memory, so does a GC before spawning it. (Because otherwise
> the OS will happily page out your garbage, resulting in massive amounts of
> unneeded IO.)
>
Call the GC explicitly before, no need to control when *not* to call it for
this, as you were suggesting.
Serious, man. Not having a implicit GC is not having GC at all! And as Perl
should be Perl, it should keep collecting our garbage as we produce it!
> -=- James Mastros
> --
> "All I really want is somebody to curl up with and pretend the world is a
> safe place."
> AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
>
- Branden
