Re^3: Deleting a package

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.

Comment on Re^3: Deleting a package

Replies are listed 'Best First'.
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
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. Surprisingly enough I do know what a package is :-) I don't really understand the point you're trying to make. The OPs problem is what packages don't give you - simple mechanisms for creation and destruction. I think that sticking the Perl code in a hash or whatever rather than a package will result in simpler code (e.g. the way Template Toolkit uses Template::Document objects to represent compiled templates.)	[reply]