Posted by Jerry Stuckle on 08/29/07 17:03

Steve wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:W5idncnku_TD10nbnZ2dnUVZ_g6dnZ2d@comcast.com...
> | Steve wrote:
> | > "Michael Fesser" <netizen@gmx.de> wrote in message
> | > news:cng0d3dhkhm507nvjtg590i1gs1bl605ta@4ax.com...
> | > | .oO(Jerry Stuckle)
> | > |
> | > | >But if you change the function name, parameter list and/or return
> value,
> | > | >you have to change all of the code calling it. This is NOT
> refactoring.
> | > |
> | > | http://en.wikipedia.org/wiki/Rename_Method
> | > |
> | > | http://www.refactoring.com/catalog/renameMethod.html
> | >
> | > apparently, i'm not up on my lingo.
> | >
> | > so what if i change an interface with optional parameters? i then don't
> need
> | > to change *any* calling code, yet i've changed the interface. is this
> now
> | > refactoring? further, most php is not written in OOP but with
> proceedural
> | > code. so, the 'interface' would be a browser, in most cases.
> technically, i
> | > could change any and all code yet not be mucking with the 'interface'.
> and
> | > so that we're all clear...an 'interface' *only* exists as a
> communication
> | > point between a caller and an *OBJECT*. functions alone and of
> themselves
> | > are NOT interfaces.
> | >
> |
> | OK, I should have clarified - you can't change the interface except to
> | *extend* it. Adding optional parameters would be extending the interface.
> |
> | In this case, the "interface" wouldn't be the browser - the browser has
> | nothing to do with PHP. Rather, it would be the common function calls.
> | Interfaces existed long before OO programming! For instance, fopen()
> | is an interface to the file system.
>
> well, the op was regarding best programming practices in gereral. either
> way, the user interface is very much a part of any language whether it is a
> command-line or gui. in general, especially in case of the command-line, it
> is equally effected by such changes (think of argument changes or command
> name changes). i understand the difference between what we're talking about
> and this idea, but the two don't always have a black/white distinction. the
> main point i was trying to make is that functions are not interfaces, and if
> they are - such as fopen being an 'interface' to the file system - then so
> too are the methods a user interacts with in an application - their (caller)
> way into accessing a set of features ('interfaces'). such an equation
> doesn't help in distinguishing development tasks.
>

Actually, functions have always been defined as interfaces. Even before
OO programming came along, it was common to build a library of functions
to perform a set of actions - similar to the file calls in PHP and C.

And yes, the methods a user interacts with an application is an
interface - widely known as the "user interface".

>
> | > as far as i'm concerned, when i 'refactor', i'm doing whatever needs to
> be
> | > done to existing code to make it better for no other reason (new
> | > enhancement, new logical/business requirement, etc.) than to make it
> better
> | > (easier to maintain, bring it under standards of practice, make it
> faster,
> | > etc.). imo, it's not worth splitting hairs over. i suppose it is a good
> | > thing that when my boss and i talk about 'refactoring' some code, we
> | > understand each other...which is the whole point of a word.
> | >
> |
> | Then how do you differ between "refactoring" and "rewriting"? There is
> | a difference!
>
> besides symantics, what is the superior definition and use of 'refactoring'.
> anytime you 'refactor' code, you 'rewrite' it. i'm fine, as an employer,
> when a developer says, 'i redid/willdo this to do/behave/help with this...it
> impacted (will impact) this/these things.' THAT is more meaningful than
> EITHER term. moreover, i just don't thing 'redid' and 'willdo' would have
> sounded very 'extreme' and hence was not included in the book(s). ;^)
>

Yes and no. Refactoring typically is more limited - for instance,
recoding a function, set of functions, class, etc., without having to
change code which calls those functions or class members.

> when discussing changes that need to be made in code with a client, i don't
> use either term. i talk about things he understands like speed, flexibility,
> longevity, scale, and costs (both long and short-term). when discussing
> changes with my boss, i talk about strategy and architecture. and with my
> employees, i talk about what i need done specific to all of the above...and
> if in the course of their changes, they see a pattern, potential problem, or
> oportunity that should be addressed, we get down to *specifics*...not lingo.
>

I do the same. I don't even talk about "rewriting" the code. I don't
even talk about architecture, and the only strategy is that which has to
be in place to get the job done. Rather, I talk about the benefits he
will receive from whatever I'm going to do.

> but that's just me. everything is a rewrite...or an origination. what
> benefit is it to anyone to split hairs over a term that is itself, already
> controvertial and unclear?
>

It's fun? :-) But you're right, it's not really worth splitting hairs over.

> don't get me wrong, jerry. i think saunders kaufman has his head squarely up
> his ass, which explains why he's 'in the dark' on this topic. however, i've
> done all the 'extreme' stuff including paired programming, bidding, etc.. as
> i've said, it comes from common practices in other fields all the way back
> to the early 1900's. ain't nothn' 'extreme' about it as far as programming
> is concerned. as for the lingo associated with it, may it forever be limited
> to the context of the book that espoused it. for me, i use specifics when i
> need someone else to understand what i'm doing or what they need to do.
> 'refactoring' is not specific enough.
>

I think Sanders is just being honest when he says he's in the dark about
it. I think most programmers are.

And I also agree there is no "extreme programming". There are "extreme
sports", which can only be done by someone in excellent physical
condition, lots of practice and a willingness to die. But virtually any
programming can be done by a competent programmer versed in the
language, tools, etc. to be used. It just takes some people longer than
others.

> if it works for someone else, i'm glad.
>

Yep.

> cheers.
>
>

Caio!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]