Front page | perl.perl6.language |
Postings from February 2001
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