Best Coding Practice

First, let me say that this question is a rather general programming
question, but the context is PHP, so I figured this group would have
the most relevant insight.

Anyways, this is also more of an opinion based question than one
seeking a definite answer. Recently, while maintaining a rather large
system. I needed to add an array class member to an object. It was
exactly the same as another class member, except that one array stored
regular products, and the other stored free promotional products. As
such, I needed a way to add products to the new, free array. Since all
the logic was the same between the two arrays aside from the price, I
had a few different options to do this. I'm interested in polling
which way some of the group members feel would have been the best.
Naturally these are abbreviated versions of what I envisioned as
possible solutions.
#1.
public function addArrayA($object){
//logic
$a[] = $object;
}

public function addArrayB($object){
//same logic
$b[] = $object;
}


#2. (These next two are arranged as such, because the class using
these functions is included in many script files,
all of which I may not be aware of, so there would have to be some
default value for the array that was always used
before this new array was needed)
public function addArray($object, $free = NULL){
//logic
if(!$free){
$a[] = $object;
}else{
$b[] = $object;
}
}

or

#3
public function addArray($object, $arr = "a"){
//logic
$$arr[] = $object;
}



I ended up going with option number 1, because I felt that despite the
inefficient, redundant code it would later be more readable to other
programmers that might work on the project. Additionally, I didn't
feel wholly comfortable with default variables being the only
difference between a full price product and a free product. Thoughts?

Re: Best Coding Practice

burgermeister01@gmail.com wrote:
> First, let me say that this question is a rather general programming
> question, but the context is PHP, so I figured this group would have
> the most relevant insight.
>
> Anyways, this is also more of an opinion based question than one
> seeking a definite answer. Recently, while maintaining a rather large
> system. I needed to add an array class member to an object. It was
> exactly the same as another class member, except that one array stored
> regular products, and the other stored free promotional products. As
> such, I needed a way to add products to the new, free array. Since all
> the logic was the same between the two arrays aside from the price, I
> had a few different options to do this. I'm interested in polling
> which way some of the group members feel would have been the best.
> Naturally these are abbreviated versions of what I envisioned as
> possible solutions.
> #1.
> public function addArrayA($object){
> //logic
> $a[] = $object;
> }
>
> public function addArrayB($object){
> //same logic
> $b[] = $object;
> }
>
>
> #2. (These next two are arranged as such, because the class using
> these functions is included in many script files,
> all of which I may not be aware of, so there would have to be some
> default value for the array that was always used
> before this new array was needed)
> public function addArray($object, $free = NULL){
> //logic
> if(!$free){
> $a[] = $object;
> }else{
> $b[] = $object;
> }
> }
>
> or
>
> #3
> public function addArray($object, $arr = "a"){
> //logic
> $$arr[] = $object;
> }
>
>
>
> I ended up going with option number 1, because I felt that despite the
> inefficient, redundant code it would later be more readable to other
> programmers that might work on the project. Additionally, I didn't
> feel wholly comfortable with default variables being the only
> difference between a full price product and a free product. Thoughts?
>

I'd pick choice 1.

Generally I try not to change an existing function's signature unless
necessary. Also, it's more clear as to what it's doing, and there is
only one line of duplicated code (if there were a lot of lines, I'd have
a common function and pass $a or $b to that function).

You could make a case could be made for choice 2, but it adds
complication (and processing time for the if statements).

No way would I ever pick choice 3. It's unnecessarily complicated and
confusing. And what would happen if someone passed 'c' to it?

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

Re: Best Coding Practice

On Aug 23, 8:41 pm, "burgermeiste...@gmail.com"
wrote:
> First, let me say that this question is a rather general programming
> question, but the context is PHP, so I figured this group would have
> the most relevant insight.
>
> Anyways, this is also more of an opinion based question than one
> seeking a definite answer. Recently, while maintaining a rather large
> system. I needed to add an array class member to an object. It was
> exactly the same as another class member, except that one array stored
> regular products, and the other stored free promotional products. As
> such, I needed a way to add products to the new, free array. Since all
> the logic was the same between the two arrays aside from the price, I
> had a few different options to do this. I'm interested in polling
> which way some of the group members feel would have been the best.
> Naturally these are abbreviated versions of what I envisioned as
> possible solutions.
> #1.
> public function addArrayA($object){
> //logic
> $a[] = $object;
>
> }
>
> public function addArrayB($object){
> //same logic
> $b[] = $object;
>
> }

still have redundant logic, as you stated

>
> #2. (These next two are arranged as such, because the class using
> these functions is included in many script files,
> all of which I may not be aware of, so there would have to be some
> default value for the array that was always used
> before this new array was needed)
> public function addArray($object, $free = NULL){
> //logic
> if(!$free){
> $a[] = $object;
> }else{
> $b[] = $object;
> }
>
> }

not very good practice. when you start using conditional statements
within your code, it's a good canidate for refactoring. Seeing this
as a possibility, I probably would have created a abstract base
Products class, which it's child concrete classes would act as
containers for product items. The base class would contain all the
core functionality, and the child classes the specific elements.
Then, come time to add a new sibling class, it simply inherets from
the superclass and your good to go.

>
> or
>
> #3
> public function addArray($object, $arr = "a"){
> //logic
> $$arr[] = $object;
>
> }
>

I've actually done something similar to this before. Only 2 months
later I was cursing the programmer that came up with this
chaos....damn.

> I ended up going with option number 1, because I felt that despite the
> inefficient, redundant code it would later be more readable to other
> programmers that might work on the project. Additionally, I didn't
> feel wholly comfortable with default variables being the only
> difference between a full price product and a free product. Thoughts?

Re: Best Coding Practice

wrote in message
news:1187916107.291436.304670@q3g2000prf.googlegroups.com...
| First, let me say that this question is a rather general programming
| question, but the context is PHP, so I figured this group would have
| the most relevant insight.

since this is a general prog. q., let me answer with a formal approach...

i'd get more strict with the array. i'd make them into an object - a class.
i'd either have b extend a, or a and b extend another base/common object, or
have a and b implement a standard inter face. the array that you're holding
$object in should be strong-typed as the 1) base object or 2) the shared
interface. upon processing within your function, you'd simply get the class
type of the object and place it in its appropriate array.

but, that just may be to formal...especially since isp's seem reluctant/slow
in upgrading to more recent and oop compatible versions of php.

and, that could just be me.

cheers.

Re: Best Coding Practice

ELINTPimp wrote:
> On Aug 23, 8:41 pm, "burgermeiste...@gmail.com"

>> public function addArray($object, $free = NULL){
>> //logic
>> if(!$free){
>> $a[] = $object;
>> }else{
>> $b[] = $object;
>> }
>>
>> }
>
> not very good practice. when you start using conditional statements
> within your code, it's a good canidate for refactoring.

Refactoring?
What's that?

Re: Best Coding Practice

"Sanders Kaufman" wrote in message
news:CMrzi.11327$3x.7315@newssvr25.news.prodigy.net...
> ELINTPimp wrote:

>> not very good practice. when you start using conditional statements
>> within your code, it's a good canidate for refactoring.
>
> Refactoring?
> What's that?

http://www.google.com.au/search?q=refactoring

Second hit.

--
Richard.

Re: Best Coding Practice

rf wrote:
> "Sanders Kaufman" wrote in message

>> Refactoring?
>> What's that?
>
> http://www.google.com.au/search?q=refactoring

http://en.wikipedia.org/wiki/Refactoring

Oh, I get it. It's a politically-correct, bidness-safe way of saying
you did something fundamentally wrong and have to re-design the whole
damned thing. Oddly, my spell-checker sees "refactor" as not-a-word.

I'll have to remember that one - I don't rewrite my code, I
refactor(sp?) it.

I notice they cite Agile and Extreme (but not Waterfall) in that
definition. That's funny. Every time I've been involved in a shop that
prayed from one of those bibles, agony and failure were the
words-of-the-day... for just that reason.

They always come up with convoluted ways of stating the simplest things,
and the most complex ways of performing the simplest functions.

On second thought... maybe I'll just forget that one.

Thx rf

Re: Best Coding Practice

"Sanders Kaufman" wrote in message
news:nHszi.4651$LL7.2735@nlpi069.nbdc.sbc.com...
| rf wrote:
| > "Sanders Kaufman" wrote in message
|
| >> Refactoring?
| >> What's that?
| >
| > http://www.google.com.au/search?q=refactoring
|
| http://en.wikipedia.org/wiki/Refactoring
|
| Oh, I get it. It's a politically-correct, bidness-safe way of saying
| you did something fundamentally wrong and have to re-design the whole
| damned thing. Oddly, my spell-checker sees "refactor" as not-a-word.
|
| I'll have to remember that one - I don't rewrite my code, I
| refactor(sp?) it.
|
| I notice they cite Agile and Extreme (but not Waterfall) in that
| definition. That's funny. Every time I've been involved in a shop that
| prayed from one of those bibles, agony and failure were the
| words-of-the-day... for just that reason.
|
| They always come up with convoluted ways of stating the simplest things,
| and the most complex ways of performing the simplest functions.
|
| On second thought... maybe I'll just forget that one.

but don't you just love the 'automatic unit testing blah blah blah'. i've
written tests more complex that the code it was performed on. perhaps
'automatic' should be stricken from that def.

however, the 'fundamentally wrong' is not really wrong at all. the
functionality is not broken. it could be that a new enhancement needs to be
added. refactoring old code for the addition may just mean code isolation so
that pertinent portions can be used in multiple places yet maintained in
one. it may mean you hired a consultant to produce quick results that you
were understaffed to complete. *always* go behind your consultants!!! *most*
of the shittiest working code i've ever seen comes from that source. plus
they may just innocently enough, not know your standards and practices...so
you're bringing it back in line. it could be that when reviewing a code
base, patterns emerge that could be consolidated or reduced to a more simple
statement...all of these things are reasons to refactor.

btw, i hate 'extreme programming'. it employs decades old scientific
management models and pawns them off as new and exciting, even
revolutionary...dare i say 'extreme'...methodology not seen until modern
times. but, i digress...

cheers

Re: Best Coding Practice

"Sanders Kaufman" wrote in message
news:nHszi.4651$LL7.2735@nlpi069.nbdc.sbc.com...
> rf wrote:
>> "Sanders Kaufman" wrote in message
>
>>> Refactoring?
>>> What's that?
>>
>> http://www.google.com.au/search?q=refactoring
>
> http://en.wikipedia.org/wiki/Refactoring
>
> Oh, I get it. It's a politically-correct, bidness-safe way of saying you
> did something fundamentally wrong and have to re-design the whole damned
> thing.

No it is most definately not. If you had read and understood the above
article you would know that.

While you are looking again at the article you may wish to follow the link
to Extreme Programming, of which refactoring is an integral component.

This is not, of course, programming 101. It's many levels above that.

--
Richard.

Re: Best Coding Practice

> > Anyways, this is also more of an opinion based question than one
> > seeking a definite answer. Recently, while maintaining a rather large
> > system. I needed to add an array class member to an object. It was
> > exactly the same as another class member, except that one array stored
> > regular products, and the other stored free promotional products. As
> > such, I needed a way to add products to the new, free array. Since all
> > the logic was the same between the two arrays aside from the price, I
> > had a few different options to do this. I'm interested in polling
> > which way some of the group members feel would have been the best.
> > Naturally these are abbreviated versions of what I envisioned as
> > possible solutions.
> > #2. (These next two are arranged as such, because the class using
> > these functions is included in many script files,
> > all of which I may not be aware of, so there would have to be some
> > default value for the array that was always used
> > before this new array was needed)
> > public function addArray($object, $free = NULL){
> > //logic
> > if(!$free){
> > $a[] = $object;
> > }else{
> > $b[] = $object;
> > }
>
> > }
>
> not very good practice. when you start using conditional statements
> within your code, it's a good canidate for refactoring. Seeing this
> as a possibility, I probably would have created a abstract base
> Products class, which it's child concrete classes would act as
> containers for product items. The base class would contain all the
> core functionality, and the child classes the specific elements.
> Then, come time to add a new sibling class, it simply inherets from
> the superclass and your good to go.
>



Frankly, I can't believe that I didn't think of a more OO approach to
begin with. I've been working in a shop that went through a series of
really terrible programmers, and me, wanting to stick to convention
just for consistency's sake, it appears I have begun to lose some of
my 'good' habits. I will have to consult this group more frequently to
ensure that doesn't happen any further. In fact, this code is so fresh
I may still go back and rewrite it.

That being the case, I have some more specific inquires into the
group's and ElINT's opinion on OOP. It's possible I'm not fully
understanding the way you describe it, ELINT, so if I'm reiterating
what you've already said, I apologize in advance. The approach I might
take, is as follows:
My Product class which is a member of the Order class, of which I
mentioned in my OP, would be my parent class. My reasoning for this is
because the Product class is already used in so many other scripts, I
wouldn't feel entirely comfortable suddenly making it a child class of
some other super class. Additionally, the data used to instantiate the
Product class is being pulled from a separate database table (like an
active record) however, the free products essentially are the items
from the Product table, only with their price overridden to $0 (that
in itself may not make a lot of sense, but apparently, after
communicating with the client its the best way to interface with their
inventory system). Therefore, in my mind it would make sense from an
OO standpoint to make a FreeProduct class which extends the Product
class and simply overrides the price member, or the function that
returns it.
Further thoughts and opinions on this matter are welcome and
appreciated.

Re: Best Coding Practice

rf wrote:
> "Sanders Kaufman" wrote in message

>> Oh, I get it. It's a politically-correct, bidness-safe way of saying you
>> did something fundamentally wrong and have to re-design the whole damned
>> thing.
>
> No it is most definately not. If you had read and understood the above
> article you would know that.
>
> While you are looking again at the article you may wish to follow the link
> to Extreme Programming, of which refactoring is an integral component.
>
> This is not, of course, programming 101. It's many levels above that.

Yeah - so advanced that it leaves the programming world entirely, and
enters that of PC bidness-speak. Bleccchh.

I'm a code-monkey, and I like it.

Re: Best Coding Practice

burgermeister01@gmail.com wrote:

> I needed to add an array class member to an object. It was exactly the
> same as another class member, except that one array stored regular
> products, and the other stored free promotional products. As such, I
> needed a way to add products to the new, free array. Since all the logic
> was the same between the two arrays aside from the price, I had a few
> different options to do this.

Frankly I think all the options you outlined expose too much of the inner
workings of your class. What happens when you add a third category of
products (products that cost money, free products & products we have to
pay you to take away!)

A better solution would be something like this:

public function add_product (Product $p)
{
if ($p->price==0)
$this->free_products[] = $p;
else
$this->products[] = $p;
}

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.12-12mdksmp, up 64 days, 11:44.]

TrivialEncoder/0.2
http://tobyinkster.co.uk/blog/2007/08/19/trivial-encoder/

Re: Best Coding Practice

burgermeister01@gmail.com wrote:
>>> Anyways, this is also more of an opinion based question than one
>>> seeking a definite answer. Recently, while maintaining a rather large
>>> system. I needed to add an array class member to an object. It was
>>> exactly the same as another class member, except that one array stored
>>> regular products, and the other stored free promotional products. As
>>> such, I needed a way to add products to the new, free array. Since all
>>> the logic was the same between the two arrays aside from the price, I
>>> had a few different options to do this. I'm interested in polling
>>> which way some of the group members feel would have been the best.
>>> Naturally these are abbreviated versions of what I envisioned as
>>> possible solutions.
>>> #2. (These next two are arranged as such, because the class using
>>> these functions is included in many script files,
>>> all of which I may not be aware of, so there would have to be some
>>> default value for the array that was always used
>>> before this new array was needed)
>>> public function addArray($object, $free = NULL){
>>> //logic
>>> if(!$free){
>>> $a[] = $object;
>>> }else{
>>> $b[] = $object;
>>> }
>>> }
>> not very good practice. when you start using conditional statements
>> within your code, it's a good canidate for refactoring. Seeing this
>> as a possibility, I probably would have created a abstract base
>> Products class, which it's child concrete classes would act as
>> containers for product items. The base class would contain all the
>> core functionality, and the child classes the specific elements.
>> Then, come time to add a new sibling class, it simply inherets from
>> the superclass and your good to go.
>>
>
>
>
> Frankly, I can't believe that I didn't think of a more OO approach to
> begin with. I've been working in a shop that went through a series of
> really terrible programmers, and me, wanting to stick to convention
> just for consistency's sake, it appears I have begun to lose some of
> my 'good' habits. I will have to consult this group more frequently to
> ensure that doesn't happen any further. In fact, this code is so fresh
> I may still go back and rewrite it.
>
> That being the case, I have some more specific inquires into the
> group's and ElINT's opinion on OOP. It's possible I'm not fully
> understanding the way you describe it, ELINT, so if I'm reiterating
> what you've already said, I apologize in advance. The approach I might
> take, is as follows:
> My Product class which is a member of the Order class, of which I
> mentioned in my OP, would be my parent class. My reasoning for this is
> because the Product class is already used in so many other scripts, I
> wouldn't feel entirely comfortable suddenly making it a child class of
> some other super class. Additionally, the data used to instantiate the
> Product class is being pulled from a separate database table (like an
> active record) however, the free products essentially are the items
> from the Product table, only with their price overridden to $0 (that
> in itself may not make a lot of sense, but apparently, after
> communicating with the client its the best way to interface with their
> inventory system). Therefore, in my mind it would make sense from an
> OO standpoint to make a FreeProduct class which extends the Product
> class and simply overrides the price member, or the function that
> returns it.
> Further thoughts and opinions on this matter are welcome and
> appreciated.
>

Why would you have a FreeProduct class? All a FreeProduct is is a
Product with a cost of 0. Cost is an attribute, and different values
for attributes should not determine new products. Would you have a
ProductCostsNinetyNineCents class? Just set the cost to zero, instead
of overriding it.

Or is there something I'm missing?

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

Re: Best Coding Practice

On Aug 24, 12:59 am, Sanders Kaufman wrote:
> rf wrote:
> > "Sanders Kaufman" wrote in message
> >> Oh, I get it. It's a politically-correct, bidness-safe way of saying you
> >> did something fundamentally wrong and have to re-design the whole damned
> >> thing.
>
> > No it is most definately not. If you had read and understood the above
> > article you would know that.
>
> > While you are looking again at the article you may wish to follow the link
> > to Extreme Programming, of which refactoring is an integral component.
>
> > This is not, of course, programming 101. It's many levels above that.
>
> Yeah - so advanced that it leaves the programming world entirely, and
> enters that of PC bidness-speak. Bleccchh.
>
> I'm a code-monkey, and I like it.

Sanders, I respect where you are coming from as wanting to be a "code-
monkey" and remove yourself from the "PC bidness-speak", as I've been
that way (and continue to be that way to some extent). There is a big
difference, however, in adopting sound best practices in software
engineering and "running with the crowd", as it were, using terms we
all love to hate like Web 2.0 and the like.

Refactoring your code doesn't always mean you screwed up in the design
or within the actual logic of the code. Most of the time, it has to
deal with improving your code to meet new business requirements. A
good (and dramatic) example is if you started with a very small
project that used OO, but not an MVC or similar framework. Later,
your customer tells you that their business has expanded and their
presence on the Internet must grow accordingly and now the customer is
needing something that is well beyond the original specifications of
the web application you created. Then starts the refactoring
process. Refactoring could also deal not just with your business
logic, but also database schema and aspects therein.

I recommend to all that hasn't already read them, to check out books
by Martin Fowler as a starter into this subject.

The term "refactoring" can be considered a label, really, similar to
giving a design pattern a name. It gives technical people a common
language so they can work together. Just because your PHB may pickup
on the term, and use it (probably incorrectly), doesn't mean it's
garbage and does not relate to a software engineer.

Extreme programming uses the term refactoring, but even though it may
be in the index of the book, doesn't mean they are strictly related.

Re: Best Coding Practice

On Aug 24, 6:17 am, Jerry Stuckle wrote:
> burgermeiste...@gmail.com wrote:
> >>> Anyways, this is also more of an opinion based question than one
> >>> seeking a definite answer. Recently, while maintaining a rather large
> >>> system. I needed to add an array class member to an object. It was
> >>> exactly the same as another class member, except that one array stored
> >>> regular products, and the other stored free promotional products. As
> >>> such, I needed a way to add products to the new, free array. Since all
> >>> the logic was the same between the two arrays aside from the price, I
> >>> had a few different options to do this. I'm interested in polling
> >>> which way some of the group members feel would have been the best.
> >>> Naturally these are abbreviated versions of what I envisioned as
> >>> possible solutions.
> >>> #2. (These next two are arranged as such, because the class using
> >>> these functions is included in many script files,
> >>> all of which I may not be aware of, so there would have to be some
> >>> default value for the array that was always used
> >>> before this new array was needed)
> >>> public function addArray($object, $free = NULL){
> >>> //logic
> >>> if(!$free){
> >>> $a[] = $object;
> >>> }else{
> >>> $b[] = $object;
> >>> }
> >>> }
> >> not very good practice. when you start using conditional statements
> >> within your code, it's a good canidate for refactoring. Seeing this
> >> as a possibility, I probably would have created a abstract base
> >> Products class, which it's child concrete classes would act as
> >> containers for product items. The base class would contain all the
> >> core functionality, and the child classes the specific elements.
> >> Then, come time to add a new sibling class, it simply inherets from
> >> the superclass and your good to go.
>
> > Frankly, I can't believe that I didn't think of a more OO approach to
> > begin with. I've been working in a shop that went through a series of
> > really terrible programmers, and me, wanting to stick to convention
> > just for consistency's sake, it appears I have begun to lose some of
> > my 'good' habits. I will have to consult this group more frequently to
> > ensure that doesn't happen any further. In fact, this code is so fresh
> > I may still go back and rewrite it.
>
> > That being the case, I have some more specific inquires into the
> > group's and ElINT's opinion on OOP. It's possible I'm not fully
> > understanding the way you describe it, ELINT, so if I'm reiterating
> > what you've already said, I apologize in advance. The approach I might
> > take, is as follows:
> > My Product class which is a member of the Order class, of which I
> > mentioned in my OP, would be my parent class. My reasoning for this is
> > because the Product class is already used in so many other scripts, I
> > wouldn't feel entirely comfortable suddenly making it a child class of
> > some other super class. Additionally, the data used to instantiate the
> > Product class is being pulled from a separate database table (like an
> > active record) however, the free products essentially are the items
> > from the Product table, only with their price overridden to $0 (that
> > in itself may not make a lot of sense, but apparently, after
> > communicating with the client its the best way to interface with their
> > inventory system). Therefore, in my mind it would make sense from an
> > OO standpoint to make a FreeProduct class which extends the Product
> > class and simply overrides the price member, or the function that
> > returns it.
> > Further thoughts and opinions on this matter are welcome and
> > appreciated.
>
> Why would you have a FreeProduct class? All a FreeProduct is is a
> Product with a cost of 0. Cost is an attribute, and different values
> for attributes should not determine new products. Would you have a
> ProductCostsNinetyNineCents class? Just set the cost to zero, instead
> of overriding it.
>
> Or is there something I'm missing?
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================

Jerry,
Initially I was going to answer your post with a description about how
Product classes are active records and FreeProducts aren't *really*
active records. However, the more I thought about it, the more I
realized that that's in fact no justification for a child class in
this case. In fact, because of the way the Order class stores
products, i.e. basically $products['product_id_number'] = $quantity,
this would only add an extra layer of complexity and not really make
storing the products any easier. This leads me back to what you and I
originally concurred about being the better solution (or something
like it, such as passing in an array, as you suggested, or denoting
the appropriate array by product characteristics as per Toby).
To others this may not sound optimal, but this system is rather large,
and has become rather convoluted over time, and as such it's hard to
describe the different factors I need to account for; I really do
think that an OO approach would be overcomplicated in this case. I'm
sure that by this point I sound a bit like a crazy-man that can't make
up his mind, but I think for me this is been more of lesson in how
difficult it can be to keep code in your head over time and be able to
talk with others about it intelligently.

Re: Best Coding Practice

On Aug 24, 7:17 am, Jerry Stuckle wrote:
> burgermeiste...@gmail.com wrote:
> >>> Anyways, this is also more of an opinion based question than one
> >>> seeking a definite answer. Recently, while maintaining a rather large
> >>> system. I needed to add an array class member to an object. It was
> >>> exactly the same as another class member, except that one array stored
> >>> regular products, and the other stored free promotional products. As
> >>> such, I needed a way to add products to the new, free array. Since all
> >>> the logic was the same between the two arrays aside from the price, I
> >>> had a few different options to do this. I'm interested in polling
> >>> which way some of the group members feel would have been the best.
> >>> Naturally these are abbreviated versions of what I envisioned as
> >>> possible solutions.
> >>> #2. (These next two are arranged as such, because the class using
> >>> these functions is included in many script files,
> >>> all of which I may not be aware of, so there would have to be some
> >>> default value for the array that was always used
> >>> before this new array was needed)
> >>> public function addArray($object, $free = NULL){
> >>> //logic
> >>> if(!$free){
> >>> $a[] = $object;
> >>> }else{
> >>> $b[] = $object;
> >>> }
> >>> }
> >> not very good practice. when you start using conditional statements
> >> within your code, it's a good canidate for refactoring. Seeing this
> >> as a possibility, I probably would have created a abstract base
> >> Products class, which it's child concrete classes would act as
> >> containers for product items. The base class would contain all the
> >> core functionality, and the child classes the specific elements.
> >> Then, come time to add a new sibling class, it simply inherets from
> >> the superclass and your good to go.
>
> > Frankly, I can't believe that I didn't think of a more OO approach to
> > begin with. I've been working in a shop that went through a series of
> > really terrible programmers, and me, wanting to stick to convention
> > just for consistency's sake, it appears I have begun to lose some of
> > my 'good' habits. I will have to consult this group more frequently to
> > ensure that doesn't happen any further. In fact, this code is so fresh
> > I may still go back and rewrite it.
>
> > That being the case, I have some more specific inquires into the
> > group's and ElINT's opinion on OOP. It's possible I'm not fully
> > understanding the way you describe it, ELINT, so if I'm reiterating
> > what you've already said, I apologize in advance. The approach I might
> > take, is as follows:
> > My Product class which is a member of the Order class, of which I
> > mentioned in my OP, would be my parent class. My reasoning for this is
> > because the Product class is already used in so many other scripts, I
> > wouldn't feel entirely comfortable suddenly making it a child class of
> > some other super class. Additionally, the data used to instantiate the
> > Product class is being pulled from a separate database table (like an
> > active record) however, the free products essentially are the items
> > from the Product table, only with their price overridden to $0 (that
> > in itself may not make a lot of sense, but apparently, after
> > communicating with the client its the best way to interface with their
> > inventory system). Therefore, in my mind it would make sense from an
> > OO standpoint to make a FreeProduct class which extends the Product
> > class and simply overrides the price member, or the function that
> > returns it.
> > Further thoughts and opinions on this matter are welcome and
> > appreciated.
>
> Why would you have a FreeProduct class? All a FreeProduct is is a
> Product with a cost of 0. Cost is an attribute, and different values
> for attributes should not determine new products. Would you have a
> ProductCostsNinetyNineCents class? Just set the cost to zero, instead
> of overriding it.
>
> Or is there something I'm missing?
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================

Actually, Jerry makes a good point. I guess I was just looking at
what you were doing rather than really analyzing WHAT you were trying
to accomplish.

IF this is all your trying to accomplish (discounting or rendering a
product "free"), a separate class would be incorrect. Thanks for
pointing that out, Jerry.

I think we need to step back and look at what you are doing a bit.
You have a Products class that is a child of the order class. Not
sure of the reasoning behind that from what you wrote, but I'll roll
with it. Your products class currently have two arrays, one for
standard products and one for free products. Why do these need to be
broken out into two arrays? I wonder about the db schema on how a
product is identified as "free". Is there a bit flag or something of
the sort, or maybe a discount column in percentage where 100% ==
free? Possibly something like this:

class product { //
private $_product_id;
private $_price;
private $_discount = 0;
private $_free_flag = false;
private $_quantity;
...

static public function getProduct($product_id) {
//returns the product by product ID, called from the PRODUCTS
class
//this can ensure you only have the product listed once in your
array.
//if it already exists, just adjust the quantity
}

public function isFree() {
//checks to see if the product is free
if ($this->_free_flag === true || $this->_discount == 100) {
return true;
}
return false;
}
} // end product class

class products {
$_products = array();

public function getFreeItems() {
//go through the array checking if the item is free
return $freeItems;
}

} // end products class

Re: Best Coding Practice

On Aug 24, 10:20 am, "burgermeiste...@gmail.com"
wrote:
> On Aug 24, 6:17 am, Jerry Stuckle wrote:
>
>
>
> > burgermeiste...@gmail.com wrote:
> > >>> Anyways, this is also more of an opinion based question than one
> > >>> seeking a definite answer. Recently, while maintaining a rather large
> > >>> system. I needed to add an array class member to an object. It was
> > >>> exactly the same as another class member, except that one array stored
> > >>> regular products, and the other stored free promotional products. As
> > >>> such, I needed a way to add products to the new, free array. Since all
> > >>> the logic was the same between the two arrays aside from the price, I
> > >>> had a few different options to do this. I'm interested in polling
> > >>> which way some of the group members feel would have been the best.
> > >>> Naturally these are abbreviated versions of what I envisioned as
> > >>> possible solutions.
> > >>> #2. (These next two are arranged as such, because the class using
> > >>> these functions is included in many script files,
> > >>> all of which I may not be aware of, so there would have to be some
> > >>> default value for the array that was always used
> > >>> before this new array was needed)
> > >>> public function addArray($object, $free = NULL){
> > >>> //logic
> > >>> if(!$free){
> > >>> $a[] = $object;
> > >>> }else{
> > >>> $b[] = $object;
> > >>> }
> > >>> }
> > >> not very good practice. when you start using conditional statements
> > >> within your code, it's a good canidate for refactoring. Seeing this
> > >> as a possibility, I probably would have created a abstract base
> > >> Products class, which it's child concrete classes would act as
> > >> containers for product items. The base class would contain all the
> > >> core functionality, and the child classes the specific elements.
> > >> Then, come time to add a new sibling class, it simply inherets from
> > >> the superclass and your good to go.
>
> > > Frankly, I can't believe that I didn't think of a more OO approach to
> > > begin with. I've been working in a shop that went through a series of
> > > really terrible programmers, and me, wanting to stick to convention
> > > just for consistency's sake, it appears I have begun to lose some of
> > > my 'good' habits. I will have to consult this group more frequently to
> > > ensure that doesn't happen any further. In fact, this code is so fresh
> > > I may still go back and rewrite it.
>
> > > That being the case, I have some more specific inquires into the
> > > group's and ElINT's opinion on OOP. It's possible I'm not fully
> > > understanding the way you describe it, ELINT, so if I'm reiterating
> > > what you've already said, I apologize in advance. The approach I might
> > > take, is as follows:
> > > My Product class which is a member of the Order class, of which I
> > > mentioned in my OP, would be my parent class. My reasoning for this is
> > > because the Product class is already used in so many other scripts, I
> > > wouldn't feel entirely comfortable suddenly making it a child class of
> > > some other super class. Additionally, the data used to instantiate the
> > > Product class is being pulled from a separate database table (like an
> > > active record) however, the free products essentially are the items
> > > from the Product table, only with their price overridden to $0 (that
> > > in itself may not make a lot of sense, but apparently, after
> > > communicating with the client its the best way to interface with their
> > > inventory system). Therefore, in my mind it would make sense from an
> > > OO standpoint to make a FreeProduct class which extends the Product
> > > class and simply overrides the price member, or the function that
> > > returns it.
> > > Further thoughts and opinions on this matter are welcome and
> > > appreciated.
>
> > Why would you have a FreeProduct class? All a FreeProduct is is a
> > Product with a cost of 0. Cost is an attribute, and different values
> > for attributes should not determine new products. Would you have a
> > ProductCostsNinetyNineCents class? Just set the cost to zero, instead
> > of overriding it.
>
> > Or is there something I'm missing?
>
> > --
> > ==================
> > Remove the "x" from my email address
> > Jerry Stuckle
> > JDS Computer Training Corp.
> > jstuck...@attglobal.net
> > ==================
>
> Jerry,
> Initially I was going to answer your post with a description about how
> Product classes are active records and FreeProducts aren't *really*
> active records. However, the more I thought about it, the more I
> realized that that's in fact no justification for a child class in
> this case. In fact, because of the way the Order class stores
> products, i.e. basically $products['product_id_number'] = $quantity,
> this would only add an extra layer of complexity and not really make
> storing the products any easier. This leads me back to what you and I
> originally concurred about being the better solution (or something
> like it, such as passing in an array, as you suggested, or denoting
> the appropriate array by product characteristics as per Toby).
> To others this may not sound optimal, but this system is rather large,
> and has become rather convoluted over time, and as such it's hard to
> describe the different factors I need to account for; I really do
> think that an OO approach would be overcomplicated in this case. I'm
> sure that by this point I sound a bit like a crazy-man that can't make
> up his mind, but I think for me this is been more of lesson in how
> difficult it can be to keep code in your head over time and be able to
> talk with others about it intelligently.

Agreed, please see my post above. I'll be sure to focus on the
problem rather than the approach of the person in the future. Thanks
for pointing this out, Jerry.

Re: Best Coding Practice

| That being the case, I have some more specific inquires into the
| group's and ElINT's opinion on OOP. It's possible I'm not fully
| understanding the way you describe it, ELINT, so if I'm reiterating
| what you've already said, I apologize in advance. The approach I might
| take, is as follows:
| My Product class which is a member of the Order class, of which I
| mentioned in my OP, would be my parent class. My reasoning for this is
| because the Product class is already used in so many other scripts, I
| wouldn't feel entirely comfortable suddenly making it a child class of
| some other super class.

i *completely* disagree...you are not programming for your *comfort*. you
program to get it correctly. you should have an *item* class implemented by
product which will further be extended and used by the free product class.
additionally - and the main reason you should *not* make the base class
'order' - your company could begin selling *services* and as far as billing
goes, would be so similar in structure as 'product', you'd want to reuse the
base that way. finally, since an 'order' consists of line 'items', you can
use the 'item' interface to process the order (shipping, billing, inventory,
etc.) without having to look at any other specific differences between the
inheritors (product, free product, service).

again, do it right so the code base is *sound*...don't avoid doing something
because it is *uncomfortable*. the only reason to keep from refactoring
completely is because of costs.

but that's just my 0.02 usd

Re: Best Coding Practice

| Initially I was going to answer your post with a description about how
| Product classes are active records and FreeProducts aren't *really*
| active records. However, the more I thought about it, the more I
| realized that that's in fact no justification for a child class in
| this case. In fact, because of the way the Order class stores
| products, i.e. basically $products['product_id_number'] = $quantity,
| this would only add an extra layer of complexity and not really make
| storing the products any easier. This leads me back to what you and I
| originally concurred about being the better solution (or something
| like it, such as passing in an array, as you suggested, or denoting
| the appropriate array by product characteristics as per Toby).
| To others this may not sound optimal, but this system is rather large,
| and has become rather convoluted over time, and as such it's hard to
| describe the different factors I need to account for; I really do
| think that an OO approach would be overcomplicated in this case.

stop right there! statements like that are said by people that DON'T
understand OOP. they say it so frequently that all but seasoned developers
believe there is truth to it. that propogates MORE people give birth to
millions of lines of shitty code because they shy away from OOP and what it
REALLY offers.

it should be BECAUSE your system is becoming convoluted that you should use
OOP!!! otherwise, you'll end up with a monolith that will eventually topple.

Re: Best Coding Practice

| Agreed, please see my post above. I'll be sure to focus on the
| problem rather than the approach of the person in the future. Thanks
| for pointing this out, Jerry.

you always have to consider BOTH. that 'person in the future' is probably
going to be you. either way, it is the structure and pattern of what you
code that makes a project manageable and expandable. just looking at the
current problem is amatuer practice at best. that's called putting out fires
and is too short-sighted to do anyone much good.

Re: Best Coding Practice

"Toby A Inkster" wrote in message
news:18g2q4-6po.ln1@ophelia.g5n.co.uk...
| burgermeister01@gmail.com wrote:
|
| > I needed to add an array class member to an object. It was exactly the
| > same as another class member, except that one array stored regular
| > products, and the other stored free promotional products. As such, I
| > needed a way to add products to the new, free array. Since all the logic
| > was the same between the two arrays aside from the price, I had a few
| > different options to do this.
|
| Frankly I think all the options you outlined expose too much of the inner
| workings of your class. What happens when you add a third category of
| products (products that cost money, free products & products we have to
| pay you to take away!)
|
| A better solution would be something like this:
|
| public function add_product (Product $p)
| {
| if ($p->price==0)
| $this->free_products[] = $p;
| else
| $this->products[] = $p;
| }

well, add_product shouldn't care about anything specific to $p outside of
it's price, availability, quantity, etc. since both 'free' and 'not-free'
product have them, add_product should look more like:

public function add_product(IProduct $p)
{
$this->productions[] = $p;
}

where IProduct is an interface having all of those shared attributes. if
add_product is the interface of an 'order' object, it should look more like:

public function add_product(IItem $item)
{
$this->items[] = $item;
}

where IItem is an interface implemented in a base 'product' class and a base
'service' class...a free product or service simply extends their base class.
the WHOLE time, the 'order' object couldn't care less. it just cares about
price, availability, quantity, etc.. ain't loose-coupling great!

;^)

Re: Best Coding Practice

On Aug 24, 2:43 pm, "Steve" wrote:
> | That being the case, I have some more specific inquires into the
> | group's and ElINT's opinion on OOP. It's possible I'm not fully
> | understanding the way you describe it, ELINT, so if I'm reiterating
> | what you've already said, I apologize in advance. The approach I might
> | take, is as follows:
> | My Product class which is a member of the Order class, of which I
> | mentioned in my OP, would be my parent class. My reasoning for this is
> | because the Product class is already used in so many other scripts, I
> | wouldn't feel entirely comfortable suddenly making it a child class of
> | some other super class.
>
> i *completely* disagree...you are not programming for your *comfort*. you
> program to get it correctly. you should have an *item* class implemented by
> product which will further be extended and used by the free product class.
> additionally - and the main reason you should *not* make the base class
> 'order' - your company could begin selling *services* and as far as billing
> goes, would be so similar in structure as 'product', you'd want to reuse the
> base that way. finally, since an 'order' consists of line 'items', you can
> use the 'item' interface to process the order (shipping, billing, inventory,
> etc.) without having to look at any other specific differences between the
> inheritors (product, free product, service).
>
> again, do it right so the code base is *sound*...don't avoid doing something
> because it is *uncomfortable*. the only reason to keep from refactoring
> completely is because of costs.
>
> but that's just my 0.02 usd

I think after analyzing his actual situation rather than what he was
actually trying to do in the first place, Jerry is on the right
track. For this particular situation, creating a superclass and
concrete child classes isn't necessary and would, in my opinion never
really be needed. His product class holds individual products
(despite the name, which makes it seem like it should be a parent
class for concrete product type classes).

I don't think anybody was saying OOP was a bad solution in this
situation, since they were still talking about using a array within an
class. If he uses the product class as an object-wrapper around the
array, it will would nicely (which is what I was getting at in my
pseudo-code.

The solution that both you and I offered up prior to Jerry re-
emphasizing the problem is a sound way to program, keeping your code
clean and ready for polymorphism. Only problem is that our solution
wasn't relevant to this situation. =)

Re: Best Coding Practice

"ELINTPimp" wrote in message
news:1187982123.581945.190800@q4g2000prc.googlegroups.com...
| On Aug 24, 2:43 pm, "Steve" wrote:
| > | That being the case, I have some more specific inquires into the
| > | group's and ElINT's opinion on OOP. It's possible I'm not fully
| > | understanding the way you describe it, ELINT, so if I'm reiterating
| > | what you've already said, I apologize in advance. The approach I might
| > | take, is as follows:
| > | My Product class which is a member of the Order class, of which I
| > | mentioned in my OP, would be my parent class. My reasoning for this is
| > | because the Product class is already used in so many other scripts, I
| > | wouldn't feel entirely comfortable suddenly making it a child class of
| > | some other super class.
| >
| > i *completely* disagree...you are not programming for your *comfort*.
you
| > program to get it correctly. you should have an *item* class implemented
by
| > product which will further be extended and used by the free product
class.
| > additionally - and the main reason you should *not* make the base class
| > 'order' - your company could begin selling *services* and as far as
billing
| > goes, would be so similar in structure as 'product', you'd want to reuse
the
| > base that way. finally, since an 'order' consists of line 'items', you
can
| > use the 'item' interface to process the order (shipping, billing,
inventory,
| > etc.) without having to look at any other specific differences between
the
| > inheritors (product, free product, service).
| >
| > again, do it right so the code base is *sound*...don't avoid doing
something
| > because it is *uncomfortable*. the only reason to keep from refactoring
| > completely is because of costs.
| >
| > but that's just my 0.02 usd
|
| I think after analyzing his actual situation rather than what he was
| actually trying to do in the first place, Jerry is on the right
| track. For this particular situation, creating a superclass and
| concrete child classes isn't necessary and would, in my opinion never
| really be needed. His product class holds individual products
| (despite the name, which makes it seem like it should be a parent
| class for concrete product type classes).
|
| I don't think anybody was saying OOP was a bad solution in this
| situation, since they were still talking about using a array within an
| class. If he uses the product class as an object-wrapper around the
| array, it will would nicely (which is what I was getting at in my
| pseudo-code.
|
| The solution that both you and I offered up prior to Jerry re-
| emphasizing the problem is a sound way to program, keeping your code
| clean and ready for polymorphism. Only problem is that our solution
| wasn't relevant to this situation. =)

agreed. however (in the spirit of 'general programming' the op pondered), if
it is to be completely accurate as to the quoted text to which i responded
then, product is not a function of order (which is made up of items).
product should inherit an IItem interface and any other extesions to it,
like 'free product' should come from the product base class. an IItem should
also be implemented other order item types like service...any extentions
from that should also come from it, like 'free service' are from that. there
are other item types as well such as discounts, non-itemized taxes, etc..
these are all 'items' that can appear on an 'order'. so, extending products
using order as a base class is ass-backward and soon, you'd be refactoring
things to match exactly the structure i described.

btw, burgermeister was the above quoted that talked about complexity
decreases desire to oop. you, jerry, and i are 'comfortable'...i was trying
to pursuade burger to change his mind.

;^)

Re: Best Coding Practice

On Aug 24, 3:20 pm, "Steve" wrote:
> "ELINTPimp" wrote in message
>
> news:1187982123.581945.190800@q4g2000prc.googlegroups.com...
> | On Aug 24, 2:43 pm, "Steve" wrote:
> | > | That being the case, I have some more specific inquires into the
> | > | group's and ElINT's opinion on OOP. It's possible I'm not fully
> | > | understanding the way you describe it, ELINT, so if I'm reiterating
> | > | what you've already said, I apologize in advance. The approach I might
> | > | take, is as follows:
> | > | My Product class which is a member of the Order class, of which I
> | > | mentioned in my OP, would be my parent class. My reasoning for this is
> | > | because the Product class is already used in so many other scripts, I
> | > | wouldn't feel entirely comfortable suddenly making it a child class of
> | > | some other super class.
> | >
> | > i *completely* disagree...you are not programming for your *comfort*.
> you
> | > program to get it correctly. you should have an *item* class implemented
> by
> | > product which will further be extended and used by the free product
> class.
> | > additionally - and the main reason you should *not* make the base class
> | > 'order' - your company could begin selling *services* and as far as
> billing
> | > goes, would be so similar in structure as 'product', you'd want to reuse
> the
> | > base that way. finally, since an 'order' consists of line 'items', you
> can
> | > use the 'item' interface to process the order (shipping, billing,
> inventory,
> | > etc.) without having to look at any other specific differences between
> the
> | > inheritors (product, free product, service).
> | >
> | > again, do it right so the code base is *sound*...don't avoid doing
> something
> | > because it is *uncomfortable*. the only reason to keep from refactoring
> | > completely is because of costs.
> | >
> | > but that's just my 0.02 usd
> |
> | I think after analyzing his actual situation rather than what he was
> | actually trying to do in the first place, Jerry is on the right
> | track. For this particular situation, creating a superclass and
> | concrete child classes isn't necessary and would, in my opinion never
> | really be needed. His product class holds individual products
> | (despite the name, which makes it seem like it should be a parent
> | class for concrete product type classes).
> |
> | I don't think anybody was saying OOP was a bad solution in this
> | situation, since they were still talking about using a array within an
> | class. If he uses the product class as an object-wrapper around the
> | array, it will would nicely (which is what I was getting at in my
> | pseudo-code.
> |
> | The solution that both you and I offered up prior to Jerry re-
> | emphasizing the problem is a sound way to program, keeping your code
> | clean and ready for polymorphism. Only problem is that our solution
> | wasn't relevant to this situation. =)
>
> agreed. however (in the spirit of 'general programming' the op pondered), if
> it is to be completely accurate as to the quoted text to which i responded
> then, product is not a function of order (which is made up of items).
> product should inherit an IItem interface and any other extesions to it,
> like 'free product' should come from the product base class. an IItem should
> also be implemented other order item types like service...any extentions
> from that should also come from it, like 'free service' are from that. there
> are other item types as well such as discounts, non-itemized taxes, etc..
> these are all 'items' that can appear on an 'order'. so, extending products
> using order as a base class is ass-backward and soon, you'd be refactoring
> things to match exactly the structure i described.
>
> btw, burgermeister was the above quoted that talked about complexity
> decreases desire to oop. you, jerry, and i are 'comfortable'...i was trying
> to pursuade burger to change his mind.
>
> ;^)

For the record, I think my second post has been terrible
misinterpreted. Product is not an extension of orders, orders contains
products in an array.

And Steve, I'm by no means saying you're wrong in claiming that OOP
would truly be the BEST, way to go. If it were up to me, I would be
doing exactly what you're saying. However, I came into this project
four months ago, after it's been under constant development with
continuous scope creep for the last 3-4 years. And the programmers
before me, as far as I can tell, don't understand OOP nearly as well
as I do, and that offsets them either further from you, because I can
concede that you probably do know more about OOP than I do. In any
case, the code is already at the point where it needs to be
'refactored', and I've told my boss this in different terms on a
number of occasions. However, the company is small enough that we
simply don't have the resources to do that, and the client isn't going
to be willing to pay for the man hours to essentially make their code
cleaner. All they care about is that it works. I know, I know...it's
the wrong way to look at things, and I've made my best efforts to
persuade others of that, but it's unfortunately vain efforts.

As for the specific circumstance we were addressing in the first
place, I'm not trying to say that I don't want to use OOP simply
because I think it's going to make things more complex for me, or
something like that; I don't want to use it because I don't think it's
going to add anything to make any feasible solution any better. I
would still need two arrays to distinguish products because the
database is structured so poorly, and redundantly, which I probably
should have made more clear in the first place, but I really feel that
this conversation is leaving the context of the original question I
was trying to have answered. And I understand your desire to promote
OOP as the 'right' solution, because usually it is; I love objects and
polymorphism. I just don't think it's going to help in these specific
circumstances.

Re: Best Coding Practice

| For the record, I think my second post has been terrible
| misinterpreted. Product is not an extension of orders, orders contains
| products in an array.

no, i got that.

| And Steve, I'm by no means saying you're wrong in claiming that OOP
| would truly be the BEST, way to go. If it were up to me, I would be
| doing exactly what you're saying. However, I came into this project
| four months ago, after it's been under constant development with
| continuous scope creep for the last 3-4 years. And the programmers
| before me, as far as I can tell, don't understand OOP nearly as well
| as I do, and that offsets them either further from you, because I can
| concede that you probably do know more about OOP than I do.

then you'd be giving me more credit than i'm due. ;^)

listen, i know about dead-lines and costs and don't even get me started on
scope-creep. i've been consulting on a project that i originally estimated
and priced as a three month project. now it's two years later...at least
they keep my extra income level high.

| All they care about is that it works. I know, I know...it's
| the wrong way to look at things, and I've made my best efforts to
| persuade others of that, but it's unfortunately vain efforts.

yeah, that's usually the way it goes. plus, the more times you try to help
open their eyes to potential problems they will most assuredly pay for down
the road, the more the see you as one who complains a lot...nothing more.

| As for the specific circumstance we were addressing in the first
| place, I'm not trying to say that I don't want to use OOP simply
| because I think it's going to make things more complex for me, or
| something like that; I don't want to use it because I don't think it's
| going to add anything to make any feasible solution any better.

it works out that way sometimes too. that would be oop-creep when a more
simple solution lies at the fingertips of a few well written lines of code,
but is otherwise written to match oop. it is key to recognize this, which
you have it seems. when you sit down to write or rework code, that's the
question (of many) i ask myself. what's the best way to express a solution
that is stable, maintainable, and will last over the long run? (oh, and it
has to work, not cost much, and be done yesturday)

| I would still need two arrays to distinguish products

well, no, you wouldn't. using oop, you can tell the object type of $product.
if 'free' extends the product class, then you can tell by its
type...'freeProduct' (or whatever). you can then branch your 'order' logic
based on that if you need to do something special with 'free'.

| because the
| database is structured so poorly, and redundantly, which I probably
| should have made more clear in the first place, but I really feel that
| this conversation is leaving the context of the original question I
| was trying to have answered.

well again, if you oop things, you can isolate one area of code to
consolidate the interactions with the db: one set of code to manage it, one
set of code to maintain it. that way, further development is kept clean and
not tied to poorly/redundantly designed db structures. if not contained this
way, you'll see the code become even more convoluted that the db and people
will copy and paste the already shitty code into new sections where it will
be modified slightly for whatever purpose need...propgating one nasty end
product.

hey, didn't mean to seem like i was getting on to you or anything like that.
i guess i was just preaching to the choir. ;^)

cheers

Re: Best Coding Practice

On Aug 24, 4:44 pm, "Steve" wrote:
> | For the record, I think my second post has been terrible
> | misinterpreted. Product is not an extension of orders, orders contains
> | products in an array.
>
> no, i got that.
>
> | And Steve, I'm by no means saying you're wrong in claiming that OOP
> | would truly be the BEST, way to go. If it were up to me, I would be
> | doing exactly what you're saying. However, I came into this project
> | four months ago, after it's been under constant development with
> | continuous scope creep for the last 3-4 years. And the programmers
> | before me, as far as I can tell, don't understand OOP nearly as well
> | as I do, and that offsets them either further from you, because I can
> | concede that you probably do know more about OOP than I do.
>
> then you'd be giving me more credit than i'm due. ;^)
>
> listen, i know about dead-lines and costs and don't even get me started on
> scope-creep. i've been consulting on a project that i originally estimated
> and priced as a three month project. now it's two years later...at least
> they keep my extra income level high.
>
> | All they care about is that it works. I know, I know...it's
> | the wrong way to look at things, and I've made my best efforts to
> | persuade others of that, but it's unfortunately vain efforts.
>
> yeah, that's usually the way it goes. plus, the more times you try to help
> open their eyes to potential problems they will most assuredly pay for down
> the road, the more the see you as one who complains a lot...nothing more.
>
> | As for the specific circumstance we were addressing in the first
> | place, I'm not trying to say that I don't want to use OOP simply
> | because I think it's going to make things more complex for me, or
> | something like that; I don't want to use it because I don't think it's
> | going to add anything to make any feasible solution any better.
>
> it works out that way sometimes too. that would be oop-creep when a more
> simple solution lies at the fingertips of a few well written lines of code,
> but is otherwise written to match oop. it is key to recognize this, which
> you have it seems. when you sit down to write or rework code, that's the
> question (of many) i ask myself. what's the best way to express a solution
> that is stable, maintainable, and will last over the long run? (oh, and it
> has to work, not cost much, and be done yesturday)
>
> | I would still need two arrays to distinguish products
>
> well, no, you wouldn't. using oop, you can tell the object type of $product.
> if 'free' extends the product class, then you can tell by its
> type...'freeProduct' (or whatever). you can then branch your 'order' logic
> based on that if you need to do something special with 'free'.
>
> | because the
> | database is structured so poorly, and redundantly, which I probably
> | should have made more clear in the first place, but I really feel that
> | this conversation is leaving the context of the original question I
> | was trying to have answered.
>
> well again, if you oop things, you can isolate one area of code to
> consolidate the interactions with the db: one set of code to manage it, one
> set of code to maintain it. that way, further development is kept clean and
> not tied to poorly/redundantly designed db structures. if not contained this
> way, you'll see the code become even more convoluted that the db and people
> will copy and paste the already shitty code into new sections where it will
> be modified slightly for whatever purpose need...propgating one nasty end
> product.
>
> hey, didn't mean to seem like i was getting on to you or anything like that.
> i guess i was just preaching to the choir. ;^)
>
> cheers

To Steve: I did feel a bit attacked by your previous posts, but just
as your intention wasn't to offend, my real intention wasn't to defend
myself either, so much as to make the circumstances clear for the sake
of conversation. I don't want this thread to be about me so much as my
circumstances, in case someone else that reads this is in the same
place.

With that said, I intend to double post, because I feel there is
really two issues going on here. In my OP what I was really trying to
figure out is which is better: clarity through redundancy, or
efficiency, with the added question of which efficient method would be
the least likely to cause further problems down the road. It seems
that earlier we had some concurrence that the former would be the
better choice. I'm still welcome to further comments regarding that
matter.

The second part of this question, is how could this whole situation be
fixed with an OO approach. As I think the rest of this thread has
established my specifics are fairly complicated and require much more
thorough details. It's going to take my awhile to write it all out, so
I'm going to get a lot more specific in a later post. Of all the time
I've been programming the people I've met and talked to about OOP that
really knew what they were talking about have been far and few
between, so I'm really interested in learning more about what other
would consider to be good OOP.

More details later tonight or tomorrow.

Re: Best Coding Practice

ELINTPimp wrote:

>
> Refactoring your code doesn't always mean you screwed up in the design
> or within the actual logic of the code. Most of the time, it has to
> deal with improving your code to meet new business requirements.

I understand all that... and how "refactor" doesn't necessarily mean
that everything's a mess.

In fact, I just "refactored" some code in which I was passing CSV
strings, but needed to change that to an array.

But I just told my payer that I did something fundamentally wrong, and
had to fix it before I went on. Had I said I need to "refactor" my code
, it wouldn't have been clear to her what happened. Worse, I think it
would have scared her into thinking that I was another one of many
coders she's hired before who bend over backwards to avoid admitting
that they made a mistake... while charging her for it.

I realize that in some circles, that kind of biz-speak is acceptable -
but those aren't my circles.

Re: Best Coding Practice

Sanders Kaufman wrote:
> ELINTPimp wrote:
>
>>
>> Refactoring your code doesn't always mean you screwed up in the design
>> or within the actual logic of the code. Most of the time, it has to
>> deal with improving your code to meet new business requirements.
>
> I understand all that... and how "refactor" doesn't necessarily mean
> that everything's a mess.
>
> In fact, I just "refactored" some code in which I was passing CSV
> strings, but needed to change that to an array.
>
> But I just told my payer that I did something fundamentally wrong, and
> had to fix it before I went on. Had I said I need to "refactor" my code
> , it wouldn't have been clear to her what happened. Worse, I think it
> would have scared her into thinking that I was another one of many
> coders she's hired before who bend over backwards to avoid admitting
> that they made a mistake... while charging her for it.
>
> I realize that in some circles, that kind of biz-speak is acceptable -
> but those aren't my circles.
>

But that's not refactoring. You changed the interface. Refactoring
does not change the interface - just the internal workings.

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

Re: Best Coding Practice

Jerry Stuckle wrote:

> But that's not refactoring. You changed the interface. Refactoring
> does not change the interface - just the internal workings.


What happened was that I had that Database->Baseclass->Implementation
structure going on, but I oopsed and put some features in the baseclass
that belonged in the database class.

Since the whole project relied on that wrong way of doing things, I had
to go to every page that extended the baseclass and modify it to reflect
the array way instead of the csv way.

That's refactoring, right?

btw - I just finished fixing up a working implementation and it's at
"http://www.kaufman.net/bvckvs/bvckvs_publication.php".

Except for a lot of cosmetology to do, I think it's what I wanted.

Re: Best Coding Practice

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>
>> But that's not refactoring. You changed the interface. Refactoring
>> does not change the interface - just the internal workings.
>
>
> What happened was that I had that Database->Baseclass->Implementation
> structure going on, but I oopsed and put some features in the baseclass
> that belonged in the database class.
>
> Since the whole project relied on that wrong way of doing things, I had
> to go to every page that extended the baseclass and modify it to reflect
> the array way instead of the csv way.
>
> That's refactoring, right?
>
> btw - I just finished fixing up a working implementation and it's at
> "http://www.kaufman.net/bvckvs/bvckvs_publication.php".
>
> Except for a lot of cosmetology to do, I think it's what I wanted.

No, refactoring is changing the implementation without changing the
interface.

IOW, you change HOW you do things, but not WHAT you do. You changed the
interface.

An example of refactoring would be to change a class so that it gets its
data from a relational database instead of a flat file. The function
calls (interface) remain the same, but the code in the functions
(implementation) changes.

Refactoring in OO would mean you would not have to change anything
outside of the class itself.

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

Re: Best Coding Practice

Jerry Stuckle wrote:

> No, refactoring is changing the implementation without changing the
> interface.
>
> IOW, you change HOW you do things, but not WHAT you do. You changed the
> interface.
>
> An example of refactoring would be to change a class so that it gets its
> data from a relational database instead of a flat file. The function
> calls (interface) remain the same, but the code in the functions
> (implementation) changes.
>
> Refactoring in OO would mean you would not have to change anything
> outside of the class itself.

Ahh - so when I had to use new kinds of parameters - I was rewriting.
But if I'd made it all zero-impact on how it's used, it would have been
refactoring.

I don't get it. I can repeat it and rephrase it. But I don't get it.

Re: Best Coding Practice

"Sanders Kaufman" wrote in message
news:whNzi.24$FO2.2@newssvr14.news.prodigy.net...
> Jerry Stuckle wrote:
>
>> No, refactoring is changing the implementation without changing the
>> interface.
>>
>> IOW, you change HOW you do things, but not WHAT you do. You changed the
>> interface.
>>
>> An example of refactoring would be to change a class so that it gets its
>> data from a relational database instead of a flat file. The function
>> calls (interface) remain the same, but the code in the functions
>> (implementation) changes.
>>
>> Refactoring in OO would mean you would not have to change anything
>> outside of the class itself.
>
> Ahh - so when I had to use new kinds of parameters - I was rewriting. But
> if I'd made it all zero-impact on how it's used, it would have been
> refactoring.
>
> I don't get it. I can repeat it and rephrase it. But I don't get it.

This is a real example, taken from the 1970's but still valid.

A function was required to invert a matrix. The programmer decided to use
one method [1] which worked perfectly on the 6x6 test matrix. However when a
real world matrix was fed to the function took too long (estimates (by IBM)
were that for a 30x30 matrix it would have taken, with the then current
hardware, thousands of years to complete).

The function was refactored to use a different [2] method, which inverted
the 30x20 matrix in seconds.

This was _not_ fixing a bug, or even a programming mistake. It was changing
internals of the function to use a more efficient algorithm. Nothing in the
functions interface changed.

[1]
Using determinates, as discussed here
http://mathworld.wolfram.com/MatrixInverse.html
The method is of course recursive. The order of the algorithm is, I forget,
but very high, N to power of N or something.

[2]
Using reduction like done with systems of linear equations, discussed here:
http://www.purplemath.com/modules/mtrxinvr.htm
Order is about N IIRC.

--
Richard.

Re: Best Coding Practice

> No, refactoring is changing the implementation without changing the
> interface.

Please read the book before you utter nonsense.

Refactoring is changing the _structure_ of the code without changing the
_behaviour_ of that code. So interface changes can be refactorings.



> Refactoring in OO would mean you would not have to change anything
> outside of the class itself.

I think you confuse with the Open Closed Principle. The Open Closed
Principle and refactoring are perpendicular ways to adapt code in a
_controlled_ fashion: The Open Closed Principle leaves the structure
intact, while refactoring makes sure the code behaviour remains the same
while you are restructuring it.

Re: Best Coding Practice

Dikkie Dik wrote:
>> No, refactoring is changing the implementation without changing the
>> interface.
>
> Please read the book before you utter nonsense.
>
> Refactoring is changing the _structure_ of the code without changing the
> _behaviour_ of that code. So interface changes can be refactorings.
>

I have read the book - many times. And I've been involved in
"refactoring" since long before the term ever came up. The interface IS
the behavior - and changing the interface changes the behavior.

Refactoring means you don't have to chance code outside that which you
are changing. For instance, you can change the body of the function
without changing the function name, parameter list and return value.
This requires no change outside of the function, and is refactoring.

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.

Pull your head out of your ass and learn what you're talking about
before showing what an idiot you are.

>
>
>> Refactoring in OO would mean you would not have to change anything
>> outside of the class itself.
>
> I think you confuse with the Open Closed Principle. The Open Closed
> Principle and refactoring are perpendicular ways to adapt code in a
> _controlled_ fashion: The Open Closed Principle leaves the structure
> intact, while refactoring makes sure the code behaviour remains the same
> while you are restructuring it.

Not at all. But you have no idea what you're talking about.

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

Re: Best Coding Practice

..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

Micha

Re: Best Coding Practice

Michael Fesser wrote:
> .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
>
> Micha

And that's where I disagree with the author of the refactoring site.
But that's one person's opinion. Other people who have written about
refactoring

Changing the name of a function which is externally available is
changing the behavior. It means changing every piece of code which
calls the function.

For instance, between Apache 1.x and 2.x, the Apache foundation changed
some of the function calls. This causes problems with any modules which
call those functions.

By your argument, ZEND should change the fopen() call to be file_open().
How much code would that affect?

Rather, they might change the code to make it more efficient and not
change the function name. This is refactoring.

But the author is correct - there is very little information available
on refactoring. In some ways the site is good. But in other ways it
contains incorrect information.

As to the Wikipedia page - I have no idea who wrote this page. Was it
the same person? Or someone else without a good idea about it? Anyone
can create a page there. I could create one which says the sun rises in
the west. Does this make it so?

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

Re: Best Coding Practice

Dikkie Dik wrote:
>> No, refactoring is changing the implementation without changing the
>> interface.
>
> Please read the book before you utter nonsense.
>
> Refactoring is changing the _structure_ of the code without changing the
> _behaviour_ of that code. So interface changes can be refactorings.

Actually, refactor is a mathematical principle whose definition doesn't
even *address* the programming world.


> I think you confuse with the Open Closed Principle. The Open Closed
> Principle and refactoring are perpendicular ways to adapt code in a
> _controlled_ fashion: The Open Closed Principle leaves the structure
> intact, while refactoring makes sure the code behaviour remains the same
> while you are restructuring it.

Perpendicular... Open Closed Principle... blecchh.

Might just as well call them the Democrat, Libertarian and Republican
methods - for all the clarity it brings.

Re: Best Coding Practice

Jerry Stuckle wrote:

> And that's where I disagree with the author of the refactoring site. But
> that's one person's opinion. Other people who have written about
> refactoring


That's the way these discussions usually end up.
You get a bunch of folks who take a word like gigglethorpe, and each
assigns to it a meaning comfortable to himself. Then they argue which
one is the "true" meaning.

After digging in, I find that refactor is not an "opinion" word - it s a
mathematical term.

It was hijacked by some MBA's a few years ago, and incorporated into
their political philosophies on programming... like a logo.

Re: Best Coding Practice

..oO(Jerry Stuckle)

>Michael Fesser wrote:
>> .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
>>
>And that's where I disagree with the author of the refactoring site.
>But that's one person's opinion. Other people who have written about
>refactoring
>
>Changing the name of a function which is externally available is
>changing the behavior. It means changing every piece of code which
>calls the function.

IMHO it just depends on how you define "refactoring". In Martin Fowler's
"refactoring catalog" there are some more issues that might require a
tweaking of the calling code, it's not only the "rename method" thing.

>For instance, between Apache 1.x and 2.x, the Apache foundation changed
>some of the function calls. This causes problems with any modules which
>call those functions.
>
>By your argument, ZEND should change the fopen() call to be file_open().
> How much code would that affect?

True, but there are ways how to deal with issues like these, see below.

>Rather, they might change the code to make it more efficient and not
>change the function name. This is refactoring.

Agreed. But refactoring might be more. I don't think there's a strict
one-and-only definition.

>But the author is correct - there is very little information available
>on refactoring. In some ways the site is good. But in other ways it
>contains incorrect information.

What is correct?

In regard to this particular issue I read something like this on another
site: If a method's name has to be changed, the new method should be
added, while the old method should be kept - internally it should call
the new one and be marked as "deprecated" in the documentation. Sounds
like an acceptable way to me (and something I've already seen in many
projects).

>As to the Wikipedia page - I have no idea who wrote this page. Was it
>the same person?

Surely not.

>Or someone else without a good idea about it?

You think Fowler doesn't know what he's talking about? The Wikipedia
article was just a comment and a reference to his book/website.

Micha

Re: Best Coding Practice

Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> Michael Fesser wrote:
>>> .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
>>>
>> And that's where I disagree with the author of the refactoring site.
>> But that's one person's opinion. Other people who have written about
>> refactoring
>>
>> Changing the name of a function which is externally available is
>> changing the behavior. It means changing every piece of code which
>> calls the function.
>
> IMHO it just depends on how you define "refactoring". In Martin Fowler's
> "refactoring catalog" there are some more issues that might require a
> tweaking of the calling code, it's not only the "rename method" thing.
>
>> For instance, between Apache 1.x and 2.x, the Apache foundation changed
>> some of the function calls. This causes problems with any modules which
>> call those functions.
>>
>> By your argument, ZEND should change the fopen() call to be file_open().
>> How much code would that affect?
>
> True, but there are ways how to deal with issues like these, see below.
>
>> Rather, they might change the code to make it more efficient and not
>> change the function name. This is refactoring.
>
> Agreed. But refactoring might be more. I don't think there's a strict
> one-and-only definition.
>
>> But the author is correct - there is very little information available
>> on refactoring. In some ways the site is good. But in other ways it
>> contains incorrect information.
>
> What is correct?
>

That there is very little information available on refactoring.

> In regard to this particular issue I read something like this on another
> site: If a method's name has to be changed, the new method should be
> added, while the old method should be kept - internally it should call
> the new one and be marked as "deprecated" in the documentation. Sounds
> like an acceptable way to me (and something I've already seen in many
> projects).
>

Oh God. You've never had to deal with legacy code and "deprecated"
functions, have you? Very much a complete PITA!

>> As to the Wikipedia page - I have no idea who wrote this page. Was it
>> the same person?
>
> Surely not.
>

Are you sure?

>> Or someone else without a good idea about it?
>
> You think Fowler doesn't know what he's talking about? The Wikipedia
> article was just a comment and a reference to his book/website.
>
> Micha

I'm saying Martin Fowler is not the last word on anything. He is one
person with one opinion. Just like anyone else.

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

Re: Best Coding Practice

"Michael Fesser" 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.

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.

like i said before, there's no corner on any of this. 'extreme' programming
is an *OLD* construct under a new, stupid name.

but that's just my 0.02 usd and i appologise if i have stepped on someone
else's sacred cow. ;^)

Re: Best Coding Practice

Steve wrote:
> "Michael Fesser" 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.


> 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!

> like i said before, there's no corner on any of this. 'extreme' programming
> is an *OLD* construct under a new, stupid name.
>
> but that's just my 0.02 usd and i appologise if i have stepped on someone
> else's sacred cow. ;^)
>
>


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

Re: Best Coding Practice

"Jerry Stuckle" wrote in message
news:W5idncnku_TD10nbnZ2dnUVZ_g6dnZ2d@comcast.com...
| Steve wrote:
| > "Michael Fesser" 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.


| > 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). ;^)

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.

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?

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.

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

cheers.

[OT] Re: Best Coding Practice

Steve wrote:
> "Jerry Stuckle" wrote in message

> 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?
>
> 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.

It's always so wild when someone STARTS by saying I have my head up my
butt, and then GOES ON to say why they agree with me about stuff.

But I wonder - what is it about the nature of this industry that seems
draw such self-contradictory folks in *droves*.

I mean, if it was just here and there, it would be one thing. But our
industry has become somewhat of a national joke because of this kind of
bad character.

I'm not a very good coder - probably never will be - but I get a lot of
gigs where the client says something like, "Hey, your not as belligerent
as the last 12 web developers I hired" or "Wow, that's pretty
straight-forward. How come the last 8 developers couldn't say it that
plainly?".

The reason is obvious, would you rather hire a genius to belittle you,
your company and your project - or a half-wit who will get the job done.

Re: Best Coding Practice

Steve wrote:
> "Jerry Stuckle" wrote in message
> news:W5idncnku_TD10nbnZ2dnUVZ_g6dnZ2d@comcast.com...
> | Steve wrote:
> | > "Michael Fesser" 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
==================

Re: [OT] Re: Best Coding Practice

"Sanders Kaufman" wrote in message
news:FfhBi.304$4J3.145@newssvr22.news.prodigy.net...
| Steve wrote:
| > "Jerry Stuckle" wrote in message
|
| > 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?
| >
| > 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.
|
| It's always so wild when someone STARTS by saying I have my head up my
| butt, and then GOES ON to say why they agree with me about stuff.

i agree that to me, it's mostly lingo. HOWEVER UNLIKE YOU, i know BOTH
sides - what refactoring is, how it is used, have experienced the entire
'extreme programming' gammut. i have an INFORMED opinion while you not only
have your head up your ass, you seem quite comfortable in leaving it there
and speaking from it.

see the difference?


| The reason is obvious, would you rather hire a genius to belittle you,
| your company and your project - or a half-wit who will get the job done.

now that would entirely be based on the premise that 1) all geniuses
belittle people and 2) a half-wit can actually get the job done.

i'm glad you get jobs, but your category of 'wittedness' probably only
allows you exposure to those jobs that have little impact on things. if you
up the requirements or up the stakes, so too must you find developers that
can deliver. those would be the ones who learn about their industry
standards, practices, and yes, even lingo so that their expertise will lend
the best solution.

but you go ahead and be happy throwing dispution on things which you know
nothing about.

Re: Best Coding Practice

"Jerry Stuckle" wrote in message
news:WN2dnS1uY4uAOkjbnZ2dnUVZ_ternZ2d@comcast.com...
| Steve wrote:
| > "Jerry Stuckle" wrote in message
| > news:W5idncnku_TD10nbnZ2dnUVZ_g6dnZ2d@comcast.com...
| > | Steve wrote:
| > | > "Michael Fesser" 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.

all fine lines i suppose. i'm thinking of dll's here. i've always thought of
libraries as precursors to oop encapsulation...hence, really object-like.
but i do see your point.

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

thus my allusion of 'gui'. ;^) but i digress...

| > | > 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.

right. when i do use 'refactoring' in conversation, my boss knows i mean
that i'm not adding an enhancement and am usually just bringing shitty
coding practices into our standard...reformatting, consolidating code where
it is obvious some yahoo got the first bit working and then pasted it
elsewhere and maybe just changed on thing about it. hell, i did that this
week...some dumbass had 1,000 lines of billing validation for a 'current'
table, pasted that code right below and only changed the 'current' to
'history'. and the 1,000 lines where shit to begin with. i bettered the
query and got it to 200-ish. sorry, had to vent.

| > 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.

which is all they want to hear anyway. that, and that you'll have the new
features in place yesterday.

| > 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.

lol.

| > 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.

well, it's painfully obvious he doesn't. however, those other 'most'
programmers don't put down anything they know they don't know
about...especially with the fervor that he does.

keep 'em truck'n.

Re: Best Coding Practice

Jerry Stuckle wrote:

> 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.

I've been having a LOT of fun with that word ever since that discussion
we had about it.

The other day I was talking to a fellow who wanted to know how I was
doing with this framework. He liked what I've said about it so far, and
may very well pony up a few KiloBucks for me to mash his website into my
framework.

He asked me to tell him about whatever I was currently doing with it and
I said that I had to "refactor" it to make sure that I could later add
other DBMS's to it and the user not have to change their code. (That's
the correct use of "refactor", right?)

Man! The look he gave me!

I saw he was nervous, so I laughed and said, "no what I mean is..." and
then explained what I was doing in better detail.

It turns out that "refactor" is a scary word for him - one that's caused
him serious coin in the past. He said it's like when politicians say
they're leaving office "to spend time with my family"

He's not a technie; he's a businessman. So while he may not understand
the nitty-gritty of programming - he know's when he's being bull-shitted.


> 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.

Amen.


> 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.

I think of these buzz-word processes as Legacy business logic. A
pattern that may have worked will in the 20th century, when IT was new,
but not so much in the present day.

Now that computers, for most people, are not scary, impossibly complex,
proprietary things - folks are more comfortable hearing the real talk -
instead of the talk about the talk.

Re: [OT] Re: Best Coding Practice

Steve wrote:

> i agree that to me, it's mostly lingo. HOWEVER UNLIKE YOU, i know BOTH
> sides - what refactoring is, how it is used, have experienced the entire
> 'extreme programming' gammut. i have an INFORMED opinion while you not only
> have your head up your ass, you seem quite comfortable in leaving it there
> and speaking from it.

Man, I wish I could get my twit-filter working.

Re: Best Coding Practice

Steve wrote:
> "Jerry Stuckle" wrote in message

> | I think Sanders is just being honest when he says he's in the dark about
> | it. I think most programmers are.
>
> well, it's painfully obvious he doesn't. however, those other 'most'
> programmers don't put down anything they know

Really?!
In my experience, and I speak FOR myself as well, most engineering types
are HIGHLY critical of things they don't understand.

It's a side-effect of keeping yourself informed. If you're a smart
engineer, and you've kept your skills sharp, and then some businessman
comes along and tells you that "waterfall" or "extreme" or "agile" is
THE best way for you to work - you'd be a fool not to be critical.

Especially if, like so many of us here, you're an individual contributor.

Re: Best Coding Practice

On Aug 29, 2:41 pm, Sanders Kaufman wrote:
> Steve wrote:
> > "Jerry Stuckle" wrote in message
> > | I think Sanders is just being honest when he says he's in the dark about
> > | it. I think most programmers are.
>
> > well, it's painfully obvious he doesn't. however, those other 'most'
> > programmers don't put down anything they know
>
> Really?!
> In my experience, and I speak FOR myself as well, most engineering types
> are HIGHLY critical of things they don't understand.
>
> It's a side-effect of keeping yourself informed. If you're a smart
> engineer, and you've kept your skills sharp, and then some businessman
> comes along and tells you that "waterfall" or "extreme" or "agile" is
> THE best way for you to work - you'd be a fool not to be critical.
>
> Especially if, like so many of us here, you're an individual contributor.

Man, I go away for a couple days and 50+ posts, about 20 different
kinds of insults targeted at an individual engineering capabilities,
and still having fun!

Re: Best Coding Practice

ELINTPimp wrote:
> On Aug 29, 2:41 pm, Sanders Kaufman wrote:

>> Especially if, like so many of us here, you're an individual contributor.
>
> Man, I go away for a couple days and 50+ posts, about 20 different
> kinds of insults targeted at an individual engineering capabilities,
> and still having fun!

That's sorta my fault. I'm a real mensch on the political newsgroups
and at least one of my trolls followed me here.

Sorry.

Re: [OT] Re: Best Coding Practice

"Sanders Kaufman" wrote in message
news:uYiBi.21849$eY.2411@newssvr13.news.prodigy.net...
| Steve wrote:
|
| > i agree that to me, it's mostly lingo. HOWEVER UNLIKE YOU, i know BOTH
| > sides - what refactoring is, how it is used, have experienced the entire
| > 'extreme programming' gammut. i have an INFORMED opinion while you not
only
| > have your head up your ass, you seem quite comfortable in leaving it
there
| > and speaking from it.
|
| Man, I wish I could get my twit-filter working.

why? then you'd think none of your posts were making it to the server!

Re: Best Coding Practice

"Sanders Kaufman" wrote in message
news:f5jBi.585$ZA5.344@nlpi068.nbdc.sbc.com...
| Steve wrote:
| > "Jerry Stuckle" wrote in message
|
| > | I think Sanders is just being honest when he says he's in the dark
about
| > | it. I think most programmers are.
| >
| > well, it's painfully obvious he doesn't. however, those other 'most'
| > programmers don't put down anything they know
|
| Really?!
| In my experience, and I speak FOR myself as well, most engineering types
| are HIGHLY critical of things they don't understand.
|
| It's a side-effect of keeping yourself informed. If you're a smart
| engineer, and you've kept your skills sharp, and then some businessman
| comes along and tells you that "waterfall" or "extreme" or "agile" is
| THE best way for you to work - you'd be a fool not to be critical.
|
| Especially if, like so many of us here, you're an individual contributor.

you'd only be a fool NOT TO LEARN WHAT HE WAS TALKING ABOUT...which is why
you should watch leving the word 'fool'...since you hear 'refactoring',
don't look into it, and then talk outta your ass like you understood it
(which makes you even moreso).

Re: Best Coding Practice

"Sanders Kaufman" wrote in message
news:6gkBi.602$ZA5.457@nlpi068.nbdc.sbc.com...
| ELINTPimp wrote:
| > On Aug 29, 2:41 pm, Sanders Kaufman wrote:
|
| >> Especially if, like so many of us here, you're an individual
contributor.
| >
| > Man, I go away for a couple days and 50+ posts, about 20 different
| > kinds of insults targeted at an individual engineering capabilities,
| > and still having fun!
|
| That's sorta my fault. I'm a real mensch on the political newsgroups
| and at least one of my trolls followed me here.

or perhaps the truth lies in simply stating you are a real mensch and that
wherever you go, people realise this and react to it. unless you're of the
'i'm ok, everyone else is not' type of mentality. jury still out.

Re: Best Coding Practice

| The other day I was talking to a fellow who wanted to know how I was
| doing with this framework. He liked what I've said about it so far, and
| may very well pony up a few KiloBucks for me to mash his website into my
| framework.
|
| He asked me to tell him about whatever I was currently doing with it and
| I said that I had to "refactor" it to make sure that I could later add
| other DBMS's to it and the user not have to change their code. (That's
| the correct use of "refactor", right?)
|
| Man! The look he gave me!

and you were a dumbass to use private lingo to a public audience! 'refactor'
in programming is of no use to someone outside of programming. it could also
be lingo in another context. the fact that you don't know what appropriate
language to speak to whom and when is frightening!

| He's not a technie; he's a businessman. So while he may not understand
| the nitty-gritty of programming - he know's when he's being bull-shitted.

apparently not. he's considering your framework, right. ;^)

| I think of these buzz-word processes as Legacy business logic. A
| pattern that may have worked will in the 20th century, when IT was new,
| but not so much in the present day.

only, with the discussion at hand, refactoring and the greater context it
was birthed in are very sound programming methods to employ to ensure
quality. if you knew what you were talking about, you'd know the practice is
more than just words you don't understand. sad, it involves processes yet
known to you!

| Now that computers, for most people, are not scary, impossibly complex,
| proprietary things - folks are more comfortable hearing the real talk -
| instead of the talk about the talk.

so why the hell would you think lingo is profitably entangled with standard
english...such that you don't know to filter based on audience? that's just
dumb. i already think that about you, why are you giving me more cause?!

Re: Best Coding Practice

..oO(Steve)

>[...]
>| > | > 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'.
>[...]

OT, but would it be possible for you to use a proper quote indicator '>'
instead of '|' like all others on Usenet? Your posts are very hard to
read, and OE makes it even worse because of its stupid line breaking.

Micha

Re: Best Coding Practice

Michael Fesser wrote:
> .oO(Steve)

>> | > 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'.
>> [...]
>
> OT, but would it be possible for you to use a proper quote indicator '>'
> instead of '|' like all others on Usenet? Your posts are very hard to
> read, and OE makes it even worse because of its stupid line breaking.

Thanks for posting that. I thought I had a checkbox wrong somewhere
that was creating the mish-mash.

Re: Best Coding Practice

> OT, but would it be possible for you to use a proper quote indicator '>'
> instead of '|' like all others on Usenet? Your posts are very hard to
> read, and OE makes it even worse because of its stupid line breaking.
>
> Micha

just cuz it's you doing the asking. ;^)

Re: Best Coding Practice

>> OT, but would it be possible for you to use a proper quote indicator '>'
>> instead of '|' like all others on Usenet? Your posts are very hard to
>> read, and OE makes it even worse because of its stupid line breaking.
>
> Thanks for posting that. I thought I had a checkbox wrong somewhere that
> was creating the mish-mash.

seems all evidence indicates that you are easily stymmied. ;^)

Re: Best Coding Practice

On Aug 24, 5:41 am, "burgermeiste...@gmail.com"
wrote:
> First, let me say that this question is a rather general programming
> question, but the context is PHP, so I figured this group would have
> the most relevant insight.
>
> Anyways, this is also more of an opinion based question than one
> seeking a definite answer. Recently, while maintaining a rather large
> system. I needed to add an array class member to an object. It was
> exactly the same as another class member, except that one array stored
> regular products, and the other stored free promotional products. As
> such, I needed a way to add products to the new, free array. Since all
> the logic was the same between the two arrays aside from the price, I
> had a few different options to do this. I'm interested in polling
> which way some of the group members feel would have been the best.
> Naturally these are abbreviated versions of what I envisioned as
> possible solutions.
> #1.
> public function addArrayA($object){
> //logic
> $a[] = $object;
>
> }
>
> public function addArrayB($object){
> //same logic
> $b[] = $object;
>
> }
>
> #2. (These next two are arranged as such, because the class using
> these functions is included in many script files,
> all of which I may not be aware of, so there would have to be some
> default value for the array that was always used
> before this new array was needed)
> public function addArray($object, $free = NULL){
> //logic
> if(!$free){
> $a[] = $object;
> }else{
> $b[] = $object;
> }
>
> }
>
> or
>
> #3
> public function addArray($object, $arr = "a"){
> //logic
> $$arr[] = $object;
>
> }
>
> I ended up going with option number 1, because I felt that despite the
> inefficient, redundant code it would later be more readable to other
> programmers that might work on the project. Additionally, I didn't
> feel wholly comfortable with default variables being the only
> difference between a full price product and a free product. Thoughts?

I will choose option 2.

Or better store it like this:

array (
[0]
type=>free
prod=>pid
[1]
type=>paid
prod=pid

)


http://satya61229.blogspot.com

Re: Best Coding Practice

On Aug 24, 5:41 am, "burgermeiste...@gmail.com"
wrote:

> #1.
> public function addArrayA($object){
> //logic
> $a[] = $object;
>
> }
>
> public function addArrayB($object){
> //same logic
> $b[] = $object;
>
> }

This may be a good solution for just 2 object arrays. But, for some
generalization, I'd prefer:
public function addArray($object, $key='a'){
$arr[$key][] = $object;
}

--

Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

Re: Best Coding Practice

R. Rajesh Jeba Anbiah wrote:
> On Aug 24, 5:41 am, "burgermeiste...@gmail.com"
> wrote:
>
>> #1.
>> public function addArrayA($object){
>> //logic
>> $a[] = $object;
>>
>> }
>>
>> public function addArrayB($object){
>> //same logic
>> $b[] = $object;
>>
>> }
>
> This may be a good solution for just 2 object arrays. But, for some
> generalization, I'd prefer:
> public function addArray($object, $key='a'){
> $arr[$key][] = $object;
> }
>
> --
>
> Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
>

But this creates much more problems - like keeping track of keys, etc.

Better would be having one array in the object with an "Add" function.
If you need two different arrays, create two different objects.

And if you need to relate the objects, have a second class which allows
you to add as many of these objects as you wish.

This allows as many arrays as the user needs without having to worry
about ensuring you have the correct keys, etc.

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