Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Tiny Frameworks

by Ovid (Cardinal)
on Sep 29, 2007 at 18:25 UTC ( #641718=perlmeditation: print w/replies, xml ) Need Help??

Rather than have a reply buried somewhere in this thread where it might get missed, I bow to consensus and and agree that I was wrong. Sorry for all of the hullabaloo :) (though I see from comments below that not everyone disagreed with my post)

It seems that the work "framework" has fallen out of fashion in some circles. In fact, many programmers sneer at the thought of frameworks. This is disappointing because a framework, to borrow the Wikipedia definition, is merely a conceptual structure to solve a complex issue.

We might think of things like J2EE, Catalyst, or other things as frameworks and be scared of them. This is sad because those can be great tools, but the important thing is to understand the problem you are trying to solve and decide if the framework is applicable to this problem. In reality, general purpose frameworks such as Catalyst often offer a lot more than you need or solve problems in a different way from what you expect. The might be huge and have a steep learning curve or they might be so simple as to not solve your needs. In this meditation, I want to describe a very common problem and offer a simple framework to solve it. In fact, the framework is so simple that it's merely a small class, but it can save much work later on.

Disclaimer: I'm not going to pretend that my framework is a general purpose solution for you or that it's the right solution for any problem. In fact, I can definitely point out some flaws in in, but it's merely intended as an example of one way of bringing structure to your code. I'm also going to touch on the highlights of the code and let you work out the details for yourself.

The problem: you want to quickly prototype classes for your code in a way that is easy to learn.

The solution: a tiny superclass.

Some of you might argue that a single superclass is not a framework. However, remember that a framework is merely a way to solve a complex problem. This does not mean that the framework must be complex. The simple framework that I am presenting offers the following:

  • Built-in class data
  • Blessed hashrefs (because all OO programmers know them)
  • A standard constructor
  • Easy validation of presence of constructor arguments
  • Easy getter/setters

The framework is simplistic, but that's the point. What it brings is a consistency to class construction. As a result, if all of your classes are based on it, programmers coming into your project easily learn how to create and use new classes rather than wondering "what's the constructor name? How do I handle class data? What are the constructor arguments? How are errors handled?"

First, let's call the class My::UNIVERSAL. It's intended that most if not all of your classes will inherit from this or from another class which does. We're not sticking anything directly into UNIVERSAL because we don't want to introduce a global change which might have unexpected side-effects on modules which don't use this.

Now, the first thing we want to do is handle class data (strict and warnings should be included but are omitted to keep the examples simpler):

package My::UNIVERSAL; use base qw(Class::Data::Inheritable); 1;

Now every class which inherits from this gets class data for free. That's not a huge win, but we can also get accessor/mutator method generation for free:

package My::UNIVERSAL; use strict; use warnings; use base qw( Class::Data::Inheritable Class::Accessor ); 1;

Now that sort of works, but there are some problems with this:

package Creature; use base 'My::UNIVERSAL'; __PACKAGE__->mk_classdata( mortal => 1 ); __PACKAGE__->mk_accessors( qw/name gender/ ); 1; # in the code my $creature = Creature->new({ name => 'Alice', gender => 'female', } );

In the above example, the resulting data structure looks like this:

$VAR1 = bless( { gender => 'female', name => 'Alice' }, 'Creature' );

For this simple example, this seems fine, but as many who have worked on large code bases can attest, accidentally overwriting a hash key in a blessed hash can cause bugs which are very painful to track down. Further, Class::Accessor, while useful, has mutators which return the value we're setting the objects to. In other words:

print $creature->gender('male');   # prints 'male'

If you like to chain method calls, that doesn't work.

As an added issue, passing unknown hash keys results in those appearing in blessed hash. We'll deal with that later, but for now, let's dispense with Class::Accessor and write our own. We want it to make keys local to the class we're using and to return the invocant (the object) when setting a value.

sub mk_accessors { my ( $class, @accessors ) = @_; foreach my $accessor (@accessors) { no strict 'refs'; my $key = "$class\::$accessor"; *$key = sub { my $self = shift; return $self->{$key} unless @_; $self->{$key} = shift; return $self; }; } }

With this, all keys in the hashref are now prepended with the package name. Now this might seem like a pain to type out, but if you use those methods internally in your class, it's not so bad. Imagine a Rectangle class:

sub area { my $self = shift; return $self->height * $self->width; }

That's easy to read and pretty self-documenting.

Getting rid of Class::Accessor means we no longer have a default constructor, so let's add one.

use Scalar::Util 'reftype'; sub new { my ( $class, $args ) = @_; $args = {} unless defined $args; unless ( 'HASH' eq reftype $args ) { croak "Argument to new() must be a hash reference"; } my $self = bless {} => $class; while ( my ( $key, $value ) = each %$args ) { $self->$key($value); } return $self; }

And the constructor does not change, but look at the object now:

$VAR1 = bless( { 'Creature::gender' => 'female', 'Creature::name' => 'Alice' }, 'Creature' );

Now instance data is per class and we can chain method calls if we prefer this style (separate method calls are always fine):

$creature->name('Bob') ->gender('unknown');

Also, let's look at what happens if we try to add an unknown key:

my $creature = Creature->new( { name => 'Alice', gender => 'female', foo => 1, } );

This results in the error Can't locate object method "foo" via package "Creature". Very handy!

At this point, we have a useful but simplistic class creation framework. However, there are a couple of features we want. Perhaps "name" is mandatory but "gender" is not. Let's add a couple of helpers for this. The code here is going to get a bit magical for a couple of reasons. First, we want something that's easy to use and sometimes you need to do funky things under the covers. Second, in refactoring out some common code, we can lose the return value of wantarray because, unlike caller, wantarray does not allow you to inspect higher stack frames. Thus, we'll use a "magic" goto to ignore the existing stack frame (see the documentation of goto for an explanation) We'll also have to change our constructor for this.

__PACKAGE__->mk_class_data('__data_key'); sub new { my ( $class, $args ) = @_; # XXX I don't like doing this for every instance, but # use 'base' doesn't call import() my $key = " $class data "; $class->__data_key($key); $args ||= {}; unless ( 'HASH' eq reftype $args ) { croak('Argument to new() must be a hashref'); } my $self = bless { $key => $args } => $class; $self->_initialize; delete $self->{$key}; return $self; } sub _initialize { my $class = ref($_[0]); croak "_initialize() must be overridden in a ($class)"; } # a truly private method! my $check_attribute = sub { my ( $self, $attribute ) = @_; my $value = delete $self->{ $self->__data_key }->{$attribute}; if ( ! defined wantarray ) { $self->$attribute($value); } else { return $value; } }; sub _must_have { my ( $self, $attribute ) = @_; croak("Mandatory attribute ($attribute) not found") unless exists $self->{ $self->__data_key }->{$attribute}; goto $check_attribute; } sub _may_have { my ( $self, $attribute ) = @_; return unless exists $self->{ $self->__data_key }->{$attribute}; goto $check_attribute; }

We now create a subclass as follows:

package Creature; use base 'My::UNIVERSAL'; __PACKAGE__->mk_classdata( mortal => 1 ); __PACKAGE__->mk_accessors(qw/name gender/); sub _initialize { my ( $self, $args ) = @_; $self->_must_have('name'); $self->_may_have('gender'); }

Pretty simple, eh? If we're missing 'name' in the constructor, creating the class will fail. The 'gender' attribute is still optional.

But what's with the wantarray stuff? Well, it's possible that the accessor has a different name, so we support that:

package IP::Address; use base 'My::Universal'; __PACKAGE__->mk_accessors('address'); sub _initialize { my $self = shift; $self->address( $self->_must_have('ip') ); } 1; # use IP::Address; my $ip = IP::Address->new({ ip => $some_ip }); print $ip->address; # prints $some_ip

Of course, having different accessors for property names can quickly get confusing, but it's now there if you need it.

Another problem we want to solve is passing unknown attributes to the constructor. Because our constructor is deliberately destructive to the hashref passed into it, this makes this simple. We'll add a private $check_keys method and tweak our constructor a little.

my $check_keys = sub { my $self = shift; my $data = delete $self->{ $self->__data_key }; if ( my @keys = keys %$data ) { local $" = ', '; croak("Unknown keys to constructor: (@keys)"); } }; sub new { my ( $class, $args ) = @_; my $key = " $class data "; $class->__data_key($key); $args ||= {}; unless ( 'HASH' eq reftype $args ) { croak('Argument to new() must be a hashref'); } my $self = bless { $key => $args } => $class; $self->_initialize; $self->$check_keys; return $self; }

And let's see what happens with this:

my $creature = Creature->new( { name => 'Alice', gender => 'female', foo => 1, bar => 1, } ); # Unknown keys to constructor: (bar, foo)

We have now met all of our original design goals. There are plenty of other improvements we could make. Standard _carp and _croak methods might be useful. Perhaps proper exception handling would be good. And, of course, if we wanted this to be a serious class, we would have to modify mk_accessors to allow for proper data validation:

package Tall::Square; use Scalar::Util 'looks_like_number'; use base 'My::UNIVERSAL'; __PACKAGE__->mk_accessors( width => sub { looks_like_number($_[1]) && $_[1] > 0 ), height => sub { my ( $self, $height ) = @_; return looks_like_number($height) && $height > $self->width; }, ); sub _initialize { my $self = shift; $self->_must_have('height'); $self->_must_have('width'); } sub area { my $self = shift; return $self->height * $self->width; } 1;

Adding that is left as an exercise to the reader.

This simple class construction framework is not intended to be a serious framework (you might consider Moose or something similar), but it does show that frameworks need not be complex and they can reduce the tedium of 'grunt work' that can come with writing code. Remember that just because general purpose frameworks are often huge and have more features than you need, creating and using one for your personal or professional code does not have to be a bad thing.

package My::UNIVERSAL; use strict; use warnings; use Scalar::Util 'reftype'; use Carp 'croak'; use base qw(Class::Data::Inheritable); __PACKAGE__->mk_classdata('__data_key'); sub mk_accessors { my ( $class, @accessors ) = @_; foreach my $accessor (@accessors) { no strict 'refs'; my $key = "$class\::$accessor"; *$key = sub { my $self = shift; return $self->{$key} unless @_; $self->{$key} = shift; return $self; }; } } my $check_keys = sub { my $self = shift; my $data = delete $self->{ $self->__data_key }; if ( my @keys = keys %$data ) { local $" = ', '; croak("Unknown keys to constructor: (@keys)"); } }; sub new { my ( $class, $args ) = @_; my $key = " $class data "; $class->__data_key($key); $args ||= {}; unless ( 'HASH' eq reftype $args ) { croak('Argument to new() must be a hashref'); } my $self = bless { $key => $args } => $class; $self->_initialize; $self->$check_keys; return $self; } sub _initialize { my $class = ref($_[0]); croak "_initialize() must be overridden in a ($class)"; } my $check_attribute = sub { my ( $self, $attribute ) = @_; my $value = delete $self->{ $self->__data_key }->{$attribute}; if ( !defined wantarray ) { $self->$attribute($value); } else { return $value; } }; sub _must_have { my ( $self, $attribute ) = @_; croak("Mandatory attribute ($attribute) not found") unless exists $self->{ $self->__data_key }->{$attribute}; goto $check_attribute; } sub _may_have { my ( $self, $attribute ) = @_; return unless exists $self->{ $self->__data_key }->{$attribute}; goto $check_attribute; } 1;

Update: Fixed a typo noticed by calin whereby I referred to a superclass as a subclass.


New address of my CGI Course.

Replies are listed 'Best First'.
Re: Tiny Frameworks
by BrowserUk (Pope) on Sep 30, 2007 at 14:58 UTC

    As one of those who has expressed skeptisim about "frameworks" here, I'll have a go a producing a definition. Or rather, a comparison between a 'framework' and a 'library'.

    • A framework provides the common infrastructure supporting a definied architecture for a class of applications.

      (IMO) the key element of a framework is that it provides the structure of an application and leaves the application programmer to fill in the details of the specific application.

      As the label suggests, this is analogous to the framework, infrastructure of (say) an office building within which you can conduct any type of business. You would normally require a different type of framework for a domestic building or a warehouse operation etc.

    • A library (or abstract class) provides a service to any application that needs that service.

      A library encapsulates the detail of some specific service or algorithm and allows the application programmer to ignore the details. It can be called from any kind of application.

      This is analogous to (say) the telephone system. The system stays essentially the same (whilst varying in scale), regardless of the purpose of the building (application).

    In a nutshell, frameworks call you; you call libraries.

    Whilst what you describe provides the infrastructure for the creation of classes, the classes produced using it would usually be more akin to libraries. That is, classes built using your infrastructure would themselves be components within larger applications, and there would often be several such derived classes within any moderately sized application.

    So whilst it is possible to see how you arrived at the term 'mini-framework', my gut feel about what constitutes a framework is that they provide the outer shell and overall structure for an application along with the stubs for essential plumbing. Viewed this way, your module doesn't really live up to the tag. As useful as it is, I would consider it the wrong label.

    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.

      While I knew my post would be controversial, the distinction I'm not seeing from people is the dividing line between "library" and "framework" (in the same way, perhaps, that many cannot define "pornography" or "enterprise code"). Perhaps I'm being a bit slow, but the only significant difference I see between our definitions of "framework" is that yours is more verbose. There's a certain irony there :)

      In my case, the "class of applications" this code provide a defined architecture for is "all OO applications." I'm not limiting myself to Web apps, ORMs, or something similar. So using less code to support a greater range of applications than most frameworks support somehow makes it not a framework? Believe me, I did my reading on this and I'm convinced that the word "framework" is misleading the hell out of people. It's a buzzword I want to smash under my foot.

      So I provided what I refer to as a "tiny" framework. Imagine at some point that someone comes along and provides better method validation. Someone else comes along and adds integrated exception handling. Someone else comes along and adds a persistence mechanism. Someone else comes along and calls it a framework. At that point, some people jump on the bandwagon and some people sneer.

      If the mere act of calling something a framework makes it a framework, then my code qualifies. If it doesn't make something a framework, then when in the above sequence of events did it become one and why? There's nothing magical about frameworks. There is no minimum size/complexity/buzzword requirement for them. However, it seems to me that in the back of people's minds they seem to think that a framework must somehow be big and restrict the scope of things that can be worked on -- of course, mine doesn't do anything for non-OO code, so maybe it qualifies? :)

      Oh, and thanks for actually providing your own definition, unlike the Anonymous Monk above. I appreciate that :)


      New address of my CGI Course.

        Is pointillism a frame? Pointillism is a technique to use when making paintings. A frame gives you a structure to put your painting inside of. It is not a coincidence that the word "framework" contains the word "frame". BrowserUK's definition was not just "more verbose". It was also certainly less vague. It made great points about the type of structure a framework is.


        I'll either somewhat disagree with or somewhat augment what BrowserUK said by saying that his definition sounds like what I would call an "application framework" and there certainly could be a "library framework". But a "library framework" would need to define the "outer shell" and over-all structure of the library and provide ways for people to put different guts inside of that. And the term "framework" as applied to software is most often used to mean "application framework" (IMHO, of course).

        I'm unsure whether using "framework" for non-application frameworks is desirable / useful terminology. Certainly, people shouldn't be afraid of developing software in a structured manner, though.

        - tye        

        1 Update: Ooh, that could be taken quite harshly; like I was saying Ovid is worse than an idiot. That certainly wasn't my intent and I apologize. I certainly don't belive Ovid is an idiot. I think Ovid should re-read BrowserUK's description. And I made note of the fact that one anonymous reply re-stressing part of the distinction that I think Ovid may not have fully appreciated.

        "controversial" means argurable, in this case, you don't have a point at all. By the way, BrowserUK didn't provide his definition, as that's everyone's definition, oh not yours obviously.

      Boy, I'm coming late to this party. Sorry about that. The following is asked in the interest of understanding your (and by extrapolation Tye's) points. It may seem that I'm supporting Ovid's point, but really the most accurate statement of my position is "confused".

      If in the examples in the OP, the data about the Creature package were extracted to, say, XML, could you then call this a "framework for declarative creation of classes"? It seems to me that this constitutes the details to be filled in by the application programmer. I haven't used Hibernate, but wouldn't that be just one level down from what Hibernate does (declarative objects, plus how they relate, whereas this would be just declarative objects)? Does it matter whether those details are provided by the application programmer as XML (like in my hypothetical) or as structured code (like the original example)?

      I guess part of Ovid's point was to explore the grey areas in the use of the term and now I feel caught up in that gery area. Again, I ask for the sake of clarification. I don't have skin in the game either way.

      Goibhniu stops previewing, takes a deep breath and pushes create . . .

      I humbly seek wisdom.

        Hmm. From my perspective this is all about terminology. Let's try an analogy:

        When they built The Swiss Re Tower, some company was charged with the manufacture of the 5500 triangular and diamond-shaped glass panels that form the outer cladding. As these panels vary in size for each of the 40 floors, there was no doubt some mechanism for inputing the required sizes for each of the aluminium extrusions that make up the panels to the (probably digitally controlled) cutting machines.

        In terms of the manufacture of the panels, that mechanism may have been seen as some kind of a "framework". But in terms of the construction of the building, the term "framework" was probably reserved for the steel 'diagrid' that forms the overall shape and load-bearing structure for the building.

        There are already many terms for tools that are used to construct classes: Library; toolkit; Meta class; Specification language; Class Factory; etc. All of which make more or less sense depending upon the philosophy behind them; the interface they present; the way they operate; and the way they are intended to be used. Do a CPAN search: Class::* and read the first few lines of each module (say the first couple of hundred) for examples of all these and more.

        There seems little purpose in taking a term 'framework', that already has a fairly intuative interpretation, and qualifying it with 'tiny', in order to bend it to fit a conceptual space that is already heavily overloaded with terminology.

        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.

      A very good point, framework calls you, and you call library.

      Framework is a set of rules and conventions, you supply the details to the framework, and you expect the framework to call your detailed implementation according to the rules at the right time for the right thing.

      Bravo! Now I know why we didn't drown in the sea of frameworks as I said: most people are wise.

Re: Tiny Frameworks
by kyle (Abbot) on Oct 01, 2007 at 01:39 UTC

      I cealrly doubt your logic. You did a search, and there popped up some posts that might support Ovid's and your idea, bingo here you go. You said "(not) out of the ordinary", your ordinary is obviously not so ordinary.

Re: Tiny Frameworks
by dsheroh (Prior) on Oct 01, 2007 at 15:18 UTC
    Although I see you've already bowed to consensus, Ovid, I'd like to thank you for raising the question. Despite the anonymonk's insistence that you're stupid and foolish to have done so instead of simply following "commen sense"(sic), I find that progress can come only from questioning the status quo.

    Back on-topic, I do agree with the general consensus that your example is not what I would call an (unqualified) "framework", as I interpret a "framework" as something which tells you how you should create your code and, in the process, necessarily constrains that code. (If you don't comply with its constraints, you can't use whatever services the framework provides.) My::UNIVERSAL does not tell you how to structure your code overall, nor does it lead to any wide-reaching constraints, so I don't believe it qualifies as an application framework, which, as tye pointed out, is what is normally meant when "framework" is used alone.

    I could, however, go along with calling it a very-light-weight OO framework, as it does suggest and provide a structure for the OO implementation of code which uses it. The constraints it places are very few and very likely to be well-repaid with increased functionality for decreased effort, so I'd even call it a well-designed OO framework. But it's still a framework for OO only, not a general framework.

      Your opening statement only cheapened your post. It is important to get concepts right, who cares whether Ovid's feeling got hurt. All you said is that "yeah you are wrong but you are not stupid". There is clear evidence that he is wrong, and which implies in this case he is stupid. Not saying he is stupid all the time, pay attention to my qualifier "in this case". Moscow does not believe tears.
        You apparently missed my point, so let me spell it out more clearly:

        Right or wrong, it is a good thing to ask questions and make statements that most people disagree with. Just because something is widely accepted as true does not make it so. Even if the masses are correct, questioning their belief can bring progress, both through the questioner learning about the subject of their question and through others questioning their own beliefs.

        In this particular case, I had never really thought before about what I consider a "framework" to be and I am genuinely glad that Ovid asked the question and prompted me to think about it. That is why I thanked him, not because I was worried about his feelings - I assume that, like most of us here, he's mature enough that disagreement (whether reasoned like most of ours or steeped in ad hominem like yours) isn't going to injure him.

        And I still haven't seen a definition of "framework" from you. Have you thought about how you define the word or are you just leaving it as a vague, undefined "I know it when I see it" concept? If you don't want to share your definition, you don't have to, but, if you haven't thought about it, then what are you getting from your participation in this thread beyond an opportunity to call people names?

Re: Tiny Frameworks
by toma (Vicar) on Oct 02, 2007 at 02:08 UTC
    Ah, a framework flame fest! I remember those from the CAD business in the early 1990's. At first, frameworks were touted as platforms for interoperability between different vendor's products. This definition didn't seem to conform to reality.

    A definition for 'CAD Framework' that I heard in the late 1990's is that a framework is the 'outer window' of a CAD application. CAD tools often have a lot of little windows that are confined inside a larger window. So whatever structure implements the outermost window of the application is the framework. With this type of definition, you could say, for example, that a web browser is a framework for a web application.

    For business lock-in, many software vendors want to own and control the framework. For example, microsoft has ie/iis to lock in their web products.

    Some of the derision that people feel towards frameworks may come from the difference between the hype: 'The framework is a platform for interoperability' and the reality: 'The framework is the mechanism for vendor lock-in.'

    IIRC There is another definition of framework from AI that may be a little closer to Ovid's idea.

    It should work perfectly the first time! - toma

      We are talking about today, not past, so Ovid's is not framework unless it fits today's definition or more precisely common sense.

Re: Tiny Frameworks
by dmorgo (Pilgrim) on Oct 03, 2007 at 05:52 UTC
    My, how the years have flown here at the monastery since this writeup was created.

    Now that the framework-or-not-framework question has been beaten to death, can I ask a naive question? What modules are people using for class creation these days, and why?

Re: Tiny Frameworks
by Anonymous Monk on Sep 30, 2007 at 08:21 UTC
    Two things
    If you called your invention something like "a nice class", it fits much better.
    Not to mention, your class is not even needed in modern languages, as it would be free.

      I'm mainly trying to break the misconception in people's minds that frameworks have to be huge or bad (I hear both quite a bit). And you're right, that code would not be needed in modern languages. It's one of my greatest frustrations with Perl 5.


      New address of my CGI Course.

        You didn't break others' misconception, but your understanding is broken.

        So this one is not huge and bad, but tiny and not qualified.

        I may seen to be mean in other posts, but you know what, I totally understand your frustration towards Perl's non-OO. My XP points here is higher than the vast vast vast vast majority, but I left Perl for Python, so I can still feel sane.

        There wasn\t much need for me to be mean, but that's just the way of talking, however, call your 'framework' something like superclass or if you prefer big word, "methodology"... To argue the concept is useless. I watched the chatterbox a bit, I am glad most people around are still reasonable.

Re: Tiny Frameworks
by Cop on Oct 17, 2007 at 01:05 UTC

    What is framework? One of the project I led created a C# framework, and now every piece of C# code the company produces follows the framework. What does it do?

    For example, you define a tab, tell teh framework, it will display for you in a multi-tab window. The tab subscribe to certain events, and the framwork will refresh data for you (communication between tabs).

Re: Tiny Frameworks
by Cop on Oct 01, 2007 at 16:04 UTC

    Nobody bothered to use any example to prove a point.

    J2EE is a framework. You supply your beans according to certain format, J2EE implementation runs them according to predefined protocol, and you got your result. That's framework.

Re: Tiny Frameworks
by Anonymous Monk on Sep 30, 2007 at 03:15 UTC
    With my SYSTEM you can be twice as mean
Re: Tiny Frameworks
by Anonymous Monk on Sep 30, 2007 at 08:15 UTC

      Forgot to mention, click Peter on the menu and chose computer submenu.

        In that link, you wrote (other folks might want to read it for context):

        Before I start to talk about framework, I would like to make sure that nobody smell Ovid's class as framework, as if anyone would thought that way. If that is framework, we have all drowned in the sea of frameworks already. Thanks god, not many people are as ignorant as Ovid, and has the guts to call their classes frameworks.

        When you (or someone) wrote that, you forgot one thing: to define a framework. Nowhere in your short rant did you provide something which should have been obvious. You see, I defined a framework. What probably surprises many people is that something that small can be a framework (I knew there would be people who jumped at that bait and I'm afraid you're the fish on my hoook). Many people have this silly notion that frameworks have to be huge. They don't. The sooner you get over this misconception, the better. Do you have this strange notion that a framework must have at least 297,173 lines of code and a core of at least 13 developers?

        A framework is a merely general solution to a complex problem. By creating said solution, you can gain the benefit of a standard, predictable approach to a problem. The problem space I chose to attack was some difficulties with the Perl 5 language and I created a tiny framework whic attempted to address this. Sure, it's going to be startling to be people who are used to assuming that you must have X number of lines of code to call yourself a framework. Of course, there are also lots of programmers out there who think you have to have an IDE to be a professional programmer.

        Or if you want, we can get down to a more specific definition of a software framework:

        A software framework is a reusable design for a software system (or subsystem). This is expressed as a set of abstract classes and the way their instances collaborate for a specific type of software.12 Software frameworks can be object-oriented designs. Although designs don't have to be implemented in an object-oriented language, they usually are. A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed through an application programming interface (API).

        Hmm, let's see: I have provided one abstract class (a set with only one member is still a set). An abstract class isn't enough to be a framework, but my code definitely meets the core criteria of a reusable design for a software system. In fact, it's clearly a general solution to a common problem with a standard API exposed. There are other bits (helper scripts and so on) which people often expect in a framework, but they're certainly not required. Wow, my code meets the definition of a framework! Imagine that, Ovid did his homework. Surprising, eh?

        So, if you care to rebut this, please start by providing your definition of a framework. No definition, no rebuttal. Mind you, if you do post a definition, please provide either a source for that definition or why you think your definition is appropriate.


        New address of my CGI Course.

        I followed your links and found a shallow, poorly written rant that fails to provide any refutation of Ovid's ideas. In fact it appears to be more an ad hominem attack against Ovid specifically and Perl programmers in general. Until you can manage to provide any sort of intelligent counter argument, I suggest that you find another place to post. I don't speak for anyone but myself, but I don't appreciate pointless attacks against people who are actively trying to create constructive dialog and new ideas.

        "Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://641718]
Front-paged by lidden
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2018-07-17 06:15 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (355 votes). Check out past polls.