Most of the XML parsing, in the hacks that have XML in them, is with XML::Simple or modules that are more specialised (such as SOAP::Lite, XML::RSS, etc.).
One of the nicest features of the book is that it promotes the use of appropriate parsers over random regexing.
It's a lot easier than the amount of documentation makes out. If you had read the book the original review was about then you'd know that.
As for those tutorials: perlbot is more a quick cookbook reference type thing; perltoot is part 1 of tchrist's OO tutorial; perltooc is part 2 and covers class data; while perlboot covers OO from the ground up.
toot/tooc are ideal for those used to OO elsewhere. boot is great for newbies to OO. bot is excellent as a "how do I..." reference.
Sure, they could all do with some rewriting but those most qualified to do so (justifiably) point to "Learning Perl Objects, References and Modules" and Conway's "Object Oriented Perl". Patches welcome.
As for @ISA, it's cute and simple. Perl does multiple inheritance, so it makes sense to keep that information in an array. You can even modify this array at runtime to modify your inheritance. You can hide it all with base (despite where that link will take you, it is a core module and has been since 5.00405 [early 1999]).
What syntax would you prefer?
The startling thing about Perl OO is its flexibility.
blah. I'd cite more examples but variable names and example code don't tend to come to me while not writing actual code.
Hungarian is just so much waffle. The main reason I enjoy having sigils in front of variables in Perl is that I can't clash with reserved words. I don't care so much about using it to differentiate between scalar, array and hash. Heck, in Perl 6 much of the distinction between an array and an arrayref will be gone (in most cases they'll be usable interchangeably) so the sigils will matter even less.
"If you upgrade from 5.6 to 5.8, you have to recompile your C based Perl modules."
Fairly simple. Making a snapshot bundle and installing said bundle is also trivial.
Depending on how your previous Perls were compiled, you may or may not have had to do this previously anyway. On the bright side, it also means that users will probably have more up to date versions of modules rather than whatever version existed 3 years ago (5.6.0) or longer (5.005 was 5 years ago). Modules can change a lot in that time. As can the language itself.
(b) get a better editor. sane editors (vim, emacs, presumably others) are able to comment regions, or automatically insert comment leaders as you type, or both.
APP is a _very_ brief skim of the material. EaEP goes into far more detail.
In fact, APP only skims all the topics it covers. It appears to mostly be an introduction to various topics that one can then further explore elsewhere.
These days, you're better off purchasing the TPJ books if you want the sort of thing APP gave.
Only if the pages are frequently revised to incorporate said "submissions". Otherwise it's just a mess.
Re:hasn't received much attention until recently?
on
XML and Perl
·
· Score: 1
Funny you should mention the reviewer's objectivity.
He wrote Manning's "Data Munging with Perl". Which is all about "slamming and jammin' text, including XML". In fact, it's got a reasonably large section on XML.
But he doesn't mention it, and he doesn't push it. Instead he recommends two books from different publishers, neither of which he works for. As far as I know he doesn't provide any content for O'Reilly's oreillynet, but I may be wrong there.
People who use Perl, and are part of the Perl community, know that you can slice and dice XML wuith Perl. What Dave is trying to say is that the managers and Java/Python/whatever programmers aren't so aware of this.
From what I recall, with books you can copyright the content
but not the title. With fonts, you can copyright the name, and the
implementation, but not the look.
Thus you can Palatino, Paladin, Pembroke, etc. All the same
font, just different implementations.
Which makes it all the better that/x is the default in Perl 6. Anything that makes complex regexs more legible and more likely to be commented is good in my book.
(Incidentally, Mastering Regular Expressions, 2nd edition, is out sometime this month.)
I'm not sure when it was introduced (I suspect it's new to 5.8), but the English module lets you do this these days:
use English qw( -no_match_vars );
Which will import everything, except the saw-ampersand and the other problematic variables ($PREMATCH, $MATCH, $POSTMATCH. So you can have the English, and not at the expense of speed.
Yes, there is a volume 4 in the works. Do a google for Donald Knuth. It's expected (currently) around 2009. The full set will have 7 volumes (thereabouts) assuming he completes it all before he dies (he's currently 64 or so). I just hope he finishes the lexing and parsing one.
As an addendum: you will note that your own GRETA doesn't support Perl 5's (?{...}) feature (and presumably not (??{...}) either). So, you'll probably agree to libraries not requiring 100% feature match. And you've got that recursive stuff going too.
To a degree, yes, some of these things won't be possible. But that's always been the case.
Embedded closures, direct scalar, array, hash assignment --- of course. Mighty will be the language that can do it without the aid of the sigil, or the runtime parsing.
Named rules --- they should be possible. It's just like making your grammar (hence the Larry's use of the word 'grammar'). After all, your GRETA does handle balanced nested tags. It shouldn't be too great a step.
But, yes, embedded closures would be a bugger --- but then I suspect they'll be classed as a "nifty Perl feature". Some languages will be able to implement their own version (I'm mostly thinking things like Ruby and Python --- semi-interpreted programs rather than pure compiled).
Variable assignation --- heck, most languages don't have the builtin concept of hashes so that one would be fun. Scalars and arrays could be possible --- perhaps even without the sigil. I may have to think on that one a bit more deeply at some point in the coming week. It would certainly help if regexps were first class in the language in question (rather than the C/C++ versions). I suspect that in C/C++ the most you could hope for was that the regexp match function would load its result object with appropriately named fields.
Now, if you'll excuse the somewhat ugly mix of psuedo C/C++ below (it's a while since I've used either to any extent and back then it was mostly C, but I think OO now =) )
I can see that working, although people will probably want some way of getting rid of the sigil.
On the whole: for Perl, the reshuffle is good. It's about time. For libraries that have inherited Perl's full complement of weird features (the (?...) set), then it's probably best if they provide some form of support for the new syntax --- it doesn't matter if it's incomplete, that's to be expected. If you can add some snazzy compensatory feature --- then that's good too. Maybe Perl will pick it up if it's appropriate =) Anyway -- I don't need to be telling you this, you've proved your abilities. I do, however, think that you should be able to implement most of the new syntax.
By the way: thanks for the GRETA link. Odds are that I would have been looking for something like that in two months.
Actually, if you read the Apocalypse, you will see that Perl5 regexen are quite complex and can be quite hard to properly grok. As Larry says: look at the (?...) extensions.
The Perl 6 design is far simpler. It's simpler and more powerful. It's just going to be different from every other regex implementation around. I can, however, safely assume that packages such as PCRE will be updated. Someone will amend vim's and emacs's implementations to allow for Perl 6 style regexen.
The world will continue rotating and people will realise that things have improved.
And, yes, Perl5 will be maintained for a while yet. Although I'm willing to bet that most people who actively use the Perl (the community, rather than those who have had their Perl 5 non-nms scripts running for five years and never learnt Perl to begin with) will shunt to 6. I'm sure people said the same thing about Apache 1.3 and 2. Or Windows 3 and 95. Or C and C++ (perhaps a bad example there).
Anyway - in the case of people and their old web scripts. They'll probably keep them that way. Someone will write Perl 6 versions and new users will use them. It's called migration. Heck - who knows - maybe some web hosters will remove the Perl 5 versions and installed Perl 6 versions. Maybe even just remove Perl 5. =)
Depends on the lass in question. Some like tools. Just as some guys wouldn't know what to do with an Allen key if you showed them something in which to insert it.
(a) finding list subscription addresses in the inbox (b) emailing them (c) finding list subscription confirmation address in the inbox (d) emailing them.
So the virus is auto-subscribing people to lists they don't necessarily want to be on, or are already on.
Slashdot Mirror
Most of the XML parsing, in the hacks that have XML in them, is with XML::Simple or modules that are more specialised (such as SOAP::Lite, XML::RSS, etc.).
One of the nicest features of the book is that it promotes the use of appropriate parsers over random regexing.
It's a lot easier than the amount of documentation makes out. If you had read the book the original review was about then you'd know that.
..." reference.
As for those tutorials: perlbot is more a quick cookbook reference type thing; perltoot is part 1 of tchrist's OO tutorial; perltooc is part 2 and covers class data; while perlboot covers OO from the ground up.
toot/tooc are ideal for those used to OO elsewhere.
boot is great for newbies to OO.
bot is excellent as a "how do I
Sure, they could all do with some rewriting but those most qualified to do so (justifiably) point to "Learning Perl Objects, References and Modules" and Conway's "Object Oriented Perl". Patches welcome.
As for @ISA, it's cute and simple. Perl does multiple inheritance, so it makes sense to keep that information in an array. You can even modify this array at runtime to modify your inheritance. You can hide it all with base (despite where that link will take you, it is a core module and has been since 5.00405 [early 1999]).
What syntax would you prefer?
The startling thing about Perl OO is its flexibility.
Um. No. Name for its purpose, not its type.
Array containing a bunch of squares? @squares.
blah. I'd cite more examples but variable names and example code don't tend to come to me while not writing actual code.
Hungarian is just so much waffle. The main reason I enjoy having sigils in front of variables in Perl is that I can't clash with reserved words. I don't care so much about using it to differentiate between scalar, array and hash. Heck, in Perl 6 much of the distinction between an array and an arrayref will be gone (in most cases they'll be usable interchangeably) so the sigils will matter even less.
You need new taste buds. Your current set appear to be worn out.
Ok. Let's try:
"If you upgrade from 5.6 to 5.8, you have to recompile your C based Perl modules."
Fairly simple. Making a snapshot bundle and installing said bundle is also trivial.
Depending on how your previous Perls were compiled, you may or may not have had to do this previously anyway. On the bright side, it also means that users will probably have more up to date versions of modules rather than whatever version existed 3 years ago (5.6.0) or longer (5.005 was 5 years ago). Modules can change a lot in that time. As can the language itself.
Of course, Mono is just working to implement a preexisting VM. Parrot has grander aims.
Here, why not learn something.
That chapter is less informative than the text on the back of "Programming Web Services with Perl".
(a) use pod (q.v. perldoc perlpod )
(b) get a better editor. sane editors (vim, emacs, presumably others) are able to comment regions, or automatically insert comment leaders as you type, or both.
(c) Acme::Comment
APP is a _very_ brief skim of the material. EaEP goes into far more detail.
In fact, APP only skims all the topics it covers. It appears to mostly be an introduction to various topics that one can then further explore elsewhere.
These days, you're better off purchasing the TPJ books if you want the sort of thing APP gave.
For mixing C and Perl, EaEP is excellent.
Only if the pages are frequently revised to incorporate said "submissions". Otherwise it's just a mess.
Funny you should mention the reviewer's objectivity.
He wrote Manning's "Data Munging with Perl". Which is all about "slamming and jammin' text, including XML". In fact, it's got a reasonably large section on XML.
But he doesn't mention it, and he doesn't push it. Instead he recommends two books from different publishers, neither of which he works for. As far as I know he doesn't provide any content for O'Reilly's oreillynet, but I may be wrong there.
People who use Perl, and are part of the Perl community, know that you can slice and dice XML wuith Perl. What Dave is trying to say is that the managers and Java/Python/whatever programmers aren't so aware of this.
Many. Read the book.
There's alwqys the Ruby Way.
"My name is #{name}\n"
where 'name' can be any expression, not just a variable name.
Not to mention Ovation Pro (Pilling probably still maintains that
whereas CC don't do much with Impression these days)
From what I recall, with books you can copyright the content but not the title. With fonts, you can copyright the name, and the implementation, but not the look.
Thus you can Palatino, Paladin, Pembroke, etc. All the same font, just different implementations.
(Incidentally, Mastering Regular Expressions, 2nd edition, is out sometime this month.)
Yes, there is a volume 4 in the works. Do a google for Donald Knuth. It's expected (currently) around 2009. The full set will have 7 volumes (thereabouts) assuming he completes it all before he dies (he's currently 64 or so). I just hope he finishes the lexing and parsing one.
To get mod_perl announcements via email subscribe here. For more details, see here.
As an addendum: you will note that your own GRETA doesn't support Perl 5's (?{...}) feature (and presumably not (??{...}) either). So, you'll probably agree to libraries not requiring 100% feature match. And you've got that recursive stuff going too.
Embedded closures, direct scalar, array, hash assignment --- of course. Mighty will be the language that can do it without the aid of the sigil, or the runtime parsing.
Named rules --- they should be possible. It's just like making your grammar (hence the Larry's use of the word 'grammar'). After all, your GRETA does handle balanced nested tags. It shouldn't be too great a step.
But, yes, embedded closures would be a bugger --- but then I suspect they'll be classed as a "nifty Perl feature". Some languages will be able to implement their own version (I'm mostly thinking things like Ruby and Python --- semi-interpreted programs rather than pure compiled).
Variable assignation --- heck, most languages don't have the builtin concept of hashes so that one would be fun. Scalars and arrays could be possible --- perhaps even without the sigil. I may have to think on that one a bit more deeply at some point in the coming week. It would certainly help if regexps were first class in the language in question (rather than the C/C++ versions). I suspect that in C/C++ the most you could hope for was that the regexp match function would load its result object with appropriately named fields.
Now, if you'll excuse the somewhat ugly mix of psuedo C/C++ below (it's a while since I've used either to any extent and back then it was mostly C, but I think OO now =) )I can see that working, although people will probably want some way of getting rid of the sigil.
On the whole: for Perl, the reshuffle is good. It's about time. For libraries that have inherited Perl's full complement of weird features (the (?...) set), then it's probably best if they provide some form of support for the new syntax --- it doesn't matter if it's incomplete, that's to be expected. If you can add some snazzy compensatory feature --- then that's good too. Maybe Perl will pick it up if it's appropriate =) Anyway -- I don't need to be telling you this, you've proved your abilities. I do, however, think that you should be able to implement most of the new syntax.
By the way: thanks for the GRETA link. Odds are that I would have been looking for something like that in two months.
Actually, if you read the Apocalypse, you will see that Perl5 regexen are quite complex and can be quite hard to properly grok. As Larry says: look at the (?...) extensions.
The Perl 6 design is far simpler. It's simpler and more powerful. It's just going to be different from every other regex implementation around. I can, however, safely assume that packages such as PCRE will be updated. Someone will amend vim's and emacs's implementations to allow for Perl 6 style regexen.
The world will continue rotating and people will realise that things have improved.
And, yes, Perl5 will be maintained for a while yet. Although I'm willing to bet that most people who actively use the Perl (the community, rather than those who have had their Perl 5 non-nms scripts running for five years and never learnt Perl to begin with) will shunt to 6. I'm sure people said the same thing about Apache 1.3 and 2. Or Windows 3 and 95. Or C and C++ (perhaps a bad example there).
Anyway - in the case of people and their old web scripts. They'll probably keep them that way. Someone will write Perl 6 versions and new users will use them. It's called migration. Heck - who knows - maybe some web hosters will remove the Perl 5 versions and installed Perl 6 versions. Maybe even just remove Perl 5. =)
All fun.
Depends on the lass in question. Some like tools. Just as some guys wouldn't know what to do with an Allen key if you showed them something in which to insert it.
Amusingly, the virus is:
(a) finding list subscription addresses in the inbox
(b) emailing them
(c) finding list subscription confirmation address in the inbox
(d) emailing them.
So the virus is auto-subscribing people to lists they don't necessarily want to be on, or are already on.
Ever seen the UK show 'Spaced'?
That's geek TV. and darn good too.