On 11/17/06, Daniel McBrearty <[EMAIL PROTECTED]> wrote:
So my original example : say we have an application that streams audio, and only one source may be streamed at a time. Having more than one player instance in existence could violate this on many OS's. Even if the OS would cause an error (due to more the resource being busy when it starts up), you just don't want it to happen. How would you design this?
Right. But then you are on system with two sound cards and suddenly you're able to stream two sources at the same time. Suddenly, you'll find the need for proper objects, since now you'd need one instance per sound card. I think this is the point the guy who wrote the linked rant was trying to get at. People use Singletons due to lack of foresight since, eventually, they will need to have more than one instance. Of course this is not always true and you might really only need one instance ever, but since using Singletons inherently breaks some cases of reusability and is against fundamental OO theory, it's a practice that should be avoided. -Nilson Santos F. Jr. _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
