use Perl

• Is it really a problem? (Score:2)

  by autarch (914)

  I agree, allowing tags to be mutable is silly, but has that actually been a problem for you in practice. I don't recall ever actually modifying the contents of stuff under a tag, and you can always revert it.

  As far as the checkout thing goes, that'd be annoying, but I've never done that either. When I want to make a tag I always operate directly on the repo URI:

  svn cp http://.../svn/Foo/trunk [...] http://.../svn/Foo/tags/2.0 [...]

  Yeah, distributed VCS is probably better in lots of ways, but Subversion works well enou
  • Re: (Score:2)

    by Shlomi Fish (918)

    I agree. The subversion tagging concept is perfectly acceptable because you can always revert them (using "svn revert" or "svn copy -r"), and changing the contents of the tags is unlikely. There are three similar issues with Perl:

    1. using my/our for constants [perl.org.il] - that's what I use most of the time, because it gives me most of the benefits of Readonly that Damian mentions in his book. Again, I might change them, but it's not very likely, so it doesn't matter
    2. Using a leading underscore for private methods ("
    • Re:Is it really a problem? (Score:1)

      by Aristotle (5147) <pagaltzis@gmx.de> on 2008.10.19 8:20 (#65475) Homepage Journal

      I might change them, but it’s not very likely

      But what’s the failure mode? More than likely, if you do happen to change a constant, you will probably have mysterious bugs that do not obviously point to the culprit. It can potentially take a huge amount of time to track down the issue. The rationale is the same as with using strict, only more polarised. Therefore, for constants, I have gotten into the habit of doing the following:

      our $ANSWER; BEGIN { *ANSWER = \42 }

      Trying to mutate $ANSWER or assign to it will throw a “Modification of a read-only value attempted” error.

      the added benefit of having true encapsulation and permissions in Perl’s OO is usually not worth it.

      You know now what you speak of. The problem is that if I write a Foo::Bar subclass of the CPAN module Foo and I add a private method _baz for my purposes, then if Foo is updated and itself ships a _baz method that was not there before, then Foo::Bar objects will break because Foo methods expect to get Foo::_baz when they call $self->_baz, but they get Foo::Bar::_baz instead. This has nothing to do with enforced privacy. I would be happy to let anyone call my Foo::Bar::_baz if they were actually looking for it. So I want to be able to say “only dispatch here if it’s me asking for it or someone else comes looking for it.” Therefore, I have gotten into the habit of replacing the following:

      sub _baz { ... }
      sub quux { ... ; $self->_baz( ... ); ... }

      with the following:

      our $baz; BEGIN { $baz = sub { ... } }
      sub quux { ...; $self->$baz( ... ); ... }

      Reply to This

      Parent