OO in PHP

Please, someone, tell me why OO in PHP is better than procedural.

Mudge wrote:
[color=blue]
> Please, someone, tell me why OO in PHP is better than procedural.[/color]

And please be specific. Don't tell me something general like it increases
code re-usibility.

Mudge wrote:
[color=blue]
> Please, someone, tell me why OO in PHP is better than procedural.[/color]

Who said it was? For some things OO is better, for others procedural is
better. I would say the same for all OO languages I have programmed in, and
I often mix the two in a project.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

*** Mudge wrote/escribió (Thu, 08 Jul 2004 06:23:52 GMT):[color=blue]
> And please be specific. Don't tell me something general like it increases
> code re-usibility.[/color]

If you want specific answers you should make specific question, shouldn't
you? ;-) In computer science you can never say "A is better than B" without
first considering what you need to do.

--
--
-- Álvaro G. Vicario - Burgos, Spain
--

Alvaro G Vicario wrote:
[color=blue]
> *** Mudge wrote/escribiÃ³ (Thu, 08 Jul 2004 06:23:52 GMT):[color=green]
>> And please be specific. Don't tell me something general like it increases
>> code re-usibility.[/color]
>
> If you want specific answers you should make specific question, shouldn't
> you? ;-) In computer science you can never say "A is better than B"
> without first considering what you need to do.
>[/color]

I want to build a large customized content management system in PHP. Should
I use OO or procedural?

I never went to computer science school.

Mudge (mark1822@hotmail.com) wrote:
: Alvaro G Vicario wrote:

: > *** Mudge wrote/escribiÃ³ (Thu, 08 Jul 2004 06:23:52 GMT):
: >> And please be specific. Don't tell me something general like it increases
: >> code re-usibility.
: >
: > If you want specific answers you should make specific question, shouldn't
: > you? ;-) In computer science you can never say "A is better than B"
: > without first considering what you need to do.
: >

: I want to build a large customized content management system in PHP. Should
: I use OO or procedural?

You should probably use an existing content management system.

Otherwise, yes, you should use OO or procedural.

"Mudge" <mark1822@hotmail.com> schrieb im Newsbeitrag
news:oo6Hc.44433$XM6.8100@attbi_s53...[color=blue]
> Alvaro G Vicario wrote:
>[color=green]
> > *** Mudge wrote/escribió (Thu, 08 Jul 2004 06:23:52 GMT):[color=darkred]
> >> And please be specific. Don't tell me something general like it[/color][/color][/color]
increases[color=blue][color=green][color=darkred]
> >> code re-usibility.[/color]
> >
> > If you want specific answers you should make specific question,[/color][/color]
shouldn't[color=blue][color=green]
> > you? ;-) In computer science you can never say "A is better than B"
> > without first considering what you need to do.
> >[/color]
>
> I want to build a large customized content management system in PHP.[/color]
Should[color=blue]
> I use OO or procedural?[/color]

I am actually re-writing my large customized content management system the
OO way, using PEAR libraries. For 2 reasons:
1. I want to learn how to write OO and how to use the advantages of PEAR
packages
2. it increases code readability and re-usibility ;-) and thus makes it
easier to maintain, update and enlarge the program

What more do you want to be told? Your programming style is essential for
you, but not for your project. It does not affect the functions, usability,
or design of your system.

Markus

Mudge wrote:
[color=blue]
> Alvaro G Vicario wrote:
>[color=green]
>> *** Mudge wrote/escribió (Thu, 08 Jul 2004 06:23:52 GMT):[color=darkred]
>>> And please be specific. Don't tell me something general like it
>>> increases code re-usibility.[/color]
>>
>> If you want specific answers you should make specific question, shouldn't
>> you? ;-) In computer science you can never say "A is better than B"
>> without first considering what you need to do.
>>[/color]
>
> I want to build a large customized content management system in PHP.
> Should I use OO or procedural?
>
> I never went to computer science school.[/color]

Then you need to decide for yourself which is more appropriate

C.

OO is not better than Procedural, just different. Take a look at
http://www.zend.com/zend/art/oo-proc.php

--
Tony Marston

http://www.tonymarston.net

"Mudge" <mark1822@hotmail.com> wrote in message
news:KJ5Hc.27769$JR4.14751@attbi_s54...[color=blue]
> Please, someone, tell me why OO in PHP is better than procedural.[/color]

"Mudge" <mark1822@hotmail.com> wrote in message
news:YL5Hc.27779$JR4.8479@attbi_s54...[color=blue]
> Mudge wrote:
>[color=green]
> > Please, someone, tell me why OO in PHP is better than procedural.[/color]
>
> And please be specific. Don't tell me something general like it increases
> code re-usibility.[/color]

That answer is also crap. It is possible to write acres of reusable code
without using OO at all. It is also possible to use OO techniques and
produce code that is virtually unusable.

The paradigm (OO or Procedural) is irrelevant. It is all down to how you
implement it.

--
Tony Marston

http://www.tonymarston.net

Mudge <mark1822@hotmail.com> wrote in message news:<oo6Hc.44433$XM6.8100@attbi_s53>...[color=blue]
> Alvaro G Vicario wrote:
>[color=green]
> > *** Mudge wrote/escribiÃ³ (Thu, 08 Jul 2004 06:23:52 GMT):[color=darkred]
> >> And please be specific. Don't tell me something general like it increases
> >> code re-usibility.[/color]
> >
> > If you want specific answers you should make specific question, shouldn't
> > you? ;-) In computer science you can never say "A is better than B"
> > without first considering what you need to do.
> >[/color]
>
> I want to build a large customized content management system in PHP. Should
> I use OO or procedural?
>
> I never went to computer science school.[/color]

How much about PHP do you know in the first place, much less general
programming and content management? If you know these basics, then
you should assess your needs and then determine if OO or procedural is
better for you.

Study in the PHP manual under OO concepts and look up the plusses and
minuses; along with that, assess which version of PHP are you working
with in order to be able to know what is better for you.

Your response is far too vague to be able to give you an answer and
without demonstrating any research on your end, nobody can answer
that.

I can tell you, though, that in my application development I've used a
blend of procedural and OO together in various components and
"JAR-like" libraries.

Phil

Chris Hope wrote:[color=blue]
> Mudge wrote:
>
>[color=green]
>>Please, someone, tell me why OO in PHP is better than procedural.[/color]
>
>
> Who said it was? For some things OO is better, for others procedural is
> better. I would say the same for all OO languages I have programmed in, and
> I often mix the two in a project.
>[/color]

it's kinda-like asking do you like apples or oranges.. the answer is: I
like both and sometimes in a mixed bowl of fruit...

languages and methods are just tools, you use the tool that gets the job
done.... and if you are lazy like me, with the least amount of effort.

Michael Austin.

On Thu, 08 Jul 2004 06:23:52 GMT, Mudge <mark1822@hotmail.com> wrote:
[color=blue]
>Mudge wrote:
>[color=green]
>> Please, someone, tell me why OO in PHP is better than procedural.[/color]
>
>And please be specific. Don't tell me something general like it increases
>code re-usibility.[/color]

It increases code re-usablility.

Oh, wait you want a better answer....

Really it depends. I kind of flip-flop as to whether I setup an object
to be called or I just hard-code a procedure and copy it where I need
it.

Objects can be useful or re-usablity and in particular where
inheretance is needed. They do carry a bit of (mental) overhead though
and need to be managed.

For one-off type procedures, however, object-based code may make
little sense. (To me anyway). I often start out my coding by writing
(or specing for) procedural functions, but then decide later to turn
them into object if they meet my criteria for reuse. In other words,
if it isn't easier for me and my programming team to use the object,
don't.

Just my $.02 - this opinion may not be valid for others.

kai
www.perfectreign.com || www.filesite.org
g2004 at g3prod.cotse.net

On Thu, 08 Jul 2004 11:11:23 +0100, Tony Marston wrote:
[color=blue]
> That answer is also crap. It is possible to write acres of reusable code
> without using OO at all.[/color]

Agreed. User-defined functions are by definition re-usable code and do
not have to be OO at all.

--
Jeffrey D. Silverman | jeffrey@pantsjhu.edu **
Website | http://www.newtnotes.com

(** Drop "pants" to reply by email)

"Mudge" <mark1822@hotmail.com> wrote in message
news:oo6Hc.44433$XM6.8100@attbi_s53...[color=blue]
> Alvaro G Vicario wrote:
>[color=green]
> > *** Mudge wrote/escribió (Thu, 08 Jul 2004 06:23:52 GMT):[color=darkred]
> >> And please be specific. Don't tell me something general like it[/color][/color][/color]
increases[color=blue][color=green][color=darkred]
> >> code re-usibility.[/color]
> >
> > If you want specific answers you should make specific question,[/color][/color]
shouldn't[color=blue][color=green]
> > you? ;-) In computer science you can never say "A is better than B"
> > without first considering what you need to do.
> >[/color]
>
> I want to build a large customized content management system in PHP.[/color]
Should[color=blue]
> I use OO or procedural?
>
> I never went to computer science school.[/color]

Psssst. <hushed-voice>Objects merely encapsulate procedural
code</hushed-voice>

Ahem. Objects organize code into reusable components... and couple the
behavior with the associated data. Okay, major oversimplification... but the
fact is that when you get to the bottom line, someone has to write some code
to manipulate some data.

- Virgil

"Tony Marston" <tony@NOSPAM.demon.co.uk> emerged reluctantly from
the curtain and staggered drunkenly up to the mic. In a cracked
and slurred voice he muttered:
[color=blue]
> That answer is also crap. It is possible to write acres of
> reusable code without using OO at all. It is also possible to
> use OO techniques and produce code that is virtually unusable.
>
> The paradigm (OO or Procedural) is irrelevant. It is all down to
> how you implement it.[/color]

I agree with this. The benefit (as I see it) of object-orientation
is it better allows the modelling of real-world situations in code.
So you think of your code as objects with tasks rather than a list
of sequential procedures.

--
Phil Roberts | Without me its just aweso. | http://www.flatnet.net/

"Mankind differs from the animals only by a little,
and most people throw that away."
- Confucious

Tony Marston wrote:[color=blue]
> OO is not better than Procedural, just different. Take a look at
> http://www.zend.com/zend/art/oo-proc.php
>[/color]
Or is it? Take a look at:
http://groups.google.nl/groups?hl=nl...com%26rnum%3D1

Many problems that are tributed to OO are in fact problems with C++ and
Java that did not occur in Smalltalk, the cradle of OO.

"The thing that I really hate about Smalltalk,
though, is the fact that every time I wish C++
or Java did something differently it turns out
that Smalltalk does it the way I want it to.
I've never even used Smalltalk on a real project.
I just learned it so that I could read source code,
now I keep running into things that would be easier
if I were using it. It's really annoying.
(Phil Goodwin)

Php is closer to Smalltalk then C++ and Java. And it's getting better
with php5.

I have been explaining and advocating OO since 1992. Back then people
had a hard time to believe my explanation that objects are like the
small creatures that creep around in (now retro) computer games like
pacman. They said it was only simulation. They are right, there eare no
buttons on you screen, no menu's, no letters, only pixels. But though
still "garbage in garbage out" people sometimes claim to make sense out
of those pixels, calling it buttons, letters etc, and programmers
sometimes can manipulate the pixels so that they keep saying that again
and again.

Now what is the use of programming a computer as if it where filled with
little pacman like creatures? Maybe because it makes more sense to
humans then having a single entity do everthing on its own, folling
endless lists of procedural instructions? It is next to impossible to
convince someone about this.

Nowadays i usually do not need to. OO simply has made it to the
mainstream, those who still disagree are now the ones that need to
convince others. So i am no longer advocating OO, i now can let the
opponents do the arguing, and see how (un)convincing they are.

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Phil Roberts wrote:
[color=blue]
> "Tony Marston" <tony@NOSPAM.demon.co.uk> emerged reluctantly from
> the curtain and staggered drunkenly up to the mic. In a cracked
> and slurred voice he muttered:
>
>[color=green]
>>That answer is also crap. It is possible to write acres of
>>reusable code without using OO at all. It is also possible to
>>use OO techniques and produce code that is virtually unusable.
>>
>>The paradigm (OO or Procedural) is irrelevant. It is all down to
>>how you implement it.[/color]
>
>
> I agree with this. The benefit (as I see it) of object-orientation
> is it better allows the modelling of real-world situations in code.
> So you think of your code as objects with tasks rather than a list
> of sequential procedures.
>[/color]

A well-known {paraphrased} quote from either Codd or Date (don't recall
which one) was that "we spent years breaking data into usable parts, now
all the OO people are putting it all back together again" -- or
something like that...

The mathematical computations for the relational model would be very
daunting to most DBA's today (including me -- and I have the book. :) )

Michael Austin.

"Henk Verhoeven" <news@phppeanutsREMOVE-THIS.org> wrote in message
news:cck5p0$ho9$1@news3.tilbu1.nb.home.nl...[color=blue]
> Tony Marston wrote:[color=green]
> > OO is not better than Procedural, just different. Take a look at
> > http://www.zend.com/zend/art/oo-proc.php
> >[/color]
> Or is it? Take a look at:
>[/color]
http://groups.google.nl/groups?hl=nl...com%26rnum%3D1[color=blue]
>
> Many problems that are tributed to OO are in fact problems with C++ and
> Java that did not occur in Smalltalk, the cradle of OO.
>
> "The thing that I really hate about Smalltalk,
> though, is the fact that every time I wish C++
> or Java did something differently it turns out
> that Smalltalk does it the way I want it to.
> I've never even used Smalltalk on a real project.
> I just learned it so that I could read source code,
> now I keep running into things that would be easier
> if I were using it. It's really annoying.
> (Phil Goodwin)
>
> Php is closer to Smalltalk then C++ and Java. And it's getting better
> with php5.
>
> I have been explaining and advocating OO since 1992. Back then people
> had a hard time to believe my explanation that objects are like the
> small creatures that creep around in (now retro) computer games like
> pacman. They said it was only simulation. They are right, there eare no
> buttons on you screen, no menu's, no letters, only pixels. But though
> still "garbage in garbage out" people sometimes claim to make sense out
> of those pixels, calling it buttons, letters etc, and programmers
> sometimes can manipulate the pixels so that they keep saying that again
> and again.
>
> Now what is the use of programming a computer as if it where filled with
> little pacman like creatures? Maybe because it makes more sense to
> humans then having a single entity do everthing on its own, folling
> endless lists of procedural instructions? It is next to impossible to
> convince someone about this.
>
> Nowadays i usually do not need to. OO simply has made it to the
> mainstream, those who still disagree are now the ones that need to
> convince others. So i am no longer advocating OO, i now can let the
> opponents do the arguing, and see how (un)convincing they are.[/color]

OO is not the be-all and end-all of computer programming. It is simply one
technique among many which can be used and abused just like any other
technique. It is possible to write bad programs in OO just as it is possible
to write bad procedural code. Using OO does not prevent mistakes, it simply
produces a different class of mistake.

--
Tony Marston

http://www.tonymarston.net

Mudge <mark1822@hotmail.com> wrote in message
news:<KJ5Hc.27769$JR4.14751@attbi_s54>...[color=blue]
>
> Please, someone, tell me why OO in PHP is better than procedural.[/color]

It's not. OO was added to PHP as an afterthought and tends to
create all kinds of unnecessary overhead. This said, OOP may
be required to interact with other technologies that do not have
procedural interfaces (COM, LDAP, etc.)

Cheers,
NC

Nikolai Chuvakhin a écrit :[color=blue]
> Mudge <mark1822@hotmail.com> wrote in message
> news:<KJ5Hc.27769$JR4.14751@attbi_s54>...
>[color=green]
>>Please, someone, tell me why OO in PHP is better than procedural.[/color]
>
>
> It's not. OO was added to PHP as an afterthought and tends to
> create all kinds of unnecessary overhead. This said, OOP may
> be required to interact with other technologies that do not have
> procedural interfaces (COM, LDAP, etc.)[/color]

LDAP ? Does not have a procedural interface ? Oh, my ! So I've spent so
many hours writing an OO wrapper around the (non-existing) procedural
interface to LDAP ? My bad :(

But... Wait a minute... Where is the manual ?
http://fr3.php.net/manual/en/ref.ldap.php

Oh, yes, I see...

"Mudge" <mark1822@hotmail.com> wrote in message
news:oo6Hc.44433$XM6.8100@attbi_s53...[color=blue]
> Alvaro G Vicario wrote:
>[color=green]
> > *** Mudge wrote/escribió (Thu, 08 Jul 2004 06:23:52 GMT):[color=darkred]
> >> And please be specific. Don't tell me something general like it[/color][/color][/color]
increases[color=blue][color=green][color=darkred]
> >> code re-usibility.[/color]
> >
> > If you want specific answers you should make specific question,[/color][/color]
shouldn't[color=blue][color=green]
> > you? ;-) In computer science you can never say "A is better than B"
> > without first considering what you need to do.
> >[/color]
>
> I want to build a large customized content management system in PHP.[/color]
Should[color=blue]
> I use OO or procedural?
>
> I never went to computer science school.[/color]

Well, a mixture of the two is probably the best advise. The database layer I
would implement with OO, as the use of objects tends to simplify code that
deal with states and storage. For the presentation layer I would stick with
procedural code, as the output of HTML is better modeled as a linear
process.

"Henk Verhoeven" <news@phppeanutsREMOVE-THIS.org> wrote in message
news:cck5p0$ho9$1@news3.tilbu1.nb.home.nl...[color=blue]
> Nowadays i usually do not need to. OO simply has made it to the
> mainstream, those who still disagree are now the ones that need to
> convince others. So i am no longer advocating OO, i now can let the
> opponents do the arguing, and see how (un)convincing they are.
>
> Greetings,
>
> Henk Verhoeven,
> www.phpPeanuts.org.[/color]

Vanity programming is the worst kind of programming. People who program in
OO because it's somehow "mainstream" are the same peons who watch American
Idols and follow the Arkins diet.

Chung Leong wrote:[color=blue]
> Vanity programming is the worst kind of programming. People who program in
> OO because it's somehow "mainstream" are the same peons who watch American
> Idols and follow the Arkins diet.
>[/color]
Hi chung,

I like your reply :-)))

But OTOH i do think there is a rationale for some conformism towards
commonly accepted standards and best practices. However, OO is not
simply a "best practice" or so, imho it's a paradigm in the sense T.S.
Kuhn meant in his book "Structure of scientific revolutions". Kuhn
explained the impossability of logical or even empirical falsification
of a paradigm and described how consensus between scientists in the end
is descisive in the competition between paradigms. In that respect OO
getting into the mainstream, maybe even becoming the leading paradigm,
is the most rational measure we have of its value.

Of course this does not mean that arguments are not important, and
certainly not that discussions should stop. But it can be expected that
progress will come from NEW paradigms, not from old, predecessor ones
like procedural or structural programming.

Greetings,

Henk.

P.S. i do believe that building good software requires an open mind,
originality and creativity and that conformism is not very compatible
with that. And i must confess that i share your romantic belief that
*good* developers do not watch American Idols and follow the Arkins diet ;-)

Tony Marston wrote:[color=blue]
> OO is not the be-all and end-all of computer programming. It is simply one
> technique among many which can be used and abused just like any other
> technique. It is possible to write bad programs in OO just as it is possible
> to write bad procedural code. Using OO does not prevent mistakes, it simply
> produces a different class of mistake.
>[/color]

Tony, i totally agree, except for OO to be a technique, i think it's a
paradigm, see my reply to Chung Leong. Many bad programs that use
objects and classes seem bad to me because they brutally violate a very
basic principle of OO. Usually they also violate basic principles of
structured programming.

It would be interesting to see code that abuses principles of OO to
create a bad program. And i do not meen a program that does evil things,
like a virus. I mean badly designed. But i am sure it can be done, OO
has its limitations, it's just hard to see them without a new paradigm
to make them visible.

One furter remark about mistakes: the number of bugs introduced tends to
be proportional to the amount of code that is written. This is
independent from the number of years of experience of the programmer.
But the more frequent existing code is used, the more bugs are removed
by debugging. So reusing existing code instead of writing new code will
in practice decrease the number of bugs in the end user software in two
ways: less code, more frequently used. (To my knowledge there is no
evidence that following code patterns does this too)

Greetings,

Henk.

Illustration: Amiga, OO without classes

I once studied some good programming manuals about the Amiga OS
libraries. They showed an impressive smartness and discipline in the
combined use of structs, libraries and function pointers, but it was
hard to grasp. Later, when i learnt OO, i concluded the deveolpers of
the Amiga must have understood the principles of OO very well. Yet they
used flat c for implementation.

Interesting detail: The amiga 500 had a multi tasking operating system
with a GUI in only 256 Kb rom and 880 Kb disk. Compare that to the size
of the first version of windows 95...

Henk Verhoeven <news@phppeanutsREMOVE-THIS.org> wrote in message news:<ccls6n$dr4$1@news2.tilbu1.nb.home.nl>...[color=blue]
> Chung Leong wrote:[color=green]
> > Vanity programming is the worst kind of programming. People who program in
> > OO because it's somehow "mainstream" are the same peons who watch American
> > Idols and follow the Arkins diet.
> >[/color]
> Hi chung,
>
> I like your reply :-)))
>
> But OTOH i do think there is a rationale for some conformism towards
> commonly accepted standards and best practices. However, OO is not
> simply a "best practice" or so, imho it's a paradigm in the sense T.S.
> Kuhn meant in his book "Structure of scientific revolutions". Kuhn
> explained the impossability of logical or even empirical falsification
> of a paradigm and described how consensus between scientists in the end
> is descisive in the competition between paradigms. In that respect OO
> getting into the mainstream, maybe even becoming the leading paradigm,
> is the most rational measure we have of its value.
>
> Of course this does not mean that arguments are not important, and
> certainly not that discussions should stop. But it can be expected that
> progress will come from NEW paradigms, not from old, predecessor ones
> like procedural or structural programming.[/color]

That reminds me, what is the latest consensus on AOP as opposed to OOP
and is that even being considered within the PHP community?

[color=blue]
>
> Greetings,
>
> Henk.
>
> P.S. i do believe that building good software requires an open mind,
> originality and creativity and that conformism is not very compatible
> with that. And i must confess that i share your romantic belief that
> *good* developers do not watch American Idols and follow the Arkins diet ;-)[/color]

We're too busy coding to watch stupid reality shows. We watch the
History Channel and eat large slabs of meat, and the occasional sushi!
;)

Phil

Phil Powell wrote:
[color=blue]
> That reminds me, what is the latest consensus on AOP as opposed to OOP
> and is that even being considered within the PHP community?[/color]

Personally i would rather have some more abstract or low level form of
implicit delegation being supported by PHP (directly without
precompilation). It should be implemented in such way that one can at
least use it for AOP, Composition Filters, proxies and Smalltalks
#doesNotUnderstand:, Preferably it allows framework development in such
a way that design patterns become an outdated, somewhat clumsy form of
expression.

I must admit i do not have a concrete proposal, but if one builds AOP,
Composition Filters, proxies and Smalltalks #doesNotUnderstand: into PHP
and then tries to refactor all modifications he made to PHP into a
single language extension (one single keyword or function) he might get
close.

Greetings,

Henk Verhoeven,
www,phpPeanuts.org.

Hello,

On 07/09/2004 04:03 PM, Henk Verhoeven wrote:[color=blue]
> Phil Powell wrote:
>[color=green]
> > That reminds me, what is the latest consensus on AOP as opposed to OOP
> > and is that even being considered within the PHP community?[/color]
>
> Personally i would rather have some more abstract or low level form of
> implicit delegation being supported by PHP (directly without
> precompilation).[/color]

AOP is not different and OOP. It is just a way to make more efficient
software (read not so bloated) by only including the Aspects that you
really want in the software that you load at runtime.

The problem with traditional OOP is that as you evolve your library
classes to make them more flexible, you keep adding code that will
probably be use just in case.

That gets worse with cascaded dependencies: classes that get loaded just
because you used one feature that you want from one class that requires
other classes to implement features that you do not need.

It would be better if you just could tell what features you need and a
magic generator would generate a class that includes the aspects that
you really will use at run time.

This is the approach of Metastorage Data Access Object (DAO) classes
generator. You just describe your DAO classes and specify which
functionality you need. Then it just generates JE WIN code (Just Exactly
What I Need). For instance, if you will never need to delete persistent
objects, Metastorage will not generate delete object functions.

The result is more compact software that loads faster at run time and
saves memory. This is an actual call for Code Generation based solutions
like Metastorage which implements a black box approach for AOP. There
are also white box approaches to AOP based on code insertion on existing
code.

You may find more about Metastorage here:

http://www.meta-language.net/metastorage.html

--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

Henk Verhoeven wrote:
[color=blue]
> Tony Marston wrote:
>[color=green]
>> OO is not the be-all and end-all of computer programming. It is simply
>> one
>> technique among many which can be used and abused just like any other
>> technique. It is possible to write bad programs in OO just as it is
>> possible
>> to write bad procedural code. Using OO does not prevent mistakes, it
>> simply
>> produces a different class of mistake.
>>[/color]
>
> Tony, i totally agree, except for OO to be a technique, i think it's a
> paradigm, see my reply to Chung Leong. Many bad programs that use
> objects and classes seem bad to me because they brutally violate a very
> basic principle of OO. Usually they also violate basic principles of
> structured programming.
>
> It would be interesting to see code that abuses principles of OO to
> create a bad program. And i do not meen a program that does evil things,
> like a virus. I mean badly designed. But i am sure it can be done, OO
> has its limitations, it's just hard to see them without a new paradigm
> to make them visible.
>
> One furter remark about mistakes: the number of bugs introduced tends to
> be proportional to the amount of code that is written. This is
> independent from the number of years of experience of the programmer.
> But the more frequent existing code is used, the more bugs are removed
> by debugging. So reusing existing code instead of writing new code will
> in practice decrease the number of bugs in the end user software in two
> ways: less code, more frequently used. (To my knowledge there is no
> evidence that following code patterns does this too)
>
> Greetings,
>
> Henk.
>
> Illustration: Amiga, OO without classes
>
> I once studied some good programming manuals about the Amiga OS
> libraries. They showed an impressive smartness and discipline in the
> combined use of structs, libraries and function pointers, but it was
> hard to grasp. Later, when i learnt OO, i concluded the deveolpers of
> the Amiga must have understood the principles of OO very well. Yet they
> used flat c for implementation.
>
> Interesting detail: The amiga 500 had a multi tasking operating system
> with a GUI in only 256 Kb rom and 880 Kb disk. Compare that to the size
> of the first version of windows 95...
>[/color]

and the amiga OS is still better that the stuff that comes from Redmond...

Michael Austin.

Manuel Lemos wrote:
[color=blue]
> The problem with traditional OOP is that as you evolve your library
> classes to make them more flexible, you keep adding code that will
> probably be use just in case.[/color]

Hi Manual,

Only if you never rebuild your library. I have rebuilt ours two times
now (that makes three in total). This means that after some years we
reuse the concepts and designs but drop the code. It still kept getting
more powerfull where it is most effective, but it it also gets stripped
from everything that is not the simpelest thing that could possibly work
for the most essential objectives. Therfore it's still only 1.1 Mb
uncompressed.
[color=blue]
> That gets worse with cascaded dependencies: classes that get loaded just
> because you used one feature that you want from one class that requires
> other classes to implement features that you do not need.[/color]

Not if you ever only include a class if you are going to call its
functions or instantiate it.
[color=blue]
> It would be better if you just could tell what features you need and a
> magic generator would generate a class that includes the aspects that
> you really will use at run time.[/color]

That would only eliminate about 5 include calls from ca 3 methods per
class. I do not think that would make a big difference it the size of my
code, nor in the number of bugs. But i must admit that i use meta data
for auto inclusion in those cases where i eliminated the code it should
be in entirely ;-)
[color=blue]
> You just describe your DAO classes and specify which
> functionality you need.[/color]

What else is programming? As i understand it you still need to specify,
that's source code too. I want less source code, i do nog have a
performance problem.
[color=blue]
>This is an actual call for Code Generation based solutions
> like Metastorage[/color]

Why would you need a code generator for that? Why not simply factor out
the code you now generate?

Sorry, i am just not ready to buy it that AOP would be just a perfomance
issue. To my understanding the case for AOP (and CF likewise) consists
of answers to the above question.

This does not mean that i am agains JIT compilers etc., they can be
great. I just don't think they should be a (meta)language issue.

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

[color=blue]
> Hello,
>
> On 07/09/2004 04:03 PM, Henk Verhoeven wrote:
>[color=green]
>> Phil Powell wrote:
>>[color=darkred]
>> > That reminds me, what is the latest consensus on AOP as opposed to OOP
>> > and is that even being considered within the PHP community?[/color]
>>
>> Personally i would rather have some more abstract or low level form of
>> implicit delegation being supported by PHP (directly without
>> precompilation).[/color]
>
>
> AOP is not different and OOP. It is just a way to make more efficient
> software (read not so bloated) by only including the Aspects that you
> really want in the software that you load at runtime.
>
> The problem with traditional OOP is that as you evolve your library
> classes to make them more flexible, you keep adding code that will
> probably be use just in case.
>
> That gets worse with cascaded dependencies: classes that get loaded just
> because you used one feature that you want from one class that requires
> other classes to implement features that you do not need.
>
> It would be better if you just could tell what features you need and a
> magic generator would generate a class that includes the aspects that
> you really will use at run time.
>
> This is the approach of Metastorage Data Access Object (DAO) classes
> generator. You just describe your DAO classes and specify which
> functionality you need. Then it just generates JE WIN code (Just Exactly
> What I Need). For instance, if you will never need to delete persistent
> objects, Metastorage will not generate delete object functions.
>
> The result is more compact software that loads faster at run time and
> saves memory. This is an actual call for Code Generation based solutions
> like Metastorage which implements a black box approach for AOP. There
> are also white box approaches to AOP based on code insertion on existing
> code.
>
> You may find more about Metastorage here:
>
> http://www.meta-language.net/metastorage.html
>
>[/color]

"Henk Verhoeven" <news@phppeanutsREMOVE-THIS.org> wrote in message
news:ccls6n$dr4$1@news2.tilbu1.nb.home.nl...[color=blue]
> Hi chung,
>
> I like your reply :-)))
>
> But OTOH i do think there is a rationale for some conformism towards
> commonly accepted standards and best practices. However, OO is not
> simply a "best practice" or so, imho it's a paradigm in the sense T.S.
> Kuhn meant in his book "Structure of scientific revolutions". Kuhn
> explained the impossability of logical or even empirical falsification
> of a paradigm and described how consensus between scientists in the end
> is descisive in the competition between paradigms. In that respect OO
> getting into the mainstream, maybe even becoming the leading paradigm,
> is the most rational measure we have of its value.
>
> Of course this does not mean that arguments are not important, and
> certainly not that discussions should stop. But it can be expected that
> progress will come from NEW paradigms, not from old, predecessor ones
> like procedural or structural programming.[/color]

I think it was in a Dilbert cartoon where someone invented a device which
would deliver a electric shock everytime the wearer utter terms like
"paradigm."

Mudge wrote:
[color=blue]
> Please, someone, tell me why OO in PHP is better than procedural.[/color]

Hey people. I found an article that answers my question:
http://www.zend.com/zend/art/oo-proc.php

Chung Leong wrote:[color=blue]
> I think it was in a Dilbert cartoon where someone invented a device which
> would deliver a electric shock everytime the wearer utter terms like
> "paradigm."
>
>[/color]
If Dilbert had taken the specs literally, he would have invented the
machine to only give the shock if someone calls an idea, theory,
ideology or belief a paradigm. But Dilbert is an experienced developer,
he obviously knew that a version that does not make that difference will
work over 99 % correct in most circomstances, and no manager will be
able to tell the difference anyway, exept maybe for it being so much
cheaper to invent. But why tell them the device has been finished ways
before schedule if you can fill that time behind your desk with writing
profitable comics?

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Henk Verhoeven <news@phppeanutsREMOVE-THIS.org> wrote in message news:<cctlup$h3s$1@news5.tilbu1.nb.home.nl>...[color=blue]
> Chung Leong wrote:[color=green]
> > I think it was in a Dilbert cartoon where someone invented a device which
> > would deliver a electric shock everytime the wearer utter terms like
> > "paradigm."
> >
> >[/color]
> If Dilbert had taken the specs literally, he would have invented the
> machine to only give the shock if someone calls an idea, theory,
> ideology or belief a paradigm. But Dilbert is an experienced developer,
> he obviously knew that a version that does not make that difference will
> work over 99 % correct in most circomstances, and no manager will be
> able to tell the difference anyway, exept maybe for it being so much
> cheaper to invent. But why tell them the device has been finished ways
> before schedule if you can fill that time behind your desk with writing
> profitable comics?
>
> Greetings,
>
> Henk Verhoeven,
> www.phpPeanuts.org.[/color]

I find it utterly frightening that you sincerely provided a complete
technical analysis of a silly one-liner. Good LORD Henk!!!!

Phil

Phil Powell wrote:[color=blue]
>
> I find it utterly frightening that you sincerely provided a complete
> technical analysis of a silly one-liner. Good LORD Henk!!!!
>
> Phil[/color]

I knew it! I DO qualify for being a Software Architect! (with capitals!)

Thanks Phil!

Hello,

On 07/09/2004 06:28 PM, Henk Verhoeven wrote:[color=blue][color=green]
> > The problem with traditional OOP is that as you evolve your library
> > classes to make them more flexible, you keep adding code that will
> > probably be use just in case.[/color]
>
> Only if you never rebuild your library. I have rebuilt ours two times
> now (that makes three in total). This means that after some years we
> reuse the concepts and designs but drop the code. It still kept getting
> more powerfull where it is most effective, but it it also gets stripped
> from everything that is not the simpelest thing that could possibly work
> for the most essential objectives. Therfore it's still only 1.1 Mb
> uncompressed.[/color]

Refactoring does not imply code shrinking. It may happen if you focus
your efforts on that.

Still that does not avoid the problem of adding features to satisfy
better your needs. More features usually means more code.

However, different projects may use a different set of features of the
same library but each one may not use all the features. If the number of
library features used by a project is small when compared to the code
that has to be loaded, you may see the library as already bloated..

[color=blue][color=green]
> > That gets worse with cascaded dependencies: classes that get loaded just
> > because you used one feature that you want from one class that requires
> > other classes to implement features that you do not need.[/color]
>
> Not if you ever only include a class if you are going to call its
> functions or instantiate it.[/color]

That does not avoid what usually happens when a project just needs a
feature of a class that uses a fraction of the code, but the whole class
and any dependencies have to be loaded because the class does not have
built-in knowledge of all the features the project needs.

[color=blue][color=green]
> > It would be better if you just could tell what features you need and a
> > magic generator would generate a class that includes the aspects that
> > you really will use at run time.[/color]
>
> That would only eliminate about 5 include calls from ca 3 methods per
> class. I do not think that would make a big difference it the size of my
> code, nor in the number of bugs. But i must admit that i use meta data
> for auto inclusion in those cases where i eliminated the code it should
> be in entirely ;-)[/color]

I think you need to see what exactly a smart generator does and the
difference that it makes. It takes hints specified by the developer
about the aspects that he needs to figure what code should be generated
and what is not necessary.

[color=blue][color=green]
> > You just describe your DAO classes and specify which
> > functionality you need.[/color]
>
> What else is programming? As i understand it you still need to specify,
> that's source code too. I want less source code, i do nog have a
> performance problem.[/color]

Sure, but since you just need to describe the model and the generator
produces the code that implements the data access class to manipulate
data according that model, rest assured that you need to write much less
code. Actually, that is the main advantage of code generation: focus
more effort on design to avoid spending too much time in implementation,
testing and debuging.

[color=blue][color=green]
> >This is an actual call for Code Generation based solutions
> > like Metastorage[/color]
>
> Why would you need a code generator for that? Why not simply factor out
> the code you now generate?[/color]

Because this is a repetitive problem that that requires too much hand
coding to customize the solution according to the model.

I could build bricks manually but if I have a machine than can produce
the bricks automatically, it will certainly be more productive.

[color=blue]
> Sorry, i am just not ready to buy it that AOP would be just a perfomance
> issue. To my understanding the case for AOP (and CF likewise) consists
> of answers to the above question.
>
> This does not mean that i am agains JIT compilers etc., they can be
> great. I just don't think they should be a (meta)language issue.[/color]

AOP and code generation are distinct matters. AOP is about the aspects
that you may want to enable or not in your application according to your
needs. It is a matter of application customization and configuration. It
may lead to more efficient and compact applications.

If you want to debug your applications you may plug a lot of code that
implements the debugging aspects that you need. But when you ship the
application, you may want to drop all the debugging plugs to make the
application as small as it may get and eventually hide aspects that you
do not want the production users to be aware.

Code generation is about automating the generation of code to implement
repetitive code eventually following design patterns. AOP does not imply
code generation, but since often you need to process and generate code
to implement certain aspects, one thing helps the other.

--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

Hello Manuel,

Manuel Lemos wrote:
(..)[color=blue]
> Sure, but since you just need to describe the model and the generator
> produces the code that implements the data access class to manipulate
> data according that model, rest assured that you need to write much less
> code. Actually, that is the main advantage of code generation: focus
> more effort on design to avoid spending too much time in implementation,
> testing and debuging.[/color]

I can use objects to describe the model and have them generate the
behavior i need directly. Code generation would take effort to build and
effort to maintain. It's called meta programming and though the concepts
that are implemented may be very abstract, its implementation can
usually be very simple. The only objective of code generation *may* be
performance, but why put time into that if performance problems (as far
as i have them) are not in the meta calls (call function by name etc.)?

The same holds for other performance optimalizations like the parser
having to parse more then is necessary: if the bottleneck is somewhere
else (or there is no performance problem at all), i better spend my
valuable time on other, more urent problems.
[color=blue]
> I could build bricks manually but if I have a machine than can produce
> the bricks automatically, it will certainly be more productive.[/color]

It will be even more efficient if you simply skip the brick entirely ;-)

The point is, you can't convince me that code generation is better then
refactoring and meta programming IN GENERAL. I have simply seen to many
unconvincing examples. You will have to come with examples or patterns
where those simply are inadequate AND explain why that inadequacy is
inherent to refactoring, OO and meta programming, otherwise i can simply
invent a solution (and if i need it, i usually will) (or tell how the
problem was soved in Smalltalk more then a decade ago* ;-) )

I have only once read an article (from trese.cs.utwente.nl) that
actually correctly identified limitations to the expressive power of OO
languages and explaind how they necessarily lead to repetition designs
and code, and i consider that as be a basis for extending a programming
language like PHP (with implicit delegation). I would like to read more
articles like that, but never found any. I am not interested in the many
examples that can be soved by better programming or are really just a
matter of performance optizations. The first are only making a case
against code generation (solving a problem that really isn't there is
not helping) and the last should i.m.h.o be addressed by the (JIT)
compiler, packager and VM without me as a developer having to know.

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

* the problem of bloat as you descibe it was solved to a degree in most
Smalltalk dialects by the introduction of class extensions: putting
part of a class' code into a different package then where the class
itself resides. There is much design humbug with respect to C++ and Java
that is really only there becuase these languages still fail to separate
structuring for code maintenance (packages) from structuring for
execution (classes and inheritance). In this light code generations
looks to me like a poor workaround for another stubbornness of language
developers failing to address problems that where already solved in what
they are trying to mimic.
[color=blue][color=green]
>>
>> Only if you never rebuild your library. I have rebuilt ours two times
>> now (that makes three in total). This means that after some years we
>> reuse the concepts and designs but drop the code. It still kept
>> getting more powerfull where it is most effective, but it it also gets
>> stripped from everything that is not the simpelest thing that could
>> possibly work for the most essential objectives. Therfore it's still
>> only 1.1 Mb uncompressed.[/color]
>
>
> Refactoring does not imply code shrinking. It may happen if you focus
> your efforts on that.
>
> Still that does not avoid the problem of adding features to satisfy
> better your needs. More features usually means more code.
>
> However, different projects may use a different set of features of the
> same library but each one may not use all the features. If the number of
> library features used by a project is small when compared to the code
> that has to be loaded, you may see the library as already bloated..
>
>
>[color=green][color=darkred]
>> > That gets worse with cascaded dependencies: classes that get loaded[/color]
>> just[color=darkred]
>> > because you used one feature that you want from one class that[/color]
>> requires[color=darkred]
>> > other classes to implement features that you do not need.[/color]
>>
>> Not if you ever only include a class if you are going to call its
>> functions or instantiate it.[/color]
>
>
> That does not avoid what usually happens when a project just needs a
> feature of a class that uses a fraction of the code, but the whole class
> and any dependencies have to be loaded because the class does not have
> built-in knowledge of all the features the project needs.
>
>[color=green][color=darkred]
>> > It would be better if you just could tell what features you need and a
>> > magic generator would generate a class that includes the aspects that
>> > you really will use at run time.[/color]
>>
>> That would only eliminate about 5 include calls from ca 3 methods per
>> class. I do not think that would make a big difference it the size of
>> my code, nor in the number of bugs. But i must admit that i use meta
>> data for auto inclusion in those cases where i eliminated the code it
>> should be in entirely ;-)[/color]
>
>
> I think you need to see what exactly a smart generator does and the
> difference that it makes. It takes hints specified by the developer
> about the aspects that he needs to figure what code should be generated
> and what is not necessary.
>
>[color=green][color=darkred]
>> > You just describe your DAO classes and specify which
>> > functionality you need.[/color]
>>
>> What else is programming? As i understand it you still need to
>> specify, that's source code too. I want less source code, i do nog
>> have a performance problem.[/color]
>
>
> Sure, but since you just need to describe the model and the generator
> produces the code that implements the data access class to manipulate
> data according that model, rest assured that you need to write much less
> code. Actually, that is the main advantage of code generation: focus
> more effort on design to avoid spending too much time in implementation,
> testing and debuging.
>
>
>[color=green][color=darkred]
>> >This is an actual call for Code Generation based solutions
>> > like Metastorage[/color]
>>
>> Why would you need a code generator for that? Why not simply factor
>> out the code you now generate?[/color]
>
>
> Because this is a repetitive problem that that requires too much hand
> coding to customize the solution according to the model.
>
> I could build bricks manually but if I have a machine than can produce
> the bricks automatically, it will certainly be more productive.
>
>[color=green]
>> Sorry, i am just not ready to buy it that AOP would be just a
>> perfomance issue. To my understanding the case for AOP (and CF
>> likewise) consists of answers to the above question.
>>
>> This does not mean that i am agains JIT compilers etc., they can be
>> great. I just don't think they should be a (meta)language issue.[/color]
>
>
> AOP and code generation are distinct matters. AOP is about the aspects
> that you may want to enable or not in your application according to your
> needs. It is a matter of application customization and configuration. It
> may lead to more efficient and compact applications.
>
> If you want to debug your applications you may plug a lot of code that
> implements the debugging aspects that you need. But when you ship the
> application, you may want to drop all the debugging plugs to make the
> application as small as it may get and eventually hide aspects that you
> do not want the production users to be aware.
>
> Code generation is about automating the generation of code to implement
> repetitive code eventually following design patterns. AOP does not imply
> code generation, but since often you need to process and generate code
> to implement certain aspects, one thing helps the other.
>[/color]

Hi...

Manuel Lemos wrote:[color=blue]
> More features usually means more code.[/color]

Funnily enough I don't find that to be true anymore. My experience has
been that the core code gets more highly factored and it shrinks as more
features are added. The incoming code about balances the core shrinkage.

The result of this is that about a third of the way through a project
you tend to hit a maximum code size. My experience of this effect has
been on three largish OO projects all with a refactoring culture.

yours, Marcus
--
Marcus Baker, marcus@lastcraft.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

Hi...

Tony Marston wrote:[color=blue]
> The paradigm (OO or Procedural) is irrelevant. It is all down to how you
> implement it.
>[/color]

Well, I used to implement in assembly language, but there is no way I
would want to go back to that if I had a choice. Procedural is the
weakest intersection of OO and functional programming. You are robbed of
polymorphism, which is the most powerful code reduction tool of all.

There are big advantages to using OO on anything over about 100 lines of
code. The main one is that you can express business problems in objects
without the mental translation needed for functional or relational
tools. By working in the language of the domain you make it more likely
that the flex points of your design will match the ones in real life.

When your requirements turn out to be wrong (they always are) the
changes you have to make will either follow the fissures you already
have or will force a change in some of your design. These changes
usually feedback straight into the business model without translation.
These insights usually result in major refactorings that really sort out
the code.

The expressiveness and the insight factor are what makes the OO dominant
paradigm in enterprise programming. It's currently the right tool for
the job.

yours, Marcus
--
Marcus Baker, marcus@lastcraft.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

"Marcus Baker" <marcus@lastcraft.com> wrote in message
news:41773BF9.50802@lastcraft.com...[color=blue]
> Hi...
>
> Tony Marston wrote:[color=green]
>> The paradigm (OO or Procedural) is irrelevant. It is all down to how you
>> implement it.
>>[/color]
>
> Well, I used to implement in assembly language, but there is no way I
> would want to go back to that if I had a choice.[/color]

You are missing my point. It is possible to use non-OOP and produce
something that shines just as it is possible to use OOP and produce someting
that stinks. It is not what you use but how you use it that counts.
[color=blue]
> Procedural is the weakest intersection of OO and functional programming.[/color]

That's your opinion. I disagree.
[color=blue]
> You are robbed of polymorphism, which is the most powerful code reduction
> tool of all.[/color]

Polymorphism is not a code reduction tool, inheritance is.

Code reduction is about having reusable modules so you don't have to keep
rewriting the same code over and over again. You can achieve this with a
class library or a function library. You do not have to use OOP to obtain
reusable code, and you do not have to use OOP to achieve polymorphism.
[color=blue]
> There are big advantages to using OO on anything over about 100 lines of
> code. The main one is that you can express business problems in objects
> without the mental translation needed for functional or relational tools.
> By working in the language of the domain you make it more likely that the
> flex points of your design will match the ones in real life.
>
> When your requirements turn out to be wrong (they always are)[/color]

Changes in requirements are down to the client, not the developer.
[color=blue]
> the changes you have to make will either follow the fissures you already
> have or will force a change in some of your design. These changes usually
> feedback straight into the business model without translation. These
> insights usually result in major refactorings that really sort out the
> code.[/color]

It does not matter whether your implementation is OO or non-OO, changes is
user requirements will affect both the design as well as the implememtation.
It is just as possible to have an OO design that is difficult to change just
as it is a non-OO design that is easy to change.
[color=blue]
> The expressiveness and the insight factor are what makes the OO dominant
> paradigm in enterprise programming. It's currently the right tool for the
> job.[/color]

It is not the right tool for every job. A good procedural programmer can
beat the pants off a bad OO programmer every time.

It is not what you use but how you use it that counts.

--
Tony Marston

http://www.tonymarston.net

Hello,

Oh, I thought this thread was over! ;-)

On 10/21/2004 01:17 AM, Marcus Baker wrote:[color=blue][color=green]
>> More features usually means more code.[/color]
>
> Funnily enough I don't find that to be true anymore. My experience has
> been that the core code gets more highly factored and it shrinks as more
> features are added. The incoming code about balances the core shrinkage.
>
> The result of this is that about a third of the way through a project
> you tend to hit a maximum code size. My experience of this effect has
> been on three largish OO projects all with a refactoring culture.[/color]

In the real world you only refactor code when you do not have nothing
better to do. If your code already works well and you are busy, usually
you just don't give priority fixing what isn't broken unless you are a
"prima donna" (ego motivation, not logic reasons) and have plenty of
free time to refactor code that already works well.

Often, refactoring code for no really important reason is
counterproductive because developers are humans and make mistakes, so
the chances are that new bugs will be added where none existed.

I am not saying that refactoring is bad, I am just saying that it should
only be done when it is absolutely necessary and more important than
other project tasks.

Anyway, this thread was about the misunderstanding of the benefits of
AOP and then how code generation can improve the overall software
quality and help implementing AOP in languages that do not support it
natively. Refactoring was only brought up because it seems that AOP and
code generation techniques are not yet well understood approaches, just
like OOP used to be in the past (for some people the benefits of OOP
continue to be misunderstood).

BTW, regarding code generation and AOP, the next version of Metastorage
will also feature the automatic generation of classes to generate
reports from an high level definition.

This is one very important feature that complements well the
capabilities of Metastorage to generate Data Access Object (DAO) classes
to do the object relational mapping.

DAO classes are not appropriate to generate reports because the design
pattern that they employ is not meant to retrieve data from arbitrary
combinations of objects.

The new report class generation support of Metastorage permits
generating reports in much less time using an object query language with
capabilities similar to SQL but using an object notation. This way
nobody has to write SQL by hand but can still benefit of its power.

--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

Hi...

Sorry for restarting this old thread. I don't touch NNTP much these days
and forgot my news reader defaults to oldest first :/.

Manuel Lemos wrote:[color=blue]
> In the real world you only refactor code when you do not have nothing
> better to do. If your code already works well and you are busy, usually
> you just don't give priority fixing what isn't broken unless you are a
> "prima donna" (ego motivation, not logic reasons) and have plenty of
> free time to refactor code that already works well.[/color]

That used to be the case, but my current project and my Sourceforge
projects have completely changed my view. We are now much more
aggressive in our refactoring and actually schedule some time for it.
Now the amount of refactoring we do can in no way be called gold plating
and there is still much that could be done, but the earlier pre-emptive
refactoring that has been done has had a real positive practical
business impact. This has absolutely nothing to do with "ego" thanks
very much (we just aren't that kind of team), we started doing it
because we were fed up with running into issues that we had already half
predicted at the time we first wrote the code. When you just run into
them later at a time when you are less familiar with that code section,
it's just so much less efficient.

So we all have background refactoring tasks. Tasks to be getting on with
when no one is around to pair or you are stuck waiting for something
else to be completed. This frees up a good 10-15% of time just for
making the code better.

Even this amount of time has really improved things. What has happened
is that the refactorings themselves point out new opportunities. It also
allows us to more accurately gauge adding new features, as we don't have
to fix anything before putting the new code in. Sometimes the most
useful thing we do is just to deprecate old junk. When someone new joins
the project there is an enormous cost getting them up to speed. At that
point extra code costs real money (pounds sterling in our case).
[color=blue]
>
> Often, refactoring code for no really important reason is
> counterproductive because developers are humans and make mistakes, so
> the chances are that new bugs will be added where none existed.[/color]

We don't get those kind of bugs anymore. Regression testing and
pairing/review pretty have pretty much eliminated them. What bugs are
left are design issues and requirements mismatch. If you are refactoring
you aren't changing much in the way of interfaces, so requirements
problems are unlikely. As for the design, well you are usually reducing
excess code and simplfying the design or sometimes just making it easier
to understand or you wouldn't be refactoring in the first place.

I have never found the introduction of new bugs an issue when refactoring.
[color=blue]
>
> I am not saying that refactoring is bad, I am just saying that it should
> only be done when it is absolutely necessary and more important than
> other project tasks.[/color]

What is "absolutely necessary"? What is important to us is easier
development day to day. Refactoring lightens the load for everybody.
Your opinion is way off here (as mine was). Allocate a refactoring time
percentage and see what happens over a longish period. It's surprisingly
beneficial.

yours, marcus
--
Marcus Baker, marcus@lastcraft.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

Hi...

Tony Marston wrote:[color=blue]
> You are missing my point. It is possible to use non-OOP and produce
> something that shines just as it is possible to use OOP and produce someting
> that stinks. It is not what you use but how you use it that counts.[/color]

Everything is possible with a computer. It is easier to do some things
one way instead of another. It is easier to build enterprise apps. with
OO than without once the skills have been learned. Simply stating that
the most incompetent OOer will be worse than the best procedural coder
only says that the bell curves overlap. We are interested in where the
mean of those bell curves are, not the end points. The OO mean is in a
more favourable position in both my experience and that of just about
every developer I know.
[color=blue]
> That's your opinion. I disagree.[/color]

Frankly I find your attitude tiresome. Just because you may post based
on opinion does not mean that everybody else does. There are plenty of
texts explaining what functional and OO languages are. Look up how both
are built from "closures" for example.
[color=blue]
> Polymorphism is not a code reduction tool, inheritance is.[/color]

I now see the reason for your thinking that OO and procedural are of
equal value. Sadly you seem to have little real world experience of OO.

By making the parameters of an operation take a wide range of types, you
save having to recode that operation. That in itself is a slight code
reduction tool. It works fully in OO because the subject of the
operation can expose methods that take on the burden of the code
variation. It works in functional languages too because in those
languages you can pass sub functions themselves around polymorphically.
It's the code variations that must be polymorhic in an extensible way.

Inheritance buys you far less code reduction by affecting only code
within a type. It also has the additional problem that it can get you
into a design mess. Inheritance hiearchies tend to be shallow precisely
because they are less necessary for factoring.
[color=blue]
> and you do not have to use OOP to achieve polymorphism.[/color]

Code example?

Even in a procedural only language you can use functional techniques too
(say by passing function names). You could use OO techniques by placing
function names inside data structures without using any OO keywords of
the language. Only, if you have to bend a procedural language that much
you are probably using the wrong language.
[color=blue]
> Changes in requirements are down to the client, not the developer.[/color]

Changes are inevitable with even the most skilled client in the world
because of market changes during the project. Coping with those changes
is very much the task of the development team. The full spec. up front
way of doing things is rightly disappearing fast.
[color=blue]
> It is just as possible to have an OO design that is difficult to change just
> as it is a non-OO design that is easy to change.[/color]

It is easier to build a design robust in the face of change if it is
built in the language of a domain. The changes are localised that way.
You missed the point (again). A non-OO solution will result in shotgun
surgery exactly because the business data will be scattered into
multiple functions.
[color=blue]
> It is not the right tool for every job. A good procedural programmer can
> beat the pants off a bad OO programmer every time.[/color]

Which is not the point (yet again). A good OO developer will beat the
good procedural developer over the long run and so end up pursuading the
procedural person to switch. I see that a lot and I don't see anyone
going back the other way.
[color=blue]
>
> It is not what you use but how you use it that counts.
>[/color]

Well, just because I can eventually cut wood with a spoon does not mean
I won't go faster with the band saw.

yours, Marcus
--
Marcus Baker, marcus@lastcraft.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

"Marcus Baker" <marcus@lastcraft.com> wrote in message
news:417D6185.5080007@lastcraft.com...[color=blue]
> Hi...
>
> Tony Marston wrote:[color=green]
>> You are missing my point. It is possible to use non-OOP and produce
>> something that shines just as it is possible to use OOP and produce
>> someting that stinks. It is not what you use but how you use it that
>> counts.[/color]
>
> Everything is possible with a computer. It is easier to do some things one
> way instead of another. It is easier to build enterprise apps. with OO
> than without once the skills have been learned.[/color]

Unfortunately too many people who teach these skills are nothing more than
cowboys and charlatans, so many end up by being taught badly.
[color=blue]
> Simply stating that the most incompetent OOer will be worse than the best
> procedural coder only says that the bell curves overlap. We are interested
> in where the mean of those bell curves are, not the end points. The OO
> mean is in a more favourable position in both my experience and that of
> just about every developer I know.
>[color=green]
>> That's your opinion. I disagree.[/color]
>
> Frankly I find your attitude tiresome. Just because you may post based on
> opinion does not mean that everybody else does. There are plenty of texts
> explaining what functional and OO languages are. Look up how both are
> built from "closures" for example.
>[color=green]
>> Polymorphism is not a code reduction tool, inheritance is.[/color]
>
> I now see the reason for your thinking that OO and procedural are of equal
> value. Sadly you seem to have little real world experience of OO.[/color]

Wrong again. My years as a procedural programmer have taught me to tell the
difference between good and bad programming. When I see some of the stuff
that OO people produce I have to reach for a sick bag. Too many of the new
programmers are taught nothing but OO, so they don't know how to tell the
difference.
[color=blue]
> By making the parameters of an operation take a wide range of types, you
> save having to recode that operation. That in itself is a slight code
> reduction tool. It works fully in OO because the subject of the operation
> can expose methods that take on the burden of the code variation. It works
> in functional languages too because in those languages you can pass sub
> functions themselves around polymorphically. It's the code variations that
> must be polymorhic in an extensible way.
>
> Inheritance buys you far less code reduction by affecting only code within
> a type. It also has the additional problem that it can get you into a
> design mess. Inheritance hiearchies tend to be shallow precisely because
> they are less necessary for factoring.[/color]

Exactly. Class hierachies which are too deep can cause problems. Procedural
languages don't have class hierachies, therefore they don't have those
problems.
[color=blue][color=green]
>> and you do not have to use OOP to achieve polymorphism.[/color]
>
> Code example?[/color]

When using a non-OO 4GL called UNIFACE I designed a 3 tier infrastructure
where the business layer was comprised of service components, one for each
business entity. Each service component had two operations, getData() and
putData(), therefore I could communicate with any business entity using just
those two operations without knowing what the actual entity was.
[color=blue]
> Even in a procedural only language you can use functional techniques too
> (say by passing function names). You could use OO techniques by placing
> function names inside data structures without using any OO keywords of the
> language. Only, if you have to bend a procedural language that much you
> are probably using the wrong language.[/color]

Then don't bend the language. Use it as it was designed to be used. If you
try to bend it and you fail, then the fault lies with you, not the language.
[color=blue][color=green]
>> Changes in requirements are down to the client, not the developer.[/color]
>
> Changes are inevitable with even the most skilled client in the world
> because of market changes during the project. Coping with those changes is
> very much the task of the development team. The full spec. up front way of
> doing things is rightly disappearing fast.
>[color=green]
>> It is just as possible to have an OO design that is difficult to change
>> just as it is a non-OO design that is easy to change.[/color]
>
> It is easier to build a design robust in the face of change if it is built
> in the language of a domain. The changes are localised that way. You
> missed the point (again). A non-OO solution will result in shotgun surgery
> exactly because the business data will be scattered into multiple
> functions.[/color]

A solution is not necessarily bad because it is procedural. A solution is
not necesarily good because it is OO.
[color=blue][color=green]
>> It is not the right tool for every job. A good procedural programmer can
>> beat the pants off a bad OO programmer every time.[/color]
>
> Which is not the point (yet again). A good OO developer will beat the good
> procedural developer over the long run and so end up pursuading the
> procedural person to switch. I see that a lot and I don't see anyone going
> back the other way.[/color]

If you know how to apply the principles of OO properly then you can achieve
better results and would not want to go back to procedural methods. But the
key word is "properly". If the principles of OO are applied improperly then
the result will be a right royal cock up.
[color=blue][color=green]
>>
>> It is not what you use but how you use it that counts.
>>[/color]
>
> Well, just because I can eventually cut wood with a spoon does not mean I
> won't go faster with the band saw.[/color]

If you ask two people to design an implement to cut wood the one with a
procedural background will design a saw. The one with the OO background will
spend so much time abstracting down to the nth degree, designing class
hierarchies, deciding between inheritance and object composition that he
will come up with something that does more than is required and which cuts
wood badly.

You will never convince me that OO is the holy grail, so don't waste your
time trying.

--
Tony Marston

http://www.tonymarston.net

Tony Marston wrote:[color=blue]
> When using a non-OO 4GL called UNIFACE I designed a 3 tier[/color]
infrastructure[color=blue]
> where the business layer was comprised of service components, one for[/color]
each[color=blue]
> business entity. Each service component had two operations, getData()[/color]
and[color=blue]
> putData(), therefore I could communicate with any business entity[/color]
using just[color=blue]
> those two operations without knowing what the actual entity was.[/color]

What you have just descibed *IS* Object Orientated programming!
Seems you appreciate OOP more than you realise! Your 'Service'
components are objects, you 'operations' are methods of those objects!

"2metre" <2metre@xxxhersham.net> wrote in message
news:clksul$p7n$1@titan.btinternet.com...[color=blue]
> Tony Marston wrote:[color=green]
> > When using a non-OO 4GL called UNIFACE I designed a 3 tier[/color]
> infrastructure[color=green]
> > where the business layer was comprised of service components, one for[/color]
> each[color=green]
> > business entity. Each service component had two operations, getData()[/color]
> and[color=green]
> > putData(), therefore I could communicate with any business entity[/color]
> using just[color=green]
> > those two operations without knowing what the actual entity was.[/color]
>
> What you have just descibed *IS* Object Orientated programming!
> Seems you appreciate OOP more than you realise! Your 'Service' components
> are objects, you 'operations' are methods of those objects![/color]

It is very similar, I agree, but the language is not Object Oriented as it
does not permit the instantiation of objects from classes. It does however
permit the creation of component instances from components. As for
inheritance, this is only one level deep - from a component template to a
component - and is not as flexible as multi-level inheritance that I use
with PHP. It also does not allow the accessing of component variables
through anything other than a parameter on an operation (function).

For a detailed comparison take a look at
http://www.tonymarston.co.uk/php-mys...jects.html#a4a.

I have to say that using that language made it easier to step into the world
of OO, but there are SOME people out there who think that my approach is
unacceptable. The arguments for and against can be found in
http://www.tonymarston.co.uk/php-mys...d-bad-oop.html

--
Tony Marston

http://www.tonymarston.net

Hi...

Tony Marston wrote:[color=blue]
> Unfortunately too many people who teach these skills are nothing more than
> cowboys and charlatans, so many end up by being taught badly.[/color]

Perhaps you could name names here? Can you give an example of a book or
reference by one of these "cowboys"? Can you point us to the correct
texts that are not cowboys?
[color=blue]
> Wrong again. My years as a procedural programmer have taught me to tell the
> difference between good and bad programming. When I see some of the stuff
> that OO people produce I have to reach for a sick bag. Too many of the new
> programmers are taught nothing but OO, so they don't know how to tell the
> difference.[/color]

And had they been taught procedural they would would all be perfect?
[color=blue]
> Exactly. Class hierachies which are too deep can cause problems. Procedural
> languages don't have class hierachies, therefore they don't have those
> problems.[/color]

Well I can crash my own car at high speed, but that's a testament to the
power of the car. I am not going to walk everywhere because I am too
scared to drive.
[color=blue]
> When using a non-OO 4GL called UNIFACE I designed a 3 tier infrastructure
> where the business layer was comprised of service components, one for each
> business entity. Each service component had two operations, getData() and
> putData(), therefore I could communicate with any business entity using just
> those two operations without knowing what the actual entity was.[/color]

A totally incomplete verbal description of two method names. How about a
code example?
[color=blue]
> Then don't bend the language. Use it as it was designed to be used. If you
> try to bend it and you fail, then the fault lies with you, not the language.[/color]

I don't, I use a language that has those features. I don't think you are
listening.
[color=blue]
> A solution is not necessarily bad because it is procedural. A solution is
> not necesarily good because it is OO.[/color]

You are not looking beyond these black and white end points.
[color=blue]
> If you know how to apply the principles of OO properly then you can achieve
> better results and would not want to go back to procedural methods. But the
> key word is "properly". If the principles of OO are applied improperly then
> the result will be a right royal cock up.[/color]

OO has a steep learning curve and that is very much the downside. It
certainly does take a year, more like two, to become fluent. If the
skills are not available, doing a mission critical project in OO is a
very bad idea and it will flounder. I would not recommend it in this case.

In the other hand, if the skills are available, or appropriate mentors
can be hired, then the OO path will win especially over the long term.
[color=blue]
> If you ask two people to design an implement to cut wood the one with a
> procedural background will design a saw. The one with the OO background will
> spend so much time abstracting down to the nth degree, designing class
> hierarchies, deciding between inheritance and object composition that he
> will come up with something that does more than is required and which cuts
> wood badly.[/color]

Nope. Just because you yourself have that trouble, or because you have
hired the wrong people, does not make the technology bad. Most OO
developers that I know would very much start with the simplest code and
add flex points only as needed. There is a "drunk on power" stage people
go through in the early stages, that's true. You get through it though.

I am a little worried about your organisation that you cannot find a
single skilled OO developer. There seems to be a sickness around, of the
"only hire juniors because they do what they are told" syndrome.
[color=blue]
>
> You will never convince me that OO is the holy grail, so don't waste your
> time trying.
>[/color]

I doubt I could teach you anything, but that's not why I am posting. I
would hate to see someone reading this newsgroup and be put off learning
by someone who happens to have had bad experiences.

yours, Marcus
--
Marcus Baker, marcus@lastcraft.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

"Marcus Baker" <marcus@lastcraft.com> wrote in message
news:41801900.9050909@lastcraft.com...[color=blue]
> Hi...
>
> Tony Marston wrote:[color=green]
>> Unfortunately too many people who teach these skills are nothing more
>> than cowboys and charlatans, so many end up by being taught badly.[/color]
>
> Perhaps you could name names here? Can you give an example of a book or
> reference by one of these "cowboys"? Can you point us to the correct texts
> that are not cowboys?[/color]

http://www.tonymarston.co.uk/php-mys...d-bad-oop.html
[color=blue][color=green]
>> Wrong again. My years as a procedural programmer have taught me to tell
>> the difference between good and bad programming. When I see some of the
>> stuff that OO people produce I have to reach for a sick bag. Too many of
>> the new programmers are taught nothing but OO, so they don't know how to
>> tell the difference.[/color]
>
> And had they been taught procedural they would would all be perfect?[/color]

No, but they would have experience of other paradigms to draw upon. Those
who nothing but OOP are very blinkered in their approach. I have used a
variety of 2nd, 3rd and 4th generation languages, and each one has had
techniques that can be carried forward into the next one as well as new and
sometimes better ways of tackling similar problems. It is because of my
non-OO background that I can recognise where and when an OO approach may
bring benefits.
[color=blue][color=green]
>> Exactly. Class hierachies which are too deep can cause problems.
>> Procedural languages don't have class hierachies, therefore they don't
>> have those problems.[/color]
>
> Well I can crash my own car at high speed, but that's a testament to the
> power of the car. I am not going to walk everywhere because I am too
> scared to drive.[/color]

A high-speed car in the hands of someone who is competent is perfectly safe,
while one that is in the hands of someone who is one sandwich short of a
picnic is a distaster waiting to happen. As I keep saying, it is not the
tool but the way that you use it that counts.
[color=blue][color=green]
>> When using a non-OO 4GL called UNIFACE I designed a 3 tier infrastructure
>> where the business layer was comprised of service components, one for
>> each business entity. Each service component had two operations,
>> getData() and putData(), therefore I could communicate with any business
>> entity using just those two operations without knowing what the actual
>> entity was.[/color]
>
> A totally incomplete verbal description of two method names. How about a
> code example?[/color]

It describes the aplication of polymorphism perfectly. A code example in
UNIFACE would be totally meaningless to a non-UNIFACE programmer.
[color=blue][color=green]
>> Then don't bend the language. Use it as it was designed to be used. If
>> you try to bend it and you fail, then the fault lies with you, not the
>> language.[/color]
>
> I don't, I use a language that has those features. I don't think you are
> listening.[/color]

You are not listening either. Once a language has been chosen for a project
then it would be totally stupid to try to write code that does not fit in
with the way that language is designed to work. So trying to get a non-OO
language to work in an OO way is a disater waitng to happen. I know because
I've seen it done - take a look at
http://www.marston-home.demon.co.uk/...html#disaster3
[color=blue][color=green]
>> A solution is not necessarily bad because it is procedural. A solution is
>> not necesarily good because it is OO.[/color]
>
> You are not looking beyond these black and white end points.[/color]

I am being realistic. It is you who are insisting that everything OO is good
(white) while everything that is not OO is bad (black). I am simply pointing
out shades of grey.
[color=blue][color=green]
>> If you know how to apply the principles of OO properly then you can
>> achieve better results and would not want to go back to procedural
>> methods. But the key word is "properly". If the principles of OO are
>> applied improperly then the result will be a right royal cock up.[/color]
>
> OO has a steep learning curve and that is very much the downside. It
> certainly does take a year, more like two, to become fluent. If the skills
> are not available, doing a mission critical project in OO is a very bad
> idea and it will flounder. I would not recommend it in this case.
>
> In the other hand, if the skills are available, or appropriate mentors can
> be hired, then the OO path will win especially over the long term.[/color]

Unfortunately this steep learning curve is too much of an investment for
some companies. And who do you decide is an appropriate mentor? If you get
taught the wrong ideas by the wrong people then all that investment in
switching to OO will take a very, very long time to bear fruit.
[color=blue][color=green]
>> If you ask two people to design an implement to cut wood the one with a
>> procedural background will design a saw. The one with the OO background
>> will spend so much time abstracting down to the nth degree, designing
>> class hierarchies, deciding between inheritance and object composition
>> that he will come up with something that does more than is required and
>> which cuts wood badly.[/color]
>
> Nope. Just because you yourself have that trouble, or because you have
> hired the wrong people, does not make the technology bad. Most OO
> developers that I know would very much start with the simplest code and
> add flex points only as needed. There is a "drunk on power" stage people
> go through in the early stages, that's true. You get through it though.
>
> I am a little worried about your organisation that you cannot find a
> single skilled OO developer. There seems to be a sickness around, of the
> "only hire juniors because they do what they are told" syndrome.[/color]

The problem still exists that too many programmers out there think they are
OO experts when all they can really achieve is to over complicate the issue
and produce bloated and expensive software.
[color=blue][color=green]
>>
>> You will never convince me that OO is the holy grail, so don't waste your
>> time trying.
>>[/color]
>
> I doubt I could teach you anything, but that's not why I am posting. I
> would hate to see someone reading this newsgroup and be put off learning
> by someone who happens to have had bad experiences.[/color]

But there are plenty of other people out there who have had similar
experiences. I am simply trying to balance the argument.

--
Tony Marston

http://www.tonymarston.net

Hi...

Tony Marston wrote:[color=blue]
> http://www.tonymarston.co.uk/php-mys...d-bad-oop.html[/color]

The part I bothered reading was a bit shallow and I don't find that tone
of article useful or worth bothering with. How about you just name a
single name and save us going around in circles again. Your fuming about
the shape example is frankly a bit silly.
[color=blue]
> No, but they would have experience of other paradigms to draw upon.[/color]

So now you have shifted the ground to people who only have one paradigm?
Hm, a slippery customer indeed. Not the argument.
[color=blue]
>It is because of my
> non-OO background that I can recognise where and when an OO approach may
> bring benefits.[/color]

Well apparently not if you are using a more limited procedural paradigm
in the very field OO excels. Also since when is knowledge of non-OO
sufficient to recognise anything at all. You need non-OO and OO
knowledge and a lot more besides, such as a good deal of case studies or
experience in both.

In fact most of this knowledge already exists, but we have a lot of
developers who have been promoted to the level of project managers
without training or homework in the field. Oh great, now I'm ranting...

From your article and the thread you pointed at it seems that you were
just about to learn the very OO skills I am talking about. If you had
given it a little longer you would have got it. A shame.
[color=blue]
> A high-speed car in the hands of someone who is competent is perfectly safe,
> while one that is in the hands of someone who is one sandwich short of a
> picnic is a distaster waiting to happen. As I keep saying, it is not the
> tool but the way that you use it that counts.[/color]

You seem to get confused easily. Once you learn to drive you get around
faster. Once you learn the basic OO skills you can more accurately map
business requirements to code. That's the point. You suffer the learning
process to progress long term.
[color=blue]
> It describes the aplication of polymorphism perfectly. A code example in
> UNIFACE would be totally meaningless to a non-UNIFACE programmer.[/color]

Pretty pointless example then. How about a PHP one given you are in a
PHP forum? Or were you just trying to confuse the issue by choosing just
about the most obscure example possible.
[color=blue][color=green]
>>I don't, I use a language that has those features. I don't think you are
>>listening.[/color]
>[/color]
[color=blue]
>Once a language has been chosen for a project
> then it would be totally stupid to try to write code that does not fit in
> with the way that language is designed to work.[/color]

I thought you you weren't listening. If I have to bend the language,
that langauge is inadequate. If I have to bend procedural into OO or
functional, then that paradigm is inadequate. Now do you see the point?
[color=blue]
>So trying to get a non-OO
> language to work in an OO way is a disater waitng to happen.[/color]

Which is not the point (yet again). If you are trying to bolt OO
features onto an OO language then you should change language. If the
legacy code is too expensive to replace then you have to live with the
limitations of procedural. Hardly desirable.
[color=blue]
> I am being realistic. It is you who are insisting that everything OO is good
> (white) while everything that is not OO is bad (black). I am simply pointing
> out shades of grey.[/color]

Nope. You can solve problems with procedural if you except that you are
working under limitations. If you have fast changing requirements the
cost to the business of procedural developers will be much higher than
simply spending on those developers with OO skills. You won't lose
anything by doing tasks in OO instead of procedural fashion though,
mostly you gain (at least in the field of e-commerce). Procedural is
just a step in the learning process.

BTW we don't emply people "one sandwich short of a picnic". Instead we
hire people who already have appropriate skills for the task or we get
people who are willing to learn. It would take a dysfunctional
organisation to do otherwise. Resorting to silly examples is rather
desperate.
[color=blue]
> Unfortunately this steep learning curve is too much of an investment for
> some companies. And who do you decide is an appropriate mentor? If you get
> taught the wrong ideas by the wrong people then all that investment in
> switching to OO will take a very, very long time to bear fruit.[/color]

It bears fruit within a year, 3 months or less with pair programming and
the like if the skills are already in house. It's quite remarkable that
you manage to find the "wrong people" with such regularity. We have had
no such problems. I haven't seen the problems you describe in any of the
last six companies I have been involved with. More importantly I hardly
hear about it at all. I think your situation is unfortunate and
exceptional if it was so disastrous. Yes, I have see people go through a
drunk on patterns stage, but it usually only lasts a few weeks.

You are either exaggerating or the projects that have scarred you have
had many more problems than merely being OO. From your link it seems you
had a design imposed on the developers without buy in. Either the skills
were not there, the design was inappropriate or personal factors got in
the way. I don't see an OO problem in there, I see a people problem.
[color=blue]
> The problem still exists that too many programmers out there think they are
> OO experts when all they can really achieve is to over complicate the issue
> and produce bloated and expensive software.[/color]

As I say, the minority in my experience. If you hire a shop of all
juniors, so there are no skills to go around, then you have a disaster
waiting for happen. That is true of any paradigm or any other skill.
That's true of programming in general. The only time you can get away
with this is to have a trial project which is not mission critical and
willingness by the team to learn from their mistakes. Management don't
see it that way, so that such pilot projects are a rarity in practice.
Whatever project your on, someone in that project should have experience
of all the technical and domain skills needed.
[color=blue]
> But there are plenty of other people out there who have had similar
> experiences. I am simply trying to balance the argument.
>[/color]

You are doing nothing of the sort, you are ranting. You could balance
the argument by saying when OO is good and when OO is bad. You could
compare it with other paradigms to show where they are more appropriate
in certain situations (functional for language processing, logic
programming for rules engines, etc, etc). You haven't.

I am quite happy to argue the pros and cons of different systems of
development. I know nothing of Uniface for instance and it would be nice
to know how that works out in practice. I would also like to know more
about your failed projects as case studies are always useful. This
industry doesn't make the efforts it should to learn from each other.

Unfortunately such one sided rants mean that I cannot trust any
information you now actually put out. You tarnish your own reputation
with polemics.

yours, Marcus
--
Marcus Baker, marcus@lastcraft.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

"Marcus Baker" <marcus@lastcraft.com> wrote in message
news:41859885.8000103@lastcraft.com...[color=blue]
> Hi...
>
> Tony Marston wrote:[color=green]
>> http://www.tonymarston.co.uk/php-mys...d-bad-oop.html[/color]
>
> The part I bothered reading was a bit shallow and I don't find that tone
> of article useful or worth bothering with. How about you just name a
> single name and save us going around in circles again.[/color]

Just step through items 1 to 17 to see people's arguments with my replies.
[color=blue]
> Your fuming about the shape example is frankly a bit silly.[/color]

No it is not. When I wanted to find out how to use OOP to build applications
to deal with common-or-garden business entities such as CUSTOMER, PRODUCT
and INVOICE I bought some books and searched the internet. What did I find?
Nothing except how to write classes dealing with shapes and producing
subclasses for 'square', 'circle' etc. There were no examples at all on how
to deal with non-graphical objects, so I had to start from a blank sheet of
paper.
[color=blue][color=green]
>> No, but they would have experience of other paradigms to draw upon.[/color]
>
> So now you have shifted the ground to people who only have one paradigm?
> Hm, a slippery customer indeed. Not the argument.[/color]

When somebody makes the statement that "OOP is better than Procedural" that
begs the question - are you talking from personal experience or merely
echoing what you have been told? I have programmed in non-OO languages for
over 20 years so I have a considerable anount of personal experience - both
good and bad - to draw upon.
[color=blue][color=green]
> >It is because of my
>> non-OO background that I can recognise where and when an OO approach may
>> bring benefits.[/color]
>
> Well apparently not if you are using a more limited procedural paradigm in
> the very field OO excels. Also since when is knowledge of non-OO
> sufficient to recognise anything at all.[/color]

Working with non-OO languages has given me the following experiences:
- How to gather user requirements.
- How to analyse user requirements and design a solution.
- How to design the application database required for that solution.
- How to write program specifications.
- How to lead a team of programmers to implement that solution.
- How to prepare test plans.
- How to write documentation.
- How to handle unit testing, system testing, and user acceptance testing.
- How to train users in the use of the application.
- How to tell when something does not work as it should.

Is there anything I have missed out?
[color=blue]
> You need non-OO and OO knowledge and a lot more besides, such as a good
> deal of case studies or experience in both.
>
> In fact most of this knowledge already exists, but we have a lot of
> developers who have been promoted to the level of project managers without
> training or homework in the field. Oh great, now I'm ranting...
>
> From your article and the thread you pointed at it seems that you were
> just about to learn the very OO skills I am talking about. If you had
> given it a little longer you would have got it. A shame.[/color]

I don't need to learn any skills from people like you. I have taught myself
and succeeded in producing something which:
(a) follows the principles of OOP.
(b) follows the KISS principle.
(c) works rather effectively.
(d) makes it easy to build new components.
(e) is easy to maintain.
[color=blue][color=green]
>> A high-speed car in the hands of someone who is competent is perfectly
>> safe, while one that is in the hands of someone who is one sandwich short
>> of a picnic is a distaster waiting to happen. As I keep saying, it is not
>> the tool but the way that you use it that counts.[/color]
>
> You seem to get confused easily. Once you learn to drive you get around
> faster. Once you learn the basic OO skills you can more accurately map
> business requirements to code. That's the point. You suffer the learning
> process to progress long term.[/color]

Unfortunately if you are taught badly you start off with an immediate
disadvantage. It is also rare for people to recognise that they have been
taught badly and seek guidance from someone who is actually competent.
[color=blue][color=green]
>> It describes the aplication of polymorphism perfectly. A code example in
>> UNIFACE would be totally meaningless to a non-UNIFACE programmer.[/color]
>
> Pretty pointless example then. How about a PHP one given you are in a PHP
> forum?[/color]

It is a valid example of how I achieved polymorphism in a non-OO language. I
cannot give an example in PHP for the simple reason that I achieved it using
OO techniques.
[color=blue]
> Or were you just trying to confuse the issue by choosing just about the
> most obscure example possible.[/color]

I was just pointing out how polymorphism can be achieved in a non-OO
language. At least one other contributor to this thread had the ability to
recognise that.
[color=blue][color=green][color=darkred]
>>>I don't, I use a language that has those features. I don't think you are
>>>listening.[/color]
>>[/color]
>[color=green]
> >Once a language has been chosen for a project
>> then it would be totally stupid to try to write code that does not fit in
>> with the way that language is designed to work.[/color]
>
> I thought you you weren't listening. If I have to bend the language, that
> langauge is inadequate. If I have to bend procedural into OO or
> functional, then that paradigm is inadequate. Now do you see the point?[/color]

You fail to see the point. The language was chosen by the client before the
project started, yet some of the project team tried to bend that language to
make it work like a different language. They failed.
[color=blue][color=green]
> >So trying to get a non-OO
>> language to work in an OO way is a disater waitng to happen.[/color]
>
> Which is not the point (yet again). If you are trying to bolt OO features
> onto an OO language then you should change language. If the legacy code is
> too expensive to replace then you have to live with the limitations of
> procedural. Hardly desirable.[/color]

It is PRECISELY the point. Once the language for the project has been chosen
you should use that language in the way it was designed to be used and not
try to force it to behave differently. The language was not object oriented,
therefore trying to force it to begave in an OO fashion was a disaster
waiting to happen. And it did.
[color=blue][color=green]
>> I am being realistic. It is you who are insisting that everything OO is
>> good (white) while everything that is not OO is bad (black). I am simply
>> pointing out shades of grey.[/color]
>
> Nope. You can solve problems with procedural if you except that you are
> working under limitations.[/color]

I agree that some things can be achieved better using OO, but I also know
that some things are best left as procedural.
[color=blue]
> If you have fast changing requirements the cost to the business of
> procedural developers will be much higher than simply spending on those
> developers with OO skills. You won't lose anything by doing tasks in OO
> instead of procedural fashion though, mostly you gain (at least in the
> field of e-commerce). Procedural is just a step in the learning process.
>
> BTW we don't emply people "one sandwich short of a picnic". Instead we
> hire people who already have appropriate skills for the task or we get
> people who are willing to learn. It would take a dysfunctional
> organisation to do otherwise. Resorting to silly examples is rather
> desperate.[/color]

Judging by the 17 criticisms contained in my article
http://www.tonymarston.co.uk/php-mys...d-bad-oop.html there are plenty of
people out there who are being taught a load of rubbish. If your programmers
cannot tell the difference between rubbish and righteous then you have a
problem but are unable (or unwilling) to see it.
[color=blue][color=green]
>> Unfortunately this steep learning curve is too much of an investment for
>> some companies. And who do you decide is an appropriate mentor? If you
>> get taught the wrong ideas by the wrong people then all that investment
>> in switching to OO will take a very, very long time to bear fruit.[/color]
>
> It bears fruit within a year, 3 months or less with pair programming and
> the like if the skills are already in house. It's quite remarkable that
> you manage to find the "wrong people" with such regularity. We have had no
> such problems.[/color]

That is probably because you do not think there is such a thing as "bad"
OOP, therefore you are willing to accept any old rubbish.
[color=blue]
> I haven't seen the problems you describe in any of the last six companies
> I have been involved with[/color]

Then you haven't lived. Either that or you don't have the ability to
recognise rubbish when you see it.
[color=blue]
>. More importantly I hardly hear about it at all. I think your situation is
>unfortunate and exceptional if it was so disastrous. Yes, I have see people
>go through a drunk on patterns stage, but it usually only lasts a few
>weeks.
>
> You are either exaggerating or the projects that have scarred you have had
> many more problems than merely being OO. From your link it seems you had a
> design imposed on the developers without buy in.[/color]

No. Only the language was fixed from the start. All the application
designers had to do was come up with something which could be implememnted
in that language. They failed disastrously for reasons already mentioned.
[color=blue]
> Either the skills were not there, the design was inappropriate or personal
> factors got in the way. I don't see an OO problem in there, I see a people
> problem.[/color]

Exactly. There was nothing wrong with the language, it was the people were
incompetent.
[color=blue][color=green]
>> The problem still exists that too many programmers out there think they
>> are OO experts when all they can really achieve is to over complicate the
>> issue and produce bloated and expensive software.[/color]
>
> As I say, the minority in my experience. If you hire a shop of all
> juniors, so there are no skills to go around, then you have a disaster
> waiting for happen. That is true of any paradigm or any other skill.
> That's true of programming in general. The only time you can get away with
> this is to have a trial project which is not mission critical and
> willingness by the team to learn from their mistakes. Management don't see
> it that way, so that such pilot projects are a rarity in practice.
> Whatever project your on, someone in that project should have experience
> of all the technical and domain skills needed.[/color]

At last there is something we agree on.
[color=blue][color=green]
>> But there are plenty of other people out there who have had similar
>> experiences. I am simply trying to balance the argument.
>>[/color]
>
> You are doing nothing of the sort, you are ranting.[/color]

I am not ranting, I am simply coming up with arguments which counter the
statements you are making. You seem to dislike the fact that I have the
audacity to challenge the statement that everything OO is perfect.
[color=blue]
> You could balance the argument by saying when OO is good and when OO is
> bad. You could compare it with other paradigms to show where they are more
> appropriate in certain situations (functional for language processing,
> logic programming for rules engines, etc, etc). You haven't.[/color]

If you want a comparison between OO and procedural then take a look at
http://www.geocities.com/tablizer/oopbad.htm
[color=blue]
> I am quite happy to argue the pros and cons of different systems of
> development. I know nothing of Uniface for instance and it would be nice
> to know how that works out in practice. I would also like to know more
> about your failed projects as case studies are always useful.[/color]

Then take a look at
http://www.marston-home.demon.co.uk/...disasters.html
[color=blue]
> This industry doesn't make the efforts it should to learn from each other.
>
> Unfortunately such one sided rants mean that I cannot trust any
> information you now actually put out. You tarnish your own reputation with
> polemics.[/color]

I am not ranting, I am simply disagreeing with you. I will keep disagreeing
with you until hell freezes over.

--
Tony Marston

http://www.tonymarston.net

OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

re: OO in PHP

Similar PHP bytes

/bytes/development

/bytes/it

/bytes/about