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

139Re: [extremeperl] The Bivio naming scheme and the Perl community ethic

Expand Messages
  • Rob Nagler
    Feb 25 10:29 PM
    • 0 Attachment
      bauhaus@... writes:
      > It is kind of hard to understand why Bivio is not offered in separate
      > easy to understand components:

      Difficult question. The folks who haven't worked at bivio, probably
      can't answer this question. Answers from bivions probably look like
      an excuse. Double bind. Oh well, I'll give it my best shot.

      > + Bivio has a naming scheme that is incompatible with CPAN.

      TIMTOWTDI. :-) Why is CPAN incompatible with the world? The postal
      system was designed a couple of years before CPAN. Why are addresses
      in Europe big endian and addresses in the US little endian? Such is
      life.

      Frankly, I've never been able to figure out CPAN's naming or
      categorization system. Let's look at:

      http://cpan.uwinnipeg.ca/chapter/Opt_Arg_Param_Proc

      ("chapter" in the URI is a "category", why two names?) On this page,
      you have: App, Bio, ClearCase, ctflags, GetArgs, HH, Maypole, P4,
      Parrot, Script, AppConfig, Bryar, Config, DNS, Getopt, Java,
      OpenInteract, Pangloss, POEST, User, Argv, Buscador, ConfigReader,
      Fry, Haver, Mac, OpenPlugin, Params, Resources, and XAO.

      This is a whimsical naming scheme at best and chaotic at worst. Why
      is Bivio::* any different than ClearCase::*?

      > It is Java-inspired.

      Once and only once doesn't mean "the CPAN way". Java isn't the only
      way either, but we shouldn't ignore its solutions. Rather we should
      study them, and adopt/adapt them to solve our problems. The same is
      true of other systems, such as, Python, Ruby, Lisp, C, C++, Modula-2,
      Pascal, Ada, ALGOL, and FORTRAN.

      I have always taken the Perl community ethic to mean that we think
      about what we are doing, and don't do something just because someone
      tells us that it is the right way. There is no right way, just the
      way that works best for your problems. bOP evolved with this ethic in
      mind.

      > I tried to ask for more info on Java naming:
      >
      > http://www.javajunkies.org/index.pl?lastnode_id=717&node_id=4159
      >
      > but really could not understand the motivation for it. As long as
      > your package on CPAN has a unique name, it won't conflict with other
      > packages.

      The folks who invented Java had 20+ years on the folks who invented
      CPAN. They lived through the "hosts" file being passed around every
      night before DNS was invented. DNS solved the unique name problem
      elegantly and simply, and well before CPAN or Perl was invented.

      > + Bivio is not on CPAN

      Feel free to mirror bOP on CPAN.

      We have no business need to put bOP on CPAN. Indeed there are many
      things that CPAN doesn't offer us, such as, letting us run a demo of
      the Bivio::* classes (petshop.bivio.biz) and our "view source"
      feature.

      > + Bivio implements all aspects of web application development but not in
      > a way that isolated aspects can be used independantly.

      A misconception. Consider that J2EE is distributed in a bundle (much
      larger than bOP). Anybody doing J2EE is making a choice to buy into
      the J2EE ecosystem. They don't want to download a new module every
      time they want to expand their use/knowledge of the ecosystem. That
      doesn't mean that J2EE is a monolith. It's a collection of layered
      classes just like bOP is.

      > Contrast, for example, with HTML::Mason which has a number of
      > modules of great utility outside of it: Params::Validate,
      > Class::Container, etc.

      Great utility is in the eyes of the user. Params::Validate is of
      little or no utility if you dislike strong typing. Perl is
      weakly-typed. If I wanted strong typing, I'd be programming in Java.

      I can't figure out why I would need Class::Container. Is there any
      problem solved by bOP that would be better solved by Class::Container?
      Parameters are the least of my problems when dealing with inheritance.
      It's unexpected behavior that messes things up.

      Rob
    • Show all 5 messages in this topic