As a short answer to your question, Moo(se) lazy attributes are (according to the docs) stubbed names for class variables that are replaced with their actual value(s) on their first call.
This is a basic caching scheme that is pretty common. Since I use Class::MethodMaker (actually a subclass of this since I have a few small modifications to the CPAN version). C:MM doesn't allow you to assign a default value (v1.12 anyway) so in that case no default value(s) exist to begin with. We have modified this by adding a new C:MM accessor type called once. Once still creates the attribute names but runs memoize on their values on the first get call. You can still change their values using set calls but their default value is delayed and then cached when you call it the first time. While this is different from Moo(se) in design it provides the same functionality. The caching isn't strictly required but it is similar to Moo(se) in that long running default values are cached once loaded so you don't keep taking the hit with repeated calls the to getter unless you specifically force an update. Does that answer your question?
]]>I believe the divide was mislabeled (by myself among others) as "Modern Perl" vs non "Modern Perl", when it is much more closely a divide about using Moo(se) vs. using alternatives for object management and code re-use methodologies.
]]>I have no problem with comments about a topic where the commenter is honest, courteous, and fair. You have repeatedly argued against me based on things I did not say but you apparently pulled out of your own interpretation.
Example: I never said C:MM offers lazy loading/init/etc. of attributes (or anything else for that matter). I said that I already have access to those features, I did not say how. You appear to have pulled that together from two different posts of mine and stitched them together in order to make your point.
How would you respond when continually berated about things you didn't say? Fairly similar I would thing. I didn't come here to argue with you or anyone else. I've made that quite clear and yet you seem intent on having some type of argument seemingly with whomever you can get to have one with. I for one, am done arguing with you.
]]>The very POINT of this "blog" is to voice positions for other members of the community. Thus I am, by definition, interacting with the community, as you advise me to do.
As an American, I do question everything. I think maybe there is a language barrier, here. It appears that you are stating that those of us who disagree with you need to adjust their opinions further to align more closely to yours. I must be misreading that; obviously, you do not truly believe that those of us with dissenting views need to "go farther." Perhaps it is your German culture that frames that, I just don't know.
]]>I tried to respond but ended up with to much to say so it ended up as a full post
]]>I'll continue apologizing over and over again for the same thing if required, but it does seem a bit off to continually berate me for something I've already admitted was in error.
]]>I'm not sure I agree that the community has always been inclusive, I'll point (again) to chromatic's post back in 2k11 http://modernperlbooks.com/mt/2011/04/civility-starts-with-me.html about issues within the community relating to hostile behavior. We all have the ability to be rude, biting, short, etc. I'm just as guilty as anyone throughout my life both personally and professionally.
I strongly believe this “rude behavior” is due to the passion each of us feel about our beloved Perl. Mithaldu, Buddy Burden, myself and all the others that have either posted or commented on this “fight?”, I assume you/we all love Perl, otherwise none of us would care enough to say anything. It is and has been a huge part of our lives for years, for some of us decades. It's not a bad thing, we will all be rude at some point because we are heavily invested in Perl. When we get a bit to excited it's important for those around us to point it out and ask us to calm down a bit, I'm ok with this. No, I am not suggesting either Mithaldu or Buddy Burden were rude, both have made valid and reasonable comments adding to the discussion.
So I said I hated "Modern Perl" (I meant Moo(se)). Why? well the truth in it's in large part to the fact that I've had all the features Moo(se) offers and much more for a very long time. When compared to what I'm used to I find the syntax of Moo(se) ugly (personally). My dislike doesn't make it bad, but it also doesn't mean I have no right to voice my opinion in public. I want to see Moo(se) continue to evolve, grow, get faster, better, increase in functionality and performance while decreasing in it's learning curve because this pushes the community forward, I want this for all public Perl code.
All this being said, I think it is important for every point of view to be discussed on it's merits, not on the charisma of it's current speaker. Why do I prefer C::MM over Moo(se)? Well until I show some code it's simply an idea and put up or shut up applies to me as much as it does anyone else (having reviewed Moo I feel they are *mostly the same with different syntax in how I would use them). I wanted to start a conversation, clearly I came off way more heavy handed then I intended. I've apologized for some of the glaring mistakes I made in my original post, and I've tried hard to be both open and courteous to each and every comment I have either directly or indirectly received. I'll continue to follow the idea that an open discussion is good for me, for you, and for the community.
Modern Perl seems to mean a few different things to different people, that's more clear now then it was when I first posted. Use strict, warnings, unit testing, pair programming, peer review, qa, etc. These have been standard for my development for almost 20 years, so the idea that they are modern didn't enter my mind, they are not modern to me. The CPAN has had tests (some more, some less) for nearly all modules it hosts as long as I've used it, I didn't realize this wasn't how everyone coded both personally and professionally, and this was a stupid assumption on my part (what happens when I assume? Yeah, exactly).
My mentor in Perl taught me to test first and code second, to get peer review on anything that wasn't a 5 minute one time script. He also taught me to be passionate about what I'm doing, to do it right no matter how many re-writes that took, and to take pride in my work. I've written some truly horrible code in my day, and I've written some things I am extremely proud of. I started this conversation with the intent to share my experiences with the community at large, and to encourage more of you to do the same.
If I were to write public code today I'd very likely use Moo, why? Because it's popular (and therefore familiar to many) and because it's not so different from C::MM as to be a stumbling block for me personally. The heart of the conversation I wanted to have with you all was about writing elegant code to solve interesting problems without using ready made answers provided by others. Because code re-use is bad? Not at all, in fact without code re-use many of us would be writing the same things over and over and likely burning out in the process. I wanted to start the conversation because while working on the shoulders of giants is a great way to move forward for many, some of us really want to know the guts, to understand how the wheels work and even possibly improve on their design (I'm not suggesting I have a better wheel). I'd still like to have that conversation (I have multiple posts in the works) with any of you that are interested. Though I'll try to do so without alienating many of you in the process as I clearly did with my previous post.
If you want to consider this post an apology I'm good with that, I did say some things wrong and used some wrong terminology so by all means, take this as an I'm sorry. The heart for me is about having an open conversation about we I think we all love, Perl.
* Moo(se) provides Roles (“safer” mixins, don't believe me? Read the docs on Moo(se) Roles, they are mixins with some attempts to stop you from being stupid). Also Moo(se) allows for flagging ro(p) and data types (beyond scalar, array, hash). I haven't personally checked on this but I'm guessing adding a number to something labeled as a Str will either die or use the chr() of the number, or something similar? None of this is provided by C::MM as far as I'm aware. They are mostly the same in how I would use them, you may very well use them differently.
]]>The second half of your post I completely agree with, for what I believe are all the same reasons. I believe in constantly learning, search, growing, expanding my knowledge, view, toolset, understanding, etc.
I have personally found Moo(se) to be something I looked at, and decided against. I then found that if you are not into Moo(se) that there are fewer and fewer public discussions for you to enjoy. For this reason I've decided to start one, it's as simple as that.
I hope this clears up what appears to have been a difference between what I meant to write and what you read.
]]>I haven't had any issues with C::MM myself in relation to list vs scalar context of arrays but that doesn't mean it's not an issue for many others.
My primary goal is to blog about current solutions to current problems without Moo(se), not because there is anything wrong with Moo(se), simply that Moo(se) is far from the only way to solve these problems. Moo(se) already gets more then it's own time in the sun, I just want to remind people that many of use are doing just fine without it.
]]>I also looked at Moo again, oddly enough it offers the base of Moose with Moose style syntax, which I use at work provided my by own framework. I might actually use Moo for public code (including examples I'll post about), though does have the same level of verbosity in code that Moose has. I think I'll run some performance tests on Moo, thank you for suggesting I go back and look at it again.
]]>I'm not against new or old ways of doing anything. I plan to write about manageable, test driven code with only a clean (recent) Perl installation available.
My biggest push back against Moose was/is that my project only updates hardware about every 2 years, yet we push for better performance and more features every day. We have continually hit our targets on both marks for 9 years in a row. I only wish any team I've seen using Moose could say the same. I'm not saying there aren't teams with that experience, just that I haven't read about or seen any myself.
]]>