Re^2: Inheritance problem: Not a HASH ref

This of course means that you will need to implement all "inherited" methods from Furl as stubs in your class:

please no! Any way to access that "reference to a reference"?

Basically, what I am looking for is a fast equivalent to LWP::UserAgent which also allows for adding handlers. (I am not sure Furl offers handlers but it was just an experiment). Curl obviously comes to mind. But I did not find it dramatically faster than LWP. Whereas Furl was dramatically faster. What's your experience? The situation is 15,20 hits per minute. More than speed is the CPU load as it will be on a rented host.

Comment on Re^2: Inheritance problem: Not a HASH ref

Replies are listed 'Best First'.
Re^3: Inheritance problem: Not a HASH ref by NetWallah (Canon) on Feb 25, 2019 at 19:17 UTC
This is NOT a good idea (Breaks encapsulation) .. but it could work for a POC for this case: `$$self->{MyAdditionToFURL}= "MyValue"; #<< Extra "$" here, to access the extra indirection used by 'furl'` [download] (UNTESTED) As a computer, I find your faith in technology amusing.	[reply] [d/l]
Re^4: Inheritance problem: Not a HASH ref by bliako (Abbot) on Feb 26, 2019 at 13:16 UTC
Thanks for the word of caution NetWallah and stevieb. Stability is in the $^&Ł@& of the beholder, I say, though it sounds cockier than it is. As a side remark, personally I would never publish anything which can not be expanded or inherited by 3rd party. If I can't do it, even if it is "lightning fast" I would consign it to the catacombs. But everyone is different and everyone has their reasons and not everyone can write "lightning fast" browsers. For the record, Furl does not offer adding callbacks (LWP::UserAgent's `add_handler()`) to be called at the various phases of the transaction, so it does not serve my purpose. I ended using LWP::Protocol::Net::Curl which, so far, keeps its word as "drop-in curl replacement for LWP::UserAgent", including callbacks and some speed improvement by mere `use LWP::Protocol::Net::Curl; uuse parent 'LWP::UserAgent';` bw, bliako	[reply] [d/l] [select]
Re^4: Inheritance problem: Not a HASH ref by bliako (Abbot) on Feb 26, 2019 at 14:03 UTC
Breaks encapsulation I have been regurgitating this for awhile and I wonder if it isn't too extreme. In the sense of "since when inheritance breaks encapsulation?"	[reply]
Re^5: Inheritance problem: Not a HASH ref by tobyink (Canon) on Feb 26, 2019 at 17:08 UTC
Child classes shouldn't rely on private implementation details of their superclass. Some OO languages have the concept of "protected" parts of their API somewhere between public and private — methods/attributes which subclasses may use, but are otherwise not part of the public API. In Perl, this can only really be accomplished by convention. http://blogs.perl.org/users/toby_inkster/2014/07/method-privacy-in-perl.html toby döt ink	[reply]
Re^6: Inheritance problem: Not a HASH ref by bliako (Abbot) on Feb 26, 2019 at 21:56 UTC
Re^7: Inheritance problem: Not a HASH ref by Corion (Patriarch) on Feb 26, 2019 at 22:02 UTC
Some notes below your chosen depth have not been shown here
Re^7: Inheritance problem: Not a HASH ref by tobyink (Canon) on Feb 28, 2019 at 12:25 UTC
Re^4: Inheritance problem: Not a HASH ref by bliako (Abbot) on Feb 25, 2019 at 19:40 UTC
that works, thanks	[reply]
Re^5: Inheritance problem: Not a HASH ref by stevieb (Canon) on Feb 25, 2019 at 23:28 UTC
Understand clearly that NetWallah is suggesting something that can break things very easily and subtly. Please review that post, where it was said "not a good idea". Do not break things like this. Do not work this way. It was a concept piece of code that shows 'how' you could do something, not how you should do something. If you continue on this path now, you'll do so going forward. Don't. Proof of Concept chunks of code are just that... tests.	[reply]