Re^2: Data Persistence

This is the approach I felt like using earlier, however I thought my current understanding of how the code is handled within scripts and packages would make this pointless. Singletons always kind of feel hackish to me as well, however if you believe this would be the best approach, I will probably go with it.

This is how I believe the language works:

Default Perl scripts are always instanced
Module assigned using the "use" statement are only run once compile time, reference is then used to call the subroutines
Module/Files assigned using the "require" statement are always loaded using a fresh instance

Thanks for the suggestion :)

Comment on Re^2: Data Persistence

Replies are listed 'Best First'.
Re^3: Data Persistence by McA (Priest) on Nov 20, 2014 at 14:57 UTC
I called it Singleton to have a name for something where exactly one instance exists. How you want to implement this is a matter of taste. IMHO you should use a packages function or a class' method to access this variable. As soon as you let it access from the outside of the package you don't have control over who changes what when. That makes concurrency hard. If you don't have concurrency than so what. But there is always also the requirement of testing which makes it feasible to encapsulate. Be careful: `use` is (besides importing) a `require` at compile time. But a `require` is also just done once for a module. Have a look at `perldoc -f require`. McA	[reply] [d/l] [select]
Re^4: Data Persistence by ShaZe (Novice) on Nov 20, 2014 at 15:47 UTC
I am mind blown right now. It is going to sound retarded, but I just realized or remembered that perl was object oriented I thought most singleton patterns in perl used a flock to ensure there was only one instance of a script running, but we can actually create new objects and call their functions. Also, according to my testings, it seems like the code within a package is always executed after using the 'use' statement which was not what I expected Sorry if I was a little in doubt, I only code programs in perl once a year and I guess that what I had to do was never quite complex Thank you very much for the help, a lots of new doors just opened to me ahah. I still can't believe I had tried to understand some the modules found on CPAN and did not recall it was using objects, I feel so ashamed lol. I probably just noticed it and went back to my regular implementation without giving it too much thoughts since it was not required at all for what I had to do. Again, thank you for making me realize I was missing one of the most basic feature of the language	[reply]
Re^5: Data Persistence by Laurent_R (Canon) on Nov 20, 2014 at 23:27 UTC
Huh, no. Perl is not object oriented. Perl does support object orientation programming, but is not by itself object-oriented. Or, said in another way, you can do OO programming in Perl if so you wish, but you can use many other programming paradigms, such as classical procedural programming, functional programming and some others.	[reply]