Re^3: Help choosing the most efficient, dependable condition(al)

thank you very much for all the time, and effort you put into this.

Thank the libwww-perl authors, they did all the hard work of translating the algorithm into code and releasing it. I just remembered that this module exists, and adapted its documentation synopsis for your circumstance.

But isn't using/requiring a Module a bit overkill?

No. It does exactly what it needs to do, no less, barely more. You would not save much memory if you were to reimplement it from scratch.

doesn't perl already provide sufficient method(s) to accomplish such goals?

No, there is no negotiate function baked into Perl, being a general-purpose language. Maybe PHP has it, that would make sense given its Web deployment niche.

having used the method I posted here for some 2 years now. I haven't seen any evidence that there were any issues with it

This is not rational. Past evidence makes no promise about future performance. I can easily construct a case where the naive regex match breaks down, and the case wouldn't even be degenerate. Hint: that match ignores the q value.

In any case, this is not how a specification works. As part of the Internet, you have entered into this consensus/social contract to follow the specs. Either you are compliant, and gain interoperability, or you don't follow it, and the rest of the Internet treats you as RFC-ignorant/damage and routes around. Don't be that guy who does it on purpose, there's enough trouble already with unintentional bugs. (I had a bug in the code I showed thread-upwards, see the update.)

doing it correctly requires using an extra Module

It's free software, you can just copy the code into your project, so you have the functionality, but not a module. I generally don't do so because that approach harder to maintain. I like the abstraction modules gives me, and Perl's dependency management is outstanding. Why are you uneay about using a module as it is? Where do you draw the line what's acceptable and what not?

Comment on Re^3: Help choosing the most efficient, dependable condition(al)

Replies are listed 'Best First'.
Re^4: Help choosing the most efficient, dependable condition(al) by taint (Chaplain) on Nov 13, 2013 at 21:08 UTC
SOLD! You must be a salesmen -- and a good one, at that daxim! I'm all in -- on this one, anyway. I really appreciate all the time, and effort you put into elaborating this for me. You made a really good case for it's usage (the Module). I often struggle with KISS (Keep It Simple Stupid). Now that can go two ways; on one hand, it's really simple to make use of a Module, and it makes development, and time, a snap. But what about flow. I mean keeping it linear, or synchronous. Things look easy to follow, are a snap to diagnose, and generally run faster. Warning; I should probably confess; I started programming in assembler -- see; was my first language. Anyhow, because of this way of thinking that have (flow). I curse those that espouse OO, and all it's gloriousness. I remember hearing about it when it first started, back in the early '90's, and thought; boy, somebody sure bought the bill of goods there. H3ll, the closes thing to OO in assembler, is a macro. OK I guess it has advantages in large applications. But I still look at it with a great deal of scrutiny. So I guess this line of thinking might be considered by some, to be a hindrance. But that's the way it is with me, until I'm convinced otherwise, I guess. I'd really like to thank you again daxim, for all the time, and effort you put into this. Thanks. --Chris #!/usr/bin/perl -Tw use Perl::Always or die; my $perl_version = (5.12.5); print $perl_version;	[reply]

Replies are listed 'Best First'.

Re^4: Help choosing the most efficient, dependable condition(al)
by taint (Chaplain) on Nov 13, 2013 at 21:08 UTC

You must be a salesmen -- and a good one, at that daxim!

I'm all in -- on this one, anyway.

I really appreciate all the time, and effort you put into elaborating this for me. You made a really good case for it's usage (the Module).

I often struggle with KISS (Keep It Simple Stupid). Now that can go two ways; on one hand, it's really simple to make use of a Module, and it makes development, and time, a snap.

But what about flow. I mean keeping it linear, or synchronous. Things look easy to follow, are a snap to diagnose, and generally run faster. Warning; I should probably confess; I started programming in assembler -- see; was my first language.

Anyhow, because of this way of thinking that have (flow). I curse those that espouse OO, and all it's gloriousness. I remember hearing about it when it first started, back in the early '90's, and thought; boy, somebody sure bought the bill of goods there. H3ll, the closes thing to OO in assembler, is a macro.

OK I guess it has advantages in large applications. But I still look at it with a great deal of scrutiny. So I guess this line of thinking might be considered by some, to be a hindrance. But that's the way it is with me, until I'm convinced otherwise, I guess.

I'd really like to thank you again daxim, for all the time, and effort you put into this. Thanks.

--Chris

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;

[reply]