I've been playing with go for a week and something I miss from C is preprocessor macros.
What could I use to get this feature, besides hacking a build script that pipes go files through clang -E ?
As mentioned in the comments, build flags are probably the best way to solve whatever you need. For example, if you wanted to have some features only available in development, use a dev flag:
File constants_dev.go:
// +build dev
const DEVELOPMENT = true
File constants_pro.go
// +build !dev
const DEVELOPMENT = false
Then in your code, just do a simple if DEVELOPMENT { blah... }. I find this much more readable than any preprocessor. This can get quite messy if you have a lot of build flags, but at that point you should probably be using command-line arguments instead.
In your comment, you mentioned duplication of code. If your code is really that repetitive, you should probably be putting it in a function anyway, or possibly restructure code to reuse the bits that are repetitive. Personally, I find that anything beyond simple boolean checks ends in hard to maintain code, especially with C-style macros.
It's the same thing with generics. In one Java library I've used, the class signature was something like this:
class Thing<A, B, C, D, E>
The library wasn't very well documented, so I had to read a significant amount of the code (both implementation and code that uses the library) to understand what was going on.
In Go, the language forces a style that generally leads to better, self-documenting code. I think the Go developers omitted things like a preprocessor and generics to avoid temptation to write hard to maintain, but clever, code.
I would advise you to try out the Go way before looking back on old idioms that you used before. I think you'll find that most of what macros and #defines were used for are largely irrelevant.
I think cpp, m4 or whatever may fulfill your desire to have Go preprocessed. If it's a good idea or not is a decision of yours, but be warned that any preprocessing is a substantial obstacle for adoption of any published Go code. (And for example, the build being dependent on makefiles is the same story.)
Related
In this question i saw two different answers how to directly call functions written in C++
Inline::CPP (and here are more, like Inline::C, Inline::Lua, etc..)
SWIG
Handmade (as daxim told - majority of modules are handwritten)
I just browsed nearly all questions in SO tagged [perl][swig] for finding answer for the next questions:
What are the main differences using (choosing between) SWIG and Inline::CPP or Handwritten?
When is the "good practice" - recommented to use Inline::CPP (or Inline:C) and when is recommented to use SWIG or Handwritten?
As I thinking about it, using SWIG is more universal for other uses, like asked in this question and Inline::CPP is perl-specific. But, from the perl's point of view, is here some (any) significant difference?
I haven't used SWIG, so I cannot speak directly to it. But I'm pretty familiar with Inline::CPP.
If you would like to compose C++ code that gets compiled and becomes callable from within Perl, Inline::CPP facilitates this. So long as the C++ code doesn't change, it should only compile once. If you base a module on Inline::CPP, the code will be compiled at module install time, so another user never really sees the first time compilation lag; it happens at install time, just before the testing phase.
Inline::CPP is not 100% free of portability isues. The target user must have a C++ compiler that is of similar flavor to the C compiler used to build Perl, and the C++ standard libraries should be of versions that produce binary-compatible code with Perl. Inline::CPP has about a 94% success rate with the CPAN testers. And those last 6% almost always boil down to issues of the installation process not correctly deciphering what C++ compiler and libraries to use. ...and of those, it usually comes down to the libraries.
Let's assume you as a module author find yourself in that 95% who have no problem getting Inline::CPP installed. If you know that your target audience will fall into that same category, then producing a module based on Inline::CPP is simple. You basically have to add a couple of directives (VERSION and NAME), and swap out your Makefile.PL's ExtUtils::MakeMaker call to Inline::MakeMaker (it will invoke ExtUtils::MakeMaker). You might also want a CONFIGURE_REQUIRES directive to specify a current version of ExtUtils::MakeMaker when you create your distribution; this insures that your users have a cleaner install experience.
Now if you're creating the module for general consumption and have no idea whether your target user will fit that 94% majority who can use Inline::CPP, you might be better off removing the Inline::CPP dependency. You might want to do this just to minimize the dependency chain anyway; it's nicer for your users. In that case, compose your code to work with Inline::CPP, and then use InlineX::CPP2XS to convert it to a plain old XS module. Your user will now be able to install without the process pulling Inline::CPP in first.
C++ is a large language, and Inline::CPP handles a large subset of it. Pay attention to the typemap file to determine what sorts of parameters can be passed (and converted) automatically, and what sorts are better dealt with using "guts and API" calls. One feature I wouldn't recommend using is automatic string conversion, as it would produce Unicode-unfriendly conversions. Better to handle strings explicitly through API calls.
The portion of C++ that isn't handled gracefully by Inline::CPP is template metaprogramming. You're free to use templates in your code, and free to use the STL. However, you cannot simply pass STL type parameters and hope that Inline::CPP will know how to convert them. It deals with POD (basic data types), not STL stuff. Furthermore, if you compose a template-based function or object method, the C++ compiler won't know what context Perl plans to call the function in, so it won't know what type to apply to the template at compiletime. Consequently, the functions and object methods exposed directly to Inline::CPP need to be plain functions or methods; not template functions or classes.
These limitations in practice aren't hard to deal with as long as you know what to expect. If you want to expose a template class directly to Inline::CPP, just write a wrapper class that either inherits or composes itself of the template class, but gives it a concrete type for Inline::CPP to work with.
Inline::CPP is also useful in automatically generating function wrappers for existing C++ libraries. The documentation explains how to do that.
One of the advantages to Inline::CPP over Swig is that if you already have some experience with perlguts, perlapi, and perlcall, you will feel right at home already. With Swig, you'll have to learn the Swig way of doing things first, and then figure out how to apply that to Perl, and possibly, how to do it in a way that is CPAN-distributable.
Another advantage of using Inline::CPP is that it is a somewhat familiar tool in the Perl community. You are going to find a lot more people who understand Perl XS, Inline::C, and to some extent Inline::CPP than you will find people who have used Swig with Perl. Although XS can be messy, it's a road more heavily travelled than using Perl with Swig.
Inline::CPP is also a common topic on the inline#perl.org mailing list. In addition to myself, the maintainer of Inline::C and several other Inline-family maintainers frequent the list, and do our best to assist people who need a hand getting going with the Inline family of modules.
You might also find my Perl Mongers talk on Inline::CPP useful in exploring how it might work for you. Additionally, Math::Prime::FastSieve stands as a proof-of-concept for basing a module on Inline::CPP (with an Inline::CPP dependency). Furthermore, Rob (sisyphus), the current Inline maintainer, and author of InlineX::CPP2XS has actually included an example in the InlineX::CPP2XS distribution that takes my Math::Prime::FastSieve and converts it to plain XS code using his InlineX::CPP2XS.
You should probably also give ExtUtils::XSpp a look. I think it requires you to declare a bit more stuff than Inline::CPP or SWIG, but it's rather powerful.
I'm going into writing some crawlers for a web-site, the idea is that the site will use some back-end Perl scripts to fetch data from other sites, my design (in a very abstract way..) will be to write a package, lets say:
package MyApp::Crawler::SiteName
where site name will be a module / package for crawling specific sites, I will obviously will have other packages that will be shared across different modules, but that not relevant here.
anyway, making long short, my question is: Why (or why not...) should I prefer Moose over Standard OO Perl?
While I disagree with Flimzy's introduction ("I've not used Moose, but I have used this thing that uses Moose"), I agree with his premise.
Use what you feel you can produce the best results with. If the (or a) goal is to learn how to effectively use Moose then use Moose. If the goal is to produce good code and learning Moose would be a distraction to that, then don't use Moose.
Your question however is open-ended (as others have pointed out). There is no answer that will be universally accepted as true, otherwise Moose's adoption rate would be much higher and I wouldn't be answering this. I can really only explain why I choose to use Moose every time I start a new project.
As Sid quotes from the Moose documentation. Moose's core goal is to be a cleaner, standardized way of doing what Object Oriented Perl programmers have been doing since Perl 5.0 was released. It provides shortcuts to make doing the right thing simpler than doing the wrong thing. Something that is, in my opinion, lacking in standard Perl. It provides new tools to make abstracting your problem into smaller more easily solved problems simpler, and it provides a robust introspection and meta-programming API that tries to normalize the beastiary that is hacking Perl internals from Perl space (ie what I used to refer to as Symbol Table Witchery).
I've found that my natural sense of how much code is "too much" has been reduced by 66% since I started using Moose[^1]. I've found that I more easily follow good design principles such as encapsulation and information hiding, since Moose provides tools to make it easier than not. Because Moose automatically generates much of the boiler-plate that I normally would have to write out (such as accessor methods, delegate methods, and other such things) I find that it's easier to quickly get up to speed on what I was doing six months ago. I also find myself writing far less tricky code just to save myself a few keystrokes than I would have a few years ago.
It is possible to write clean, robust, elegant Object Oriented Perl that doesn't use Moose[^2]. In my experience it requires more effort and self control. I've found that in those occasions where the project demands I can't use Moose, my regular Object Oriented code has benefitted from the habits I have picked up from Moose. I think about it the same way I would think about writing it with Moose and then type three times as much code as I write down what I expect Moose would generate for me[^3].
So I use Moose because I find it makes me better programmer, and because of it I write better programs. If you don't find this to be true for you too, then Moose isn't the right answer.
[^1]: I used to start to think about my design when I reached ~300 lines of code in a module. Now I start getting uneasy at ~100 lines.
[^2]: Miyagawa's code in Twiggy is an excellent example that I was reading just today.
[^3]: This isn't universally true. There are several stories going around about people who write less maintainable, horrific code by going overboard with the tools that Moose provides. Bad programmers can write bad code anywhere.
You find the answer why to use Moose in the Documentation of it.
The main goal of Moose is to make Perl 5 Object Oriented programming easier, more consistent, and less tedious. With Moose you can think more about what you want to do and less about the mechanics of OOP.
From my experience and probably others will tell you the same. Moose reduces your code size extremly, it has a lot of features and just standard features like validation, forcing values on creation of a object, lazy validation, default values etc. are just so easy and readable that you will never want to miss Moose.
Use Moose. This is from something I wrote last night (using Mouse in this case). It should be pretty obvious what it does, what it validates, and what it sets up. Now imagine writing the equivalent raw OO. It's not super hard but it does start to get much harder to read and not just the code proper but the intent which can be the most important part when reading code you haven't seen before or in awhile.
has "io" =>
is => "ro",
isa => "FileHandle",
required => 1,
handles => [qw( sysread )],
trigger => sub { binmode +shift->{io}, ":bytes" },
;
I wrote a big test class last year that also used the handles functionality to redispatch a ton of methods to the underlying Selenium/WWWMech object. Disappearing this sort of boilerplate can really help readability and maintenance.
I've never used Moose, but I've used Catalyst, and have extensive experience with OO Perl and non-OO Perl. And my experience tells me that the best method to use is the method you're most comfortable using.
For me, that method has become "anything except Catalyst" :) (That's not to say that people who love and swear by Catalyst are wrong--it's just my taste).
If you already have the core of a crawler app that you can build on, use whatever it's written in. If you're starting from scratch, use whatever you have the most experience in--unless this is your chance to branch out and try something new, then by all means, accomplish your task while learning something new at the same time.
I think this is just another instance of "which language is best?" which can never be answered, except by the individual.
When I learned about objects in Perl, first thing I thought was why it's so complicated when Perl is usually trying to keep things simple.
With Moose I see that uncomplicated OOP is possible in Perl. It sort of bring OOP of Perl back to manageable level.
(yes, I admit, I don't like perl's object design.)
Although this was asked 10 years ago, much has changed in the Perl world. I think most people now see that Moose didn't deliver all people thought it might. There are several derivative projects, lots of MooseX shims, and so on. That much churn is the code smell of something that's close to useful but not quite there. Even Stevan Little, the original author, was working on it's replacement, Moxie, but it never really went anywhere. I don't think anyone was ever completely satisfied with Moose.
Currently, the future is probably not Moose, irrespective of your estimation of that framework. I have a chapter for Moose in Intermediate Perl, but I'd remove it in the next edition. That's not a decision from quality, just on-the-ground truth from what's happening in that space.
Ovid is working on Corrina, a similar but also different framework that tries to solve some of the same problems. Ovid outlines various things he wants to improve, so you can use that as a basis for your own decision. No matter what you think about either Moose or Corrina, I think the community is now transitioning out of its Moose phase.
You may want to listen to How Moose made me a bad OO programmer, a short talk from Tadeusz Sośnierz at PerlCon 2019.
Even if your skeptical, I'd say try Moose in a small project before you commit to reconfiguring a large codebase. Then, try it in a medium project. I tend to think that frameworks like Moose look appealing in the sorts of examples that fit on a page, but don't show their weaknesses until the problems get much more complex. Don't go all in until you know a little more.
You should at least know the basics of Moose, though, because you are likely to run into other code that uses it.
The Perl 5 Porters may even include this one in core perl, but a full delivery may happen in the five to ten year range, and even then you'd have to insist on a supported Perl. Most people I encounter are about three to five years behind on Perl versions. If you control your perl version, that's not a problem. Not everyone does though. Holding out for Corrina may not be a good short-term plan.
POSTLUDE
MooseX::Declare would no longer be recommended by anyone as it relies on Devel::Declare which served its purpose but is itself obsolete. At this point if anyone wants MX::D they should look at Moops
ORIGINAL
Assuming I already have a decent knowledge of old-style Perl OO, and assuming I am going to write some new code in some flavor of Moose (yes, I understand there is a performance hit), I was wondering if deeper down either rabbit hole, am I going to wish that I had chosen the other path? Could you SO-monks enlighten me with the relative merits of Moose vs. MooseX::Declare (or some other?). Also how interchangeable they are, one for one class and the other for another, should I choose to switch.
(p.s. I would be ok cw-ing this question, however I think a well formed answer might be able to avoid subjectivity)
MooseX::Declare is basically a sugar-layer of syntax over Moose. They are, for everything past the parser, identical in what they produce. MooseX::Declare just produces a lot more of it, with a lot less writing.
Speaking as someone who enjoys the syntax of MooseX::Declare but still prefers to write all of my code in plain Moose, the tradeoffs are mostly on the development & maintainability side.
The basic list of items of note when comparing them:
MooseX::Declare has much more concise syntax. Things that take several hundred lines in plain old perl objects (POPO?), may take 50 lines in Moose, may take 30 lines in MooseX::Declare. The code from MooseX::Declare is to me more readable and elegant as well.
MooseX::Declare means you have MooseX::Types and MooseX::Method::Signatures for free. This leads to the very elegant method foo(Bar $bar, Baz $baz) { ... } syntax that caused people to come back to Perl after several years in Ruby.
A downside to MooseX::Declare is that some of the error messages are much more cryptic than Moose. The error to a TypeConstraint validation failure may happen several layers deep in MooseX::Types::Structured and getting from there to where in your code you broke it can be difficult for people new to the system. Moose has this problem too, but to a lesser degree.
The places where the dragons hide in MooseX::Declare can be subtly different than where they hide in Moose. MooseX::Declare puts in an effort to walk around known Moose issues ( the timing of with() for example) but introduces some new places to be aware of. MooseX::Types for example have a wholly different set of problems from Moose's native Stringy types[^1].
MooseX::Declare has yet another performance hit. This is known to the MooseX::Declare developers and people are working on it (for several values of working I believe).
MooseX::Declare adds more dependencies to Moose. I add this one because people complain already about Moose's dependency list which is around 20 modules. MooseX::Declare adds around another 5 direct dependencies on top of that. The total list however according to http://deps.cpantesters.org/ is Moose 27, MooseX::Declare 91.
If you're willing to go with MooseX::Declare, the best part is you can swap between them at the per-class level. You need not pick one over the over in a project. If this class is better in Moose because of Performance needs, or it's being maintained by Junior programmers, or being installed on a more tightly controlled system. You can do that. If that class can benefit from the extra clarity of the MooseX::Declare syntax you can do that too.
Hope this helps answer the question.
[^1]: Some say fewer, some say more. Honestly the Moose core developers are still arguing this one, and there is no right answer.
One minor aspect that may interest you, and I may as well be interested by an answer to this : the main problem I had with MooseX::Declare, which was important in my specific case, was that I was unable to pack my application as an executable, neither with PAR::Packer nor ActiveState PerlApp.
I then used https://github.com/komarov/undeclare/blob/master/undeclare.pl to go back to Moose code.
As written above
other problems with MooseX::Declare:
- terrible error messages ( really, useless. unless you use Method::Signatures::Modifiers )
- performance hit ( as You have noted ), but in my opinion not small. ( we profiled some big real-life apps )
- problem with TryCatch ( if U use that, see: https://rt.cpan.org/Public/Bug/Display.html?id=82618 )
- some incompatibilities in mixed ( MooseX - non-Moose environment, eg. failed $VERSION check )
If You do not need the 'syntactic sugar' of MooseX, do not use it. Depending on the task You are into, I'd use from 'bottom-to-top', eg.
1. Mouse+Mehod::Signatures
2. Moose
3. then perhaps MooseX
depending on what you want.
Upgrading is not too complicated in this order. However, if You come to the point that You really need MooseX, I'd rather suggest You looking for some other, OO-wise developed language that offer most of the features in-box ( eg. horribile dictu Ruby or Python ), and those, that are not found, You perhaps you can live without.
If You really want Moose, consider a bottom-to-top approach starting with the less sugar. I prefer using Mouse + Method::Signatures first. My scenario is that I am sitting on the backend where we need very few objects, shallow hierarchy, but sometimes fast accessors - then we can still fall back to XSAccessor. Mouse+Method Signatures seem to be a rather good compromise between syntactic help and speed. If my design really needs more, then simply upgrade to Moose.
I can confirm the speed penalty with MooseX::Declare not only with simple accessor benchmarks ( https://metacpan.org/pod/App::Benchmark::Accessors ), but also in real-life application. This combined with cryptic error messages rules MooseX::Declare out.
My team recently decided to move away from MooseX::Declare. Is using MooseX::Method::Signatures on its own the best alternative?
Courtesy of Jon Rockway, who is too lazy to change his proxy:
My take is that for ease of debugging, it’s best not to use either. They don’t introduce many problems of their own (the slow startup time is Class->meta->make_immutable, which you would do anyway), but they do introduce problems when interacting with other tools. Devel::Cover, Devel::NYTProf, perlcritic, perltidy, etc., require various degrees of tweaking in order to be usable. You have to weigh the syntax sugar against the inability to use certain tools as easily.
So I think there are various options:
MooseX::Declare – less typing; ease in being accurate; ease of extensibility
MooseX::Method::Signatures – a little more typing, a little less accuracy; you have to worry about “use namespace::autoclean” or “no Moose”, you have to worry about make_immutable, you have to return a true value, etc.
MooseX::Params::Validate – now we’re back to normal Perl; same validations as MX::Method::Signatures, and same drawbacks. But now all your tools work. Only problem is that the syntax is ugly – my eyes, the goggles do nothing!
Parms::Util – simple way to get “correct” validations, acceptable syntax, but less flexible; does not integrate with MooseX::Types like MX::Params::Validate
Doing it manually – simple, usually correct, easy to understand. But it’s easy to be tempted into being lazy; allow a CODE ref, but not objects with a CODE overload; “ref $foo” instead of “ref $foo && blessed $foo && $foo->isa(‘ClassName’); etc.
So really, they’re all bad in their own special fun ways. Lately I have been doing a combination of manual validation and Params::Util, but I’m not willing to say that’s the best way to do things. I’m going to weight my “best practice” towards MX::Types + MX::Params::Validate, but for some reason, I’m not motivated to use it myself.
--Jon
From the current version (0.98) of the Moose::Manual::MooseX are the lines:
We have high hopes for the future of
MooseX::Method::Signatures and
MooseX::Declare. However, these
modules, while used regularly in
production by some of the more insane
members of the community, are still
marked alpha just in case backwards
incompatible changes need to be made.
I noticed that for MooseX::Method::Signatures the change log for September 2009 mentions the removal of the "scary ALPHA disclaimer".
So, are these still "alpha"?
Would I still be considered one of the "more insane" to use them?
I'd say they are production ready - I'm using them in production - but there are several things to consider:
Performance
MooseX::Declare and dependencies do almost all of their magic at compile time. Depending on the size of your program, you might find anywhere from half a second to several seconds of additional initialization overhead. If this a problem, don't use MooseX::Declare.
At runtime, the main overhead is type and argument checking, which you should (ideally) be doing anyway. That said, Moose type constraints have some overheads, namely coercion and the more complex (MooseX::Types::Structured-style) constraints. Don't use these if performance is an issue.
Stability
MooseX::Declare and MooseX::Method::Signature's external syntax is now stable. But it is important to know that the internals are subject to extreme change. (fortunately, changes for the better)
To give you an idea, the signature itself is grabbed using a big block of C code stolen from the Perl tokenizer (toke.c). This can break in some situations since it isn't actually parsing anything. The bit inside the brackets is parsed using PPI, which is designed for pure Perl, but the resulting PPI tree is then hacked up to get something useful. Devel::Declare itself is a hack - after it sees specific keywords (e.g. 'role', 'class', 'method') the Devel::Declare-using module must rewrite the source code by hand, with no interaction with the real Perl parser.
Corner cases may cause Perl to segfault. Or rewrite the source code badly, so you get syntax errors but have no idea what's causing them without -MO::Deparse. If you mess up the MooseX::Declare syntax by accident, there is no guarantee that the module will detect this and give you a sensible error. The ALPHA message may have gone, but this is still doing dark and scary things internally, and you should be prepared for that.
UPDATE
MooseX::Declare has not been updated much, and you may wish to look at alternatives such as Moops. Personally, I have decided to stick with pure Moose until Perl itself begins to support class/method/has syntax natively, which is possibly on the cards.
I think it's a matter of differing perspectives as much as anything -- rafl is one of the aforementioned "more insane members of the community" while Rolsky is more conservative. It's up to you to decide who you agree with, and really I think that the most important variable is your own code.
MooseX::Declare is good code. It won't randomly blow up your machine, it's not awful for performance, and it offers a lot of nifty stuff while reducing the amount of boilerplate that you have to write. But it might change in the future, making your code refuse to compile until it's updated; it might make your editor and other development tools confused when it sees syntax that it can't parse, it might piss off your collaborators by making them learn a new module to work with your code, or it might piss off your boss by making it so any future maintainer has to learn a new module to work with your code. Which of those things apply to you, and to what degree? You know better than I do, I hope.
There are people who feel that the maturity and stability of MooseX::Delcare, Devel::Declare on which it's based, or even Moose itself are not yet ready for "prime time". I also know of two large companies with millions of visitors a month, who have MooseX::Declare in their production environment. I personally am happy with the stack I am provided with Moose and do not see a need yet to bring in MooseX::Declare. I know people who's opinion I deeply respect who refuse to write new code without the declarative sugar from MooseX::Declare.
All of this is to say, the decision on whether something is or is not production ready is highly dependent upon your production environment, your development needs, and taste for risk. Without being in your shoes we can't possibly give an informed decision as to how well any given tool matches that profile.
MooseX::Method::Signatures (MXMS), and MooseX::Declare which uses it, is not production ready. This is not because the code isn't stable, but because it is appallingly slow. Simply using the method keyword, no types or arguments, is a 500-1000x runtime performance hit over a regular method call. My Macbook Pro can do about 6,000 simple method calls per second using MXMS vs 5,000,000 with plain Perl.
Method::Signatures, in contrast, has almost no performance hit above what it would normally cost to do the requested checks. The syntax is almost exactly the same as MXMS and it supports Moose (and Mouse) types. Both rely on the same underlying syntax modifying technique. (Full disclosure, I am the author of Method::Signatures.)
If you like MooseX::Declare but want the performance of Method::Signatures, try Method::Signatures::Modifiers.
It depends on what you mean by "production ready". I wouldn't depend on them until their velocity slows down quite a bit. I like my production stuff to not need frequent care from external code changes, API adjustments, and so on. That's not something particular to Moose, but any young project.
You have to judge how much that matters to you. In some situations, pushing stuff into production is a lengthy process, so you must be circumspect with such things. At the other extreme, some places let you edit files directly on the production server. That is, you have to define your tolerance before anyone can tell you which side a given MooseX module is on.
MooseX::Declare and MooseX::Method::Signatures are working well but they can have really nasty penalty depending on what does your code do. This can be fixed by just not using method keyword or using Method::Signatures::Modifiers.
Performance penalty I am seeing is around 2-5x compared to Method::Signatures::Modifiers (5x being mostly for one specific class I was using). And it seems that it is mostly compile time or maybe first time initialization, because it is getting under 2x when the computation is longer.
Method::Signatures::Modifiers has better errors but you have to turn this optimization off when you use debugger (it goes haywire because it does not see these methods, you can see for yourself in -MO=Deparse output).
It may be worth it to get rid of Perl argument shifting hell.