Re: Deleting a package

Replies are listed 'Best First'.
Re: Re: Deleting a package by halley (Prior) on Apr 27, 2004 at 13:29 UTC
If every "object" has a completely different and independent set of subs, it makes sense not to rely on the object model. -- `[ e d @ h a l l e y . c c ]`	[reply]
Re^3: Deleting a package by adrianh (Chancellor) on Apr 27, 2004 at 13:59 UTC
If every "object" has a completely different and independent set of subs, it makes sense not to rely on the object model. Without knowing more about the application who knows - but we can always store subroutines as object state if we want to.	[reply]
Re: Re^3: Deleting a package by halley (Prior) on Apr 27, 2004 at 14:04 UTC
What do you think a package is? It's an object in the interpreter which has a name, and a collection of symbols which it owns. Some of those symbols refer to subs. Have you seen the .sig someone has around here, which is something like "he started out writing a {foo} and ended up inventing a new object model"? -- `[ e d @ h a l l e y . c c ]`	[reply]
Re^5: Deleting a package by adrianh (Chancellor) on Apr 27, 2004 at 15:53 UTC
Re: Re: Deleting a package by sfink (Deacon) on Apr 27, 2004 at 17:17 UTC
Because the "pages" really are close to web pages (or CGI scripts?). It is too difficult to explain without giving some more detail about the application, so I will: the application is an interactive projection system that plays what we call "spots", which are short interactive segments with graphics and behavior that users will play with. The spots are organized into a playlist that loops repeatedly. The authors of the spots are artists -- technically-minded artists, but still much stronger artistically than technically -- and I do not want to burden them with the overhead of constructing proper Perl objects. Also, the spots aren't really reusable in any useful way. (The fragments that are, I pull out and create objects out of, but the original authors don't know how to.) So although I don't think it would work to encapsulate them as objects, it might be a good idea to take a hint from Apache::Registry and wrap them in subroutines. Oh, and as long as a playlist is active, I don't really have any problems; all of the spots can stay alive in the interpreter. The problem comes when I switch to another playlist -- I want to free up everything from the first playlist. Also, when switching back to a playlist, I want it to be running in a clean environment, and not find little fragments of earlier incarnations of itself lying around. At the same time, the interpreter is used for other things, so I don't want to just kill and recreate it.	[reply]
Re^3: Deleting a package by adrianh (Chancellor) on Apr 28, 2004 at 23:34 UTC
So although I don't think it would work to encapsulate them as objects, it might be a good idea to take a hint from Apache::Registry and wrap them in subroutines. That's probably the way I'd approach it. The issues with non-obvious creation of closures are probably easier to deal with than the hassles of manually managing the packages. Template::Document might be another place for inspiration.	[reply]