Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re^6: Depends...

by Purdy (Hermit)
on Dec 02, 2004 at 16:48 UTC ( #411854=note: print w/replies, xml ) Need Help??

in reply to Re^5: Depends...
in thread Review: CGI::Prototype

I'm not sure what to say here... probably nothing. ;) I cannot grasp what you're really talking about and my cynicism meter goes up when people start throwing out large CS words. What's wrong with an if statement?

Can you elaborate more on what you're trying to do? It sounds like:

A (mainscreen) -> B (some dynamic data) -> C (data entry) -> B|C

That right? If so, what does B do differently when it doesn't come from A?

Replies are listed 'Best First'.
Re^7: Depends...
by demerphq (Chancellor) on Dec 02, 2004 at 18:24 UTC

    What's wrong with an if statement?

    The main problem with an if statement versus polymorphism is where the logic resides. The former leaves the logic in the routine with the if, so we have something like this:

    *isa=*UNIVERSAL::isa; sub with_the_if { ... if (isa($foo,'Type1')) { return $foo->method1 } elsif (isa($foo,'Type2')) { return $foo->method2 } else { return $foo->method3 } }

    This is problematic because it makes thing hard to extend later on. The OO way to do it puts the logic on the OUTSIDE of the routine with the if. So now we do:

    sub Type1::generic_method { $_[0]->method1 } sub Type2::generic_method { $_[0]->method2 } sub TypeX::generic_method { $_[0]->method3 } @Type1::ISA=@Type2::ISA=qw(TypeX); sub with_the_if { ... return $foo->generic_method }

    Now code in with_the_if() doesnt have to change when a new type gets added to the framework. It-just-works because whichever type $foo is there will be a generic_method defined that knows what to do. (Or there should be if its work properly). Now to change the behaviour of the system the outside user never has to touch with_the_if(), he just needs to define Type9::generic_method().

    BTW, this isnt meant to add anything to the C::P vs C::A debate, I know neither well enough to say anything, but just an answer to the one question.


      Thanks for going into more detail. I'm not versed enough in C::P to know if it is good enough for this, either, but I'm sure C::A was not designed for a polymorphic view of the world. And I'm also sure that polymorphism is the way to go for this task.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Re^7: Depends...
by hardburn (Abbot) on Dec 02, 2004 at 18:01 UTC

    In my case, "mainscreen" would be misnamed. For one of my projects, it went:

    A (mainscreen) -> B (data entry) -> C (dynamic entry in a loop) -> D (preview, with option to go back and edit) -> E (finish, with all data being saved to database)

    I'm not saying that C::A can't do this (far from, for I did indeed write the above in C::A), but that the result isn't very clean.

    What I want is a subroutine call which decides which state the application is in and returns an object. You don't care what the object actually does, but you are guarenteed that it has certain methods. You take that object, call the methods as perscribed in the API, and eventually get back some HTML to display to the user (or maybe the object did that on its own). Meanwhile, the object takes care of parameter checking and saving things to databases and such.

    That's polymorphism. The logic is take care of by having the right objects in the right place, not by conditionals.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://411854]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (1)
As of 2021-07-31 04:06 GMT
Find Nodes?
    Voting Booth?

    No recent polls found