Loading ...
Sorry, an error occurred while loading the content.

Re: [extremeperl] Re: Better Development Tools for Perl

Expand Messages
  • Rob Kinyon
    ... I am a heavy believer in OO methodologies as an important tool in my toolbox and I leverage them in most code I write. Coming from a primarily Perl
    Message 1 of 107 , Jun 19, 2005
    • 0 Attachment
      On 6/19/05, Ed Grimm <ed@...> wrote:
      > On Saturday, June 18, 2005, at 05:41 PM, J Matisse Enzer wrote:
      > > On Jun 18, 2005, at 12:08 PM, Rob Nagler wrote:
      > >> No. There are a number of reasons why you don't want to do this.
      > >> Firstly, you can't know that the following is your "foo".
      > >>
      > >> $o->foo();
      > >
      > > That's part of the problem with current tools. I want to see tools that
      > > *can* figure out if $o->foo() is "my" foo, in most cases.
      >
      > You can't do this without writing something that will break my code. I
      > believe it'll break Rob Kinyon's code even worse, if he uses object
      > method calls in his dynamic code.

      I am a heavy believer in OO methodologies as an important tool in my
      toolbox and I leverage them in most code I write. Coming from a
      primarily Perl background, I'm very cavalier about how I treat
      encapsulation and interfaces. I believe in overloading, judicious use
      of "no strict 'refs';", eval as both compiler and try-catch,
      hand-build switch statements, and a big mixture of all of those. I
      overload isa(), can(), and pretty much anything else I can lay my
      grubby hands on, as well as using overload itself. Pretty much the
      only thing I pause before using is AUTOLOAD, but I'll use it when the
      time is right.

      When you see $o->foo() in my code, you have the following guarantees:
      1) $o is a blessed reference.
      2) ref($foo) is (almost always) in a separate file somewhere.
      3) ref($foo) is (almost always) the package that has promised to implement foo()

      That's about it. As for the "almost always" ...

      - I try to keep my classes in their own packages, except where it
      makes sense to generate them on the fly. (I use Class::DBI::Loader
      which might generate classes for me.)
      - I wrote Class::LazyLoad. It will redispatch to the class that's
      lazyloaded, but ref($foo) may not be what it will be once you do
      something to it.

      > Just because, in your code, $o->foo() is your foo, does not mean that
      > someone using your module will be using your foo at that point. If
      > they're not, the code is broken. If you make changes like this rename
      > in a single release, without a period of deprecation, you will get a
      > reputation among those people who use your modules of releasing
      > unstable code.

      Let's just put it this way - if you make me downgrade your module to
      make it work with my stuff because you changed API and it wasn't a
      major release, I just ripped your module out of my code. End. Of.
      Story.

      > Note that, IMHO, when one deprecates code, one must indicate what to do
      > instead, in addition to saying the code is deprecated, rather than
      > simply reporting "don't do this any more, as we're about to break it."
      > Poorly documented transitions can be nearly as frustrating as
      > undocumented transitions.

      Poorly documented ones are worse than undocumented ones. If it's
      undocumented, I know that I have to go sourcediving. If it's poorly
      documented, I don't know how poorly, so I don't know how much or where
      I need to sourcedive.

      Rob
    • Siegfried Heintze
      Since there was a helpful discussion some time ago on USB keyboards and mice for pair programming that was not specific to perl, I wanted to solicit the group
      Message 107 of 107 , Feb 13, 2006
      • 0 Attachment
        Since there was a helpful discussion some time ago on USB keyboards and mice
        for pair programming that was not specific to perl, I wanted to solicit the
        group for information on network software (also not specific to perl).



        I just set up openVPN on my openwrt/WRT54G router for pair programming with
        a headset and skype.



        (1) Can any point me to the documentation on sharing desktops on windows? I
        need to create accounts on Win2003 XP Server. When I created an account
        belonging only to the user group, my partner could not log in. He was
        receiving some error message about not being permitted to log in
        interactively. However, when I added the administrator group (reluctantly)
        to his account, he could log in. Is there a tutorial somewhere on the web
        for creating user accounts in windows for use with remote desktop logins on
        VPNs?



        (2) How do I share my remote desktop setting with a programming pair
        partner?



        (3) What about sharing sessions when I'm booted with linux? I think there is
        a vnc program out there, but I don't know how to use it. I'll need to learn
        how to create accounts and share linux desktops with remote VPN users. Is
        there a tutorial on this?



        (4) Are video cams very helpful for pair programming?



        It seems that this kind of knowledge would be very common for pair
        programmers.



        Thanks,

        Siegfried



        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.