in reply to Typeglob substitution in objects based typeglob

See HTTP::Daemon which subclasses IO::Socket::INET globs to hang its state off.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re: Typeglob substitution in objects based typeglob

Replies are listed 'Best First'.
Re^2: Typeglob substitution in objects based typeglob
by OlegG (Monk) on Jan 19, 2011 at 14:02 UTC
    I think I do not need subclassing. I need to override CORE::connect. But module IO::Socket::WhatEver, which used inside myconnect() can't use passed socket, it creates its own. But how can I combine this new socket with passed socket?
[reply]

      The advantage of subclassing might be that you can keep the effects of overriding local to where you actually need it.  Overriding the system builtin with 

      BEGIN  {
    *CORE::GLOBAL::connect = sub (*$) {  
        ...
    }
}

      [download]

      would (as the ::GLOBAL hints at) be global — which might or might not be what you really want...

      I'm not really sure I understand your basic design: why would an existing socket be passed to your myconnect(), which cannot really be used, and thus needs to be replaced or "merged" with another one? Why not create a proper one in the first place? What is the relation of the existing socket with the new custom one, i.e. what functionality or data would it share? Could you elaborate on your usage context?

[reply]
[d/l]
[select]
        >I'm not really sure I understand your basic design
        I updated my first message. Please read it.
[reply]

In Section Seekers of Perl Wisdom