Object Oriented PHP

[Water Cooler v2]

I am new to PHP, just one day new. But I am otherwise a seasoned
programmer on many other languages like C, VB 6, C#, VB.NET, Win32
platform and have some tiny bit experience in MFC, C++, Python.

All the tutorials I read so far about PHP contain procedural examples.
I haven't yet come accross a tutorial on the object oriented PHP. Could
someone point me to one?

[Richard Levasseur]

Henk Verhoeven wrote:

IMHO private declarations are too rigid and therfore decrease
reusability. I agree that it can be very usefull to know the intentions
of the developer of some code one is evaluating to call or some member
variable one is avaluating to access. But every now and then there are
good reasons to do it anyway, even if it was intended to be private. For
example lazy initialization and default reasoning both are often
implemented using direct access to member variables. Another example is
using a visitor to implement persistency.

Now maybe you would say that i should change these member variables to
protected or public. There are two problems with this:
1. It may not be my own code. Then if i get an upgrade of this code,
these member variables will once again be private, unless i re-apply my
changes. This is uneccessary overhead.
2. By changing the private declaration the intension of the other
developer gets lost. Now i could put a comment in that it was intended
to be private, but in that case: why not put the @private marker in the
comment in the first place?

The fundamental point is: With these private and protected declarations
you get stuck with the uneccessarily limitations introduced by the
author. Object-orientation can lead to more reusability then
conventional parameterized code exactly because the code can be
overridden and extended in ways the original author did not provide for.
private and protected declarations are a step backwards that is only
reasonable if you assume that future developers that will maintain or
reuse your code will ignore your intentions becuase they are fools. If
this is the case, i think you should tell your boss that you are
limiting the reusability of your code because you are aniticipating him
to hire fools and let them work on/with your code ;-)

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Its nice to see someone share this opinion (mostly). I agree that
private declarations are a hinderance more often than not. If I'm
going through the trouble of heavily extending a class, I will more
than likely need or want access to the member variables for ease of use
and efficency - and besides, you should be allowed to hack away at
things if you really want to; I think extending a class is a decent
enough prequisite that you're aware of whats going on.

One bad practice based on good intentions is code reuse when the
underlying implementation will pose a problem (ie, it uses a linear
search but you need something faster). Its a good reason to use
protected more often than private. Unfortunately, during my entire
education, I've never had a teacher mention protected other than in
passing, let alone encourage its use.

I have to disagree with not having public, though, it helps enforce
proper use of the class and prevent hack n' slash methods which are so
common in web development. You can encourage discipline and practice
all you want, but mistakes and disregard happens. Its safer to require
them to do it a certain way. Also, if you are using 3rd party packages
from pear or whatnot and they modify the underlying implementation,
then your code is broken or highly suspect. Getter and setter methods
can return a reference/pointer to the original data if they need to
access it directly, and they can have a ball with it then.

What would be nice is a mechanism for overriding protection by casting
or something. (unprotected) $this->data. Sorta like friend but not
requiring the declaration in the original source. I'm of the opinion
that if you're willing to cast something, then you're aware of the
implications it has and should be allowed to.

I think a distinction should be made between maintaining code and
reusing code. Maintaining means you're going to change it, reusing
means you're going to use whats already there, without modifying it.
If you're maintaining it, then yes, you should definately know what the
intentions are; you're probably going to be modifying the source in the
future.

(Aside: Chances are you're going to maintain some code and think 'Man,
what a fool.' Meanwhile, 'This guy's an idiot' is being thought by
your replace back at your old job. Just say no to Programmer Hubris.)

However, reusing code should not require an understanding on why the
author did what. Thats part of the purpose of OOP. So, HTML_Table
changed from using a complete associative array to a sparse linked list
matrix. Do I really care? I shouldn't have to.

Woo, my caffine rush just kicked in. I'm going to get some work done.

[Jerry Stuckle]

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:7f******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:tM******************************@comcast.c om...
Tony Marston wrote:
>"Jerry Stuckle" <js*******@attglobal.net> wrote in message
>news:ce******************************@comcast .com...
>

<snip>

>OO is about encapsulation, polymorphism and inheritance. Message passing
>is incidental.
>
>
>
>
>>And YOU are the one "bastardizing" OO. Your sloppy approach to
>>programming is just what *real* OO is designed to eliminate. And it
>>makes the coding much more maintainable, expandable and modifiable.
>
>
>Not the way some people use OO. They deliberately make it more
>complicated than it need be, while I keep it as simple as possible.
>

And that is where you are 100% wrong. Message passing is an integral
part of both object-based and object-oriented languages.

One bit of wisdom, Tony. Tis better to remain silent and have everyone
thing you might be a fool than to open your mouth and remove all doubt.

In the OO world you have removed all doubt.
The three principles of OO are encapsulation, polymorphism and
inheritance. Message passing does not appear in that list, so it is a
minor detail.

And that's where you are totally wrong.

Excuse me? After performing a google search on OOP all I see quoted time
after time are the three basic principles - encapsulation, inheritance and
polymorphism - so how could I possibly be wrong?

Maybe if you check some sites which know what they're talking about - instead of
your own. Try some like:

http://www.fincher.org/tips/General/...edDesign.shtml
http://en.wikipedia.org/wiki/Object-...ed_programming
http://www.awprofessional.com/bookst...824191&redir=1
http://www.objectfaq.com/oofaq2/body/basics.htm

Just for starters.

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

[Jerry Stuckle]

Tony Marston wrote:

And the opinion of other experts in the field - such as the ones I
mentioned before.

Even experts disagree on what is or is not the *right* way in OO, so all I
am doing is agreeing with those experts who disagree with your your
favourite experts.

But NONE of the experts disagree on message passing. Check out what Booch,
Rumbaugh or Iverson have to say, for instance. Especially Booch - the founder
of OO techniques.

Your implementation violates some of the basic reasons for even having OO!
And no, I don't believe MY way is the only way. But I believe the experts
in the field know a hell of a lot more about it than you do.

I disagree. I am using the three basic principles of OO, as documented, to
achieve a higher level of reuse than I could by using non-OO techniques.

And you're missing the fourth principle.

I suspect you've had no real-world OO experience. Large, complex projects
OO is designed to make easier. All of your experience is probably simple
PHP pages you do yourself with no collaboration.

At least I have not been taught by people who don't know what they're
talking about.

So obviously you have no real world experience.

Your attitude would never survive in a the large scale projects I've been
involved in (100+ programmers, 2 years+ time). But then it wouldn't
survive the smaller projects I've been involved in, either - (i.e. three
programmers for two months).

The size of project is irrelevant. The OOP principles are the same
regardless of the size of project. The only project I have ever been
associated with which failed disastrously was one where the system
architects got carried away with their fancy ideas of how OOP should be
implemented and produced something that was so inefficient and unproductive
that the client cancelled the entire project as soon as the first live
programs were produced. It was THEIR attitude that was wrong, not mine.

If you had worked on something other than a 50 LOC web site you'd know that is
complete horse shit.

Just because some system architects didn't know what they were doing doesn't
mean OO is bad. It means only that they had no idea what they were doing.

For the record - since starting with OO in 1988, I've been involved in a number
of projects - small to large. And every project where people knew what they
were doing was successful.

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

[Jerry Stuckle]

Henk Verhoeven wrote:

Jerry Stuckle wrote:

> Actually, things like private declarations are very important.

IMHO private declarations are too rigid and therfore decrease
reusability. I agree that it can be very usefull to know the intentions
of the developer of some code one is evaluating to call or some member
variable one is avaluating to access. But every now and then there are
good reasons to do it anyway, even if it was intended to be private. For
example lazy initialization and default reasoning both are often
implemented using direct access to member variables. Another example is
using a visitor to implement persistency.

Now maybe you would say that i should change these member variables to
protected or public. There are two problems with this:
1. It may not be my own code. Then if i get an upgrade of this code,
these member variables will once again be private, unless i re-apply my
changes. This is uneccessary overhead.
2. By changing the private declaration the intension of the other
developer gets lost. Now i could put a comment in that it was intended
to be private, but in that case: why not put the @private marker in the
comment in the first place?

The fundamental point is: With these private and protected declarations
you get stuck with the uneccessarily limitations introduced by the
author. Object-orientation can lead to more reusability then
conventional parameterized code exactly because the code can be
overridden and extended in ways the original author did not provide for.
private and protected declarations are a step backwards that is only
reasonable if you assume that future developers that will maintain or
reuse your code will ignore your intentions becuase they are fools. If
this is the case, i think you should tell your boss that you are
limiting the reusability of your code because you are aniticipating him
to hire fools and let them work on/with your code ;-)

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Henk,

Private declarations are key to OO programming.

One of the basic tenets of OO programming is that you don't know the internals
of the object you're operating on (encapsulation). You can then change the
internals of that object - and not affect any code depending on that object (as
long as you don't change the interface - the message passing). Contrast to
public variables - if you find you need to change one, it's hard telling how
many places you have to change it in the code.

For instance. Lets say you have a variable in your class containing a name,
which you access directly throughout your code. Now suddenly you find you need
to keep that as first name and last name - instead of just name. How many
places are you going to have to change in your code?

Contrast this with a GetName() function, which in the first case returns the
name field. When you change the code to have first_name and last_name, your
GetName() function just returns the concatenated fields (with a space between).
You have to make no changes in the rest of your code.

Second example. You have a Person class with a name. You reference it
directly. But now you find you need to split the class - you need class
Employee and class Contractor. Both can be derived from Person - but now
Employee doesn't have a Name. That's in the parent class Person. But while you
can't access Name in Employee, you can access GetName because that has been
inherited from Person.

Last example. You have a Date field in your class in the format of MM/DD/YYYY
(U.S. format). Someplace in your code you suddenly get "this is garbage" in the
field. Where did it come from? If the variable is private, a change to an
invalid value can be intercepted *before* the value is stored, and an error
message produced. Otherwise you may be hundreds of thousands of LOC later
before finding the invalid value.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Te******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:7f******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:tM******************************@comcast. com...
>Tony Marston wrote:
>
>
>>"Jerry Stuckle" <js*******@attglobal.net> wrote in message
>>news:ce******************************@comcas t.com...
>>

<snip>

>>OO is about encapsulation, polymorphism and inheritance. Message
>>passing is incidental.
>>
>>
>>>And YOU are the one "bastardizing" OO. Your sloppy approach to
>>>programming is just what *real* OO is designed to eliminate. And it
>>>makes the coding much more maintainable, expandable and modifiable.
>>
>>
>>Not the way some people use OO. They deliberately make it more
>>complicated than it need be, while I keep it as simple as possible.
>>
>
>And that is where you are 100% wrong. Message passing is an integral
>part of both object-based and object-oriented languages.
>
>One bit of wisdom, Tony. Tis better to remain silent and have everyone
>thing you might be a fool than to open your mouth and remove all doubt.
>
>In the OO world you have removed all doubt.
The three principles of OO are encapsulation, polymorphism and
inheritance. Message passing does not appear in that list, so it is a
minor detail.
And that's where you are totally wrong.

Excuse me? After performing a google search on OOP all I see quoted time
after time are the three basic principles - encapsulation, inheritance
and polymorphism - so how could I possibly be wrong?

Maybe if you check some sites which know what they're talking about -
instead of your own. Try some like:

http://www.fincher.org/tips/General/...edDesign.shtml
http://en.wikipedia.org/wiki/Object-...ed_programming
http://www.awprofessional.com/bookst...824191&redir=1
http://www.objectfaq.com/oofaq2/body/basics.htm

Just for starters.

I got my information from these sites:

http://c2.com/cgi/wiki?ObjectOriented
http://c2.com/cgi/wiki?PolymorphismE...ionInheritance
http://en.wikipedia.org/wiki/Object-...ed_programming
http://www.phpbuilder.com/columns/luis20000420.php3

All I see about message passing is that it is how one object communicates
with another. This is a trivial detail compared with encapsulation,
inheritance and polymorphism. Even non-OO languages can pass messages, so
what's so important about it?

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Cb******************************@comcast.com. ..

Tony Marston wrote:

And the opinion of other experts in the field - such as the ones I
mentioned before.

Even experts disagree on what is or is not the *right* way in OO, so all
I am doing is agreeing with those experts who disagree with your your
favourite experts.

But NONE of the experts disagree on message passing. Check out what
Booch, Rumbaugh or Iverson have to say, for instance. Especially Booch -
the founder of OO techniques.

Message passing exists in non-OO languages, so it not something whch is
unique to OO.

Your implementation violates some of the basic reasons for even having
OO! And no, I don't believe MY way is the only way. But I believe the
experts in the field know a hell of a lot more about it than you do.

I disagree. I am using the three basic principles of OO, as documented,
to achieve a higher level of reuse than I could by using non-OO
techniques.

And you're missing the fourth principle.

Message passing is not unique to OO, and is not one of the fundamental
principles. It is simply the way that one object communicates with another.

I suspect you've had no real-world OO experience. Large, complex
projects OO is designed to make easier. All of your experience is
probably simple PHP pages you do yourself with no collaboration.

At least I have not been taught by people who don't know what they're
talking about.

So obviously you have no real world experience.

Your attitude would never survive in a the large scale projects I've been
involved in (100+ programmers, 2 years+ time). But then it wouldn't
survive the smaller projects I've been involved in, either - (i.e. three
programmers for two months).

The size of project is irrelevant. The OOP principles are the same
regardless of the size of project. The only project I have ever been
associated with which failed disastrously was one where the system
architects got carried away with their fancy ideas of how OOP should be
implemented and produced something that was so inefficient and
unproductive that the client cancelled the entire project as soon as the
first live programs were produced. It was THEIR attitude that was wrong,
not mine.

If you had worked on something other than a 50 LOC web site you'd know
that is complete horse shit.

Excuse me? I have produced administrative web applications with over 500
components, so that puts me way beyond the 50 LOC web site.
Just because some system architects didn't know what they were doing
doesn't mean OO is bad. It means only that they had no idea what they
were doing.
But they were folowing allthe rules, so how could they be wrong?
For the record - since starting with OO in 1988, I've been involved in a
number of projects - small to large. And every project where people knew
what they were doing was successful.

If your techniques produce something that works, then you are obviously
doing something right. It is only when the software does not work that you
can say that the techniques were wrong. My techniques work, therefore you
have no cause to say that the are wrong.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Ir******************************@comcast.com. ..

Henk Verhoeven wrote:

Jerry Stuckle wrote:

> Actually, things like private declarations are very important.
IMHO private declarations are too rigid and therfore decrease
reusability. I agree that it can be very usefull to know the intentions
of the developer of some code one is evaluating to call or some member
variable one is avaluating to access. But every now and then there are
good reasons to do it anyway, even if it was intended to be private. For
example lazy initialization and default reasoning both are often
implemented using direct access to member variables. Another example is
using a visitor to implement persistency.

Now maybe you would say that i should change these member variables to
protected or public. There are two problems with this:
1. It may not be my own code. Then if i get an upgrade of this code,
these member variables will once again be private, unless i re-apply my
changes. This is uneccessary overhead.
2. By changing the private declaration the intension of the other
developer gets lost. Now i could put a comment in that it was intended to
be private, but in that case: why not put the @private marker in the
comment in the first place?

The fundamental point is: With these private and protected declarations
you get stuck with the uneccessarily limitations introduced by the
author. Object-orientation can lead to more reusability then conventional
parameterized code exactly because the code can be overridden and
extended in ways the original author did not provide for. private and
protected declarations are a step backwards that is only reasonable if
you assume that future developers that will maintain or reuse your code
will ignore your intentions becuase they are fools. If this is the case,
i think you should tell your boss that you are limiting the reusability
of your code because you are aniticipating him to hire fools and let them
work on/with your code ;-)

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Henk,

Private declarations are key to OO programming.

No they are not. Encapsulation is not the same as data hiding. Please refer
to:
http://www.javaworld.com/javaworld/j...psulation.html
http://www.itmweb.com/essay550.htm

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
One of the basic tenets of OO programming is that you don't know the
internals of the object you're operating on (encapsulation). You can then
change the internals of that object - and not affect any code depending on
that object (as long as you don't change the interface - the message
passing). Contrast to public variables - if you find you need to change
one, it's hard telling how many places you have to change it in the code.

For instance. Lets say you have a variable in your class containing a
name, which you access directly throughout your code. Now suddenly you
find you need to keep that as first name and last name - instead of just
name. How many places are you going to have to change in your code?

Contrast this with a GetName() function, which in the first case returns
the name field. When you change the code to have first_name and
last_name, your GetName() function just returns the concatenated fields
(with a space between). You have to make no changes in the rest of your
code.

Second example. You have a Person class with a name. You reference it
directly. But now you find you need to split the class - you need class
Employee and class Contractor. Both can be derived from Person - but now
Employee doesn't have a Name. That's in the parent class Person. But
while you can't access Name in Employee, you can access GetName because
that has been inherited from Person.

Last example. You have a Date field in your class in the format of
MM/DD/YYYY (U.S. format). Someplace in your code you suddenly get "this
is garbage" in the field. Where did it come from? If the variable is
private, a change to an invalid value can be intercepted *before* the
value is stored, and an error message produced. Otherwise you may be
hundreds of thousands of LOC later before finding the invalid value.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Te******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:7f******************************@comcast.c om...
Tony Marston wrote:
>"Jerry Stuckle" <js*******@attglobal.net> wrote in message
>news:tM******************************@comcast .com...
>
>
>
>>Tony Marston wrote:
>>
>>
>>
>>>"Jerry Stuckle" <js*******@attglobal.net> wrote in message
>>>news:ce******************************@comca st.com...
>>>
>
><snip>
>
>>>OO is about encapsulation, polymorphism and inheritance. Message
>>>passing is incidental.
>>>
>>>
>>>
>>>>And YOU are the one "bastardizing" OO. Your sloppy approach to
>>>>programming is just what *real* OO is designed to eliminate. And it
>>>>makes the coding much more maintainable, expandable and modifiable.
>>>
>>>
>>>Not the way some people use OO. They deliberately make it more
>>>complicated than it need be, while I keep it as simple as possible.
>>>
>>
>>And that is where you are 100% wrong. Message passing is an integral
>>part of both object-based and object-oriented languages.
>>
>>One bit of wisdom, Tony. Tis better to remain silent and have everyone
>>thing you might be a fool than to open your mouth and remove all doubt.
>>
>>In the OO world you have removed all doubt.
>
>
>The three principles of OO are encapsulation, polymorphism and
>inheritance. Message passing does not appear in that list, so it is a
>minor detail.
>

And that's where you are totally wrong.
Excuse me? After performing a google search on OOP all I see quoted time
after time are the three basic principles - encapsulation, inheritance
and polymorphism - so how could I possibly be wrong?

Maybe if you check some sites which know what they're talking about -
instead of your own. Try some like:

http://www.fincher.org/tips/General/...edDesign.shtml
http://en.wikipedia.org/wiki/Object-...ed_programming
http://www.awprofessional.com/bookst...824191&redir=1
http://www.objectfaq.com/oofaq2/body/basics.htm

Just for starters.

I got my information from these sites:

http://c2.com/cgi/wiki?ObjectOriented
http://c2.com/cgi/wiki?PolymorphismE...ionInheritance
http://en.wikipedia.org/wiki/Object-...ed_programming
http://www.phpbuilder.com/columns/luis20000420.php3

All I see about message passing is that it is how one object communicates
with another. This is a trivial detail compared with encapsulation,
inheritance and polymorphism. Even non-OO languages can pass messages, so
what's so important about it?

Gee, and wiki's are the Last Word? ROFLMAO! Try some real experts - like
Booch, Iverson and Rumbaugh, for instance. These guys have been recognized as
experts throughout the world for upwards of 20 years - instead of some guy who
posted in a wiki.

However, wikipedia (which I also mentioned because it might meet your level of
intelligence), says under "Fundamental Concepts":

"Method (also known as message) — how code can use an object of some class. A
method is a form of subroutine operating on a single object. Methods may be
divided into queries returning the current state and commands changing it: a Dog
could have a query Age to say how old it is, and command chase (Rabbit target)
to start it chasing a rabbit. A method may also do both, but some authorities
(e.g. Bertrand Meyer) recommend they be kept separate. Sometimes access to the
data of an object is restricted to the methods of its class."

It is important because that's how you communicate with objects. It's the
interface, which is public, instead of the implementation, which is private.

But if you understood OO as well as you claim you would understand that.

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

[Jerry Stuckle]

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Cb******************************@comcast.com. ..

Tony Marston wrote:

And the opinion of other experts in the field - such as the ones I
mentioned before.
Even experts disagree on what is or is not the *right* way in OO, so all
I am doing is agreeing with those experts who disagree with your your
favourite experts.

But NONE of the experts disagree on message passing. Check out what
Booch, Rumbaugh or Iverson have to say, for instance. Especially Booch -
the founder of OO techniques.

Message passing exists in non-OO languages, so it not something whch is
unique to OO.

I never said it was unique to OO. Variables exist in non-OO languages also.
The difference is that message passing is an inherent requirement in OO
languages, where it isn't in non-OO languages. You can, for instance, write a
complete program in C without a function call other than main(). Or in VB with
no subroutines, etc.

It's not possible in an OO program.

Your implementation violates some of the basic reasons for even having
OO! And no, I don't believe MY way is the only way. But I believe the
experts in the field know a hell of a lot more about it than you do.
I disagree. I am using the three basic principles of OO, as documented,
to achieve a higher level of reuse than I could by using non-OO
techniques.

And you're missing the fourth principle.

Message passing is not unique to OO, and is not one of the fundamental
principles. It is simply the way that one object communicates with another.

And without it objects cannot communicate, so you have no program.

I suspect you've had no real-world OO experience. Large, complex
projects OO is designed to make easier. All of your experience is
probably simple PHP pages you do yourself with no collaboration.
At least I have not been taught by people who don't know what they're
talking about.

So obviously you have no real world experience.

Your attitude would never survive in a the large scale projects I've been
involved in (100+ programmers, 2 years+ time). But then it wouldn't
survive the smaller projects I've been involved in, either - (i.e. three
programmers for two months).
The size of project is irrelevant. The OOP principles are the same
regardless of the size of project. The only project I have ever been
associated with which failed disastrously was one where the system
architects got carried away with their fancy ideas of how OOP should be
implemented and produced something that was so inefficient and
unproductive that the client cancelled the entire project as soon as the
first live programs were produced. It was THEIR attitude that was wrong,
not mine.

If you had worked on something other than a 50 LOC web site you'd know
that is complete horse shit.

Excuse me? I have produced administrative web applications with over 500
components, so that puts me way beyond the 50 LOC web site.

"Administrative web applications"? ROFLMAO! Try a real program. > 1M LOC,
100+ programmers working for over 2 years. Or even something with 10K LOC - all
in one file, not a bunch of separate web pages.

I'll bet none of your "web programs" has more than 500 LOC on a single page.

Just because some system architects didn't know what they were doing
doesn't mean OO is bad. It means only that they had no idea what they
were doing.

But they were folowing allthe rules, so how could they be wrong?

You don't read well, do you. Just because some system architects didn't know
what they were doing doesn't mean that OO is bad. It means only that they had
no idea what they were doing.

For the record - since starting with OO in 1988, I've been involved in a
number of projects - small to large. And every project where people knew
what they were doing was successful.

If your techniques produce something that works, then you are obviously
doing something right. It is only when the software does not work that you
can say that the techniques were wrong. My techniques work, therefore you
have no cause to say that the are wrong.

Wrong, wrong, wrong. And unfortunately the attitude of too many "programmers"
like you who are "developing" web pages. You can get a lot of things to work.
That doesn't mean they are right. And you're "justification" has too many holes
to count.

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

[Jerry Stuckle]

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Ir******************************@comcast.com. ..

Henk Verhoeven wrote:

Jerry Stuckle wrote:
> Actually, things like private declarations are very important.

IMHO private declarations are too rigid and therfore decrease
reusability. I agree that it can be very usefull to know the intentions
of the developer of some code one is evaluating to call or some member
variable one is avaluating to access. But every now and then there are
good reasons to do it anyway, even if it was intended to be private. For
example lazy initialization and default reasoning both are often
implemented using direct access to member variables. Another example is
using a visitor to implement persistency.

Now maybe you would say that i should change these member variables to
protected or public. There are two problems with this:
1. It may not be my own code. Then if i get an upgrade of this code,
these member variables will once again be private, unless i re-apply my
changes. This is uneccessary overhead.
2. By changing the private declaration the intension of the other
developer gets lost. Now i could put a comment in that it was intended to
be private, but in that case: why not put the @private marker in the
comment in the first place?

The fundamental point is: With these private and protected declarations
you get stuck with the uneccessarily limitations introduced by the
author. Object-orientation can lead to more reusability then conventional
parameterized code exactly because the code can be overridden and
extended in ways the original author did not provide for. private and
protected declarations are a step backwards that is only reasonable if
you assume that future developers that will maintain or reuse your code
will ignore your intentions becuase they are fools. If this is the case,
i think you should tell your boss that you are limiting the reusability
of your code because you are aniticipating him to hire fools and let them
work on/with your code ;-)

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Henk,

Private declarations are key to OO programming.

No they are not. Encapsulation is not the same as data hiding. Please refer
to:
http://www.javaworld.com/javaworld/j...psulation.html
http://www.itmweb.com/essay550.htm

Give it up, Tony. You obviously can't even understand the information you
reference.

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

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:oM******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Ir******************************@comcast.com. ..

Henk Verhoeven wrote:

Jerry Stuckle wrote:
> Actually, things like private declarations are very important.

IMHO private declarations are too rigid and therfore decrease
reusability. I agree that it can be very usefull to know the intentions
of the developer of some code one is evaluating to call or some member
variable one is avaluating to access. But every now and then there are
good reasons to do it anyway, even if it was intended to be private. For
example lazy initialization and default reasoning both are often
implemented using direct access to member variables. Another example is
using a visitor to implement persistency.

Now maybe you would say that i should change these member variables to
protected or public. There are two problems with this:
1. It may not be my own code. Then if i get an upgrade of this code,
these member variables will once again be private, unless i re-apply my
changes. This is uneccessary overhead.
2. By changing the private declaration the intension of the other
developer gets lost. Now i could put a comment in that it was intended
to be private, but in that case: why not put the @private marker in the
comment in the first place?

The fundamental point is: With these private and protected declarations
you get stuck with the uneccessarily limitations introduced by the
author. Object-orientation can lead to more reusability then
conventional parameterized code exactly because the code can be
overridden and extended in ways the original author did not provide for.
private and protected declarations are a step backwards that is only
reasonable if you assume that future developers that will maintain or
reuse your code will ignore your intentions becuase they are fools. If
this is the case, i think you should tell your boss that you are
limiting the reusability of your code because you are aniticipating him
to hire fools and let them work on/with your code ;-)

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Henk,

Private declarations are key to OO programming.

No they are not. Encapsulation is not the same as data hiding. Please
refer to:
http://www.javaworld.com/javaworld/j...psulation.html
http://www.itmweb.com/essay550.htm

Give it up, Tony. You obviously can't even understand the information you
reference.

No, I won't give it up. Both those articles clearly state that private
declarations (data hiding) is *not* one of the key concepts of OO.
Encapsulation is about *implementation* hiding, not information* hiding.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:T4******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Cb******************************@comcast.com. ..

Tony Marston wrote:

>And the opinion of other experts in the field - such as the ones I
>mentioned before.
Even experts disagree on what is or is not the *right* way in OO, so all
I am doing is agreeing with those experts who disagree with your your
favourite experts.
But NONE of the experts disagree on message passing. Check out what
Booch, Rumbaugh or Iverson have to say, for instance. Especially Booch -
the founder of OO techniques.

Message passing exists in non-OO languages, so it not something whch is
unique to OO.

I never said it was unique to OO. Variables exist in non-OO languages
also. The difference is that message passing is an inherent requirement in
OO languages, where it isn't in non-OO languages.

The mere fact that you call one object from another automatically means that
you have messaging. There is no special technique nvolved. It is just the
same as calling a non-OO function, just that you hae to specify both the
oject and the method.
You can, for instance, write a complete program in C without a function
call other than main(). Or in VB with no subroutines, etc.

It's not possible in an OO program.

>Your implementation violates some of the basic reasons for even having
>OO! And no, I don't believe MY way is the only way. But I believe the
>experts in the field know a hell of a lot more about it than you do.
I disagree. I am using the three basic principles of OO, as documented,
to achieve a higher level of reuse than I could by using non-OO
techniques.
And you're missing the fourth principle.

Message passing is not unique to OO, and is not one of the fundamental
principles. It is simply the way that one object communicates with
another.

And without it objects cannot communicate, so you have no program.

"Messaging" is just the same as "callng a function". There is nothing
special to it at all.

>I suspect you've had no real-world OO experience. Large, complex
>projects OO is designed to make easier. All of your experience is
>probably simple PHP pages you do yourself with no collaboration.
At least I have not been taught by people who don't know what they're
talking about.
So obviously you have no real world experience.
>Your attitude would never survive in a the large scale projects I've
>been involved in (100+ programmers, 2 years+ time). But then it
>wouldn't survive the smaller projects I've been involved in, either -
>(i.e. three programmers for two months).
The size of project is irrelevant. The OOP principles are the same
regardless of the size of project. The only project I have ever been
associated with which failed disastrously was one where the system
architects got carried away with their fancy ideas of how OOP should be
implemented and produced something that was so inefficient and
unproductive that the client cancelled the entire project as soon as the
first live programs were produced. It was THEIR attitude that was wrong,
not mine.
If you had worked on something other than a 50 LOC web site you'd know
that is complete horse shit.

Excuse me? I have produced administrative web applications with over 500
components, so that puts me way beyond the 50 LOC web site.

"Administrative web applications"? ROFLMAO! Try a real program. > 1M
LOC, 100+ programmers working for over 2 years. Or even something with
10K LOC - all in one file, not a bunch of separate web pages.

I'll bet none of your "web programs" has more than 500 LOC on a single
page.

None, actually. That's because I make use of a large library of reusable
modules. Isn't that supposed to be what OO is all about, making maximu use
of reusable modules?

Just because some system architects didn't know what they were doing
doesn't mean OO is bad. It means only that they had no idea what they
were doing.

But they were folowing allthe rules, so how could they be wrong?

You don't read well, do you. Just because some system architects didn't
know what they were doing doesn't mean that OO is bad. It means only that
they had no idea what they were doing.

For the record - since starting with OO in 1988, I've been involved in a
number of projects - small to large. And every project where people knew
what they were doing was successful.

If your techniques produce something that works, then you are obviously
doing something right. It is only when the software does not work that
you can say that the techniques were wrong. My techniques work, therefore
you have no cause to say that the are wrong.

Wrong, wrong, wrong. And unfortunately the attitude of too many
"programmers" like you who are "developing" web pages. You can get a lot
of things to work. That doesn't mean they are right. And you're
"justification" has too many holes to count.

Something that works cannot be wrong just as something that does not work
cannot be right. If you cannot understand that simple concept you have no
right to class yourself as an "expert" (except in BS)

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

[Jerry Stuckle]

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:T4******************************@comcast.com. ..

The mere fact that you call one object from another automatically means that
you have messaging. There is no special technique nvolved. It is just the
same as calling a non-OO function, just that you hae to specify both the
oject and the method.

So now you're agreeing that message passing is intrinsic to OO. Interesting
about face.

Message passing is not unique to OO, and is not one of the fundamental
principles. It is simply the way that one object communicates with
another.

And without it objects cannot communicate, so you have no program.

So Message Passing is one of the properties of OO.

"Messaging" is just the same as "callng a function". There is nothing
special to it at all.

In PHP, that is true. Other languages may implement it differently. The
concept exists; the implementation is left to the language designers.

I'll bet none of your "web programs" has more than 500 LOC on a single
page.

None, actually. That's because I make use of a large library of reusable
modules. Isn't that supposed to be what OO is all about, making maximu use
of reusable modules?

Yep. Try working on a big program - like I've said before. It's not all in one
file, and may have hundreds or even thousands of objects.

PART of what OO is about is making reusable classes. Another part is isolating
the interface from the implementation to make changes easier and limit the
unwarranted effects of changes. Also to make programming easier by being able
to operate on an object without having to worry what that object is. The list
goes on.

Yes, reuse is *one* of the reasons for OO programming.

Wrong, wrong, wrong. And unfortunately the attitude of too many
"programmers" like you who are "developing" web pages. You can get a lot
of things to work. That doesn't mean they are right. And you're
"justification" has too many holes to count.

Something that works cannot be wrong just as something that does not work
cannot be right. If you cannot understand that simple concept you have no
right to class yourself as an "expert" (except in BS)

No, Tony, something can work but be wrong. And something that doesn't work may
not be completely right - but that doesn't mean it's wrong.

You are an expert in BS, I will agree.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:oM******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Ir******************************@comcast.c om...
Henk Verhoeven wrote:
>Jerry Stuckle wrote:
>
>>Actually, things like private declarations are very important.
>
>IMHO private declarations are too rigid and therfore decrease
>reusability. I agree that it can be very usefull to know the intentions
>of the developer of some code one is evaluating to call or some member
>variable one is avaluating to access. But every now and then there are
>good reasons to do it anyway, even if it was intended to be private. For
>example lazy initialization and default reasoning both are often
>implemented using direct access to member variables. Another example is
>using a visitor to implement persistency.
>
>Now maybe you would say that i should change these member variables to
>protected or public. There are two problems with this:
>1. It may not be my own code. Then if i get an upgrade of this code,
>these member variables will once again be private, unless i re-apply my
>changes. This is uneccessary overhead.
>2. By changing the private declaration the intension of the other
>developer gets lost. Now i could put a comment in that it was intended
>to be private, but in that case: why not put the @private marker in the
>comment in the first place?
>
>The fundamental point is: With these private and protected declarations
>you get stuck with the uneccessarily limitations introduced by the
>author. Object-orientation can lead to more reusability then
>conventional parameterized code exactly because the code can be
>overridden and extended in ways the original author did not provide for.
>private and protected declarations are a step backwards that is only
>reasonable if you assume that future developers that will maintain or
>reuse your code will ignore your intentions becuase they are fools. If
>this is the case, i think you should tell your boss that you are
>limiting the reusability of your code because you are aniticipating him
>to hire fools and let them work on/with your code ;-)
>
>Greetings,
>
>Henk Verhoeven,
>www.phpPeanuts.org.

Henk,

Private declarations are key to OO programming.
No they are not. Encapsulation is not the same as data hiding. Please
refer to:
http://www.javaworld.com/javaworld/j...psulation.html
http://www.itmweb.com/essay550.htm

Give it up, Tony. You obviously can't even understand the information you
reference.

No, I won't give it up. Both those articles clearly state that private
declarations (data hiding) is *not* one of the key concepts of OO.
Encapsulation is about *implementation* hiding, not information* hiding.

Try reading from a real expert - like Booch, Rumbaugh or Iverson. Just because
someone posts something on the internet doesn't make them an expert. You've
proven that several times here.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:7s******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:Te******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:7f******************************@comcast. com...
>Tony Marston wrote:
>
>
>>"Jerry Stuckle" <js*******@attglobal.net> wrote in message
>>news:tM******************************@comcas t.com...
>>
>>
>>
>>>Tony Marston wrote:
>>>
>>>
>>>
>>>>"Jerry Stuckle" <js*******@attglobal.net> wrote in message
>>>>news:ce******************************@comc ast.com...
>>>>
>>
>><snip>
>>
>>>>OO is about encapsulation, polymorphism and inheritance. Message
>>>>passing is incidental.
>>>>
>>>>
>>>>
>>>>>And YOU are the one "bastardizing" OO. Your sloppy approach to
>>>>>programming is just what *real* OO is designed to eliminate. And
>>>>>it makes the coding much more maintainable, expandable and
>>>>>modifiable.
>>>>
>>>>
>>>>Not the way some people use OO. They deliberately make it more
>>>>complicated than it need be, while I keep it as simple as possible.
>>>>
>>>
>>>And that is where you are 100% wrong. Message passing is an integral
>>>part of both object-based and object-oriented languages.
>>>
>>>One bit of wisdom, Tony. Tis better to remain silent and have
>>>everyone thing you might be a fool than to open your mouth and remove
>>>all doubt.
>>>
>>>In the OO world you have removed all doubt.
>>
>>
>>The three principles of OO are encapsulation, polymorphism and
>>inheritance. Message passing does not appear in that list, so it is a
>>minor detail.
>>
>
>And that's where you are totally wrong.
Excuse me? After performing a google search on OOP all I see quoted time
after time are the three basic principles - encapsulation, inheritance
and polymorphism - so how could I possibly be wrong?
Maybe if you check some sites which know what they're talking about -
instead of your own. Try some like:

http://www.fincher.org/tips/General/...edDesign.shtml
http://en.wikipedia.org/wiki/Object-...ed_programming
http://www.awprofessional.com/bookst...824191&redir=1
http://www.objectfaq.com/oofaq2/body/basics.htm

Just for starters.

I got my information from these sites:

http://c2.com/cgi/wiki?ObjectOriented
http://c2.com/cgi/wiki?PolymorphismE...ionInheritance
http://en.wikipedia.org/wiki/Object-...ed_programming
http://www.phpbuilder.com/columns/luis20000420.php3

All I see about message passing is that it is how one object communicates
with another. This is a trivial detail compared with encapsulation,
inheritance and polymorphism. Even non-OO languages can pass messages, so
what's so important about it?

Gee, and wiki's are the Last Word? ROFLMAO! Try some real experts - like
Booch, Iverson and Rumbaugh, for instance. These guys have been
recognized as experts throughout the world for upwards of 20 years -
instead of some guy who posted in a wiki.

There is nothing special with messaging. It's a piece of code calling a
function, which has existed in many non-OO languages for decades. There is
no difference between calling a function and calling a method (function)
within an object.

OOP is about encapsulation, inheritance and polymorhism, and the ability to
create objects from classes. It is taken for granted that there is a method
of communicating with each of the objets ou create. There is nothing special
about "messaging" at all.
However, wikipedia (which I also mentioned because it might meet your
level of intelligence), says under "Fundamental Concepts":

"Method (also known as message) — how code can use an object of some
class. A method is a form of subroutine operating on a single object
Other languages have had the ability to create subroutines, and to be able
to call those subrutines, for ages. There is nothing special about that
which only eists in OOP.
. Methods may be divided into queries returning the current state and
commands changing it:
Other langages have had the ability for a module to have several entry
points, and for each entry point to do something different, for decades.
There is nothing special about his technique which is unique to OOP,
therefore saying that it is a fundamental priciple of OOP is entirely
misleading. AFAIAC it is a fundamental requirement of EVERY language, OO and
non-OO, to be able to call one module from another. This is a standard
requirement, there is nothing special aout it at all.
a Dog could have a query Age to say how old it is, and command chase
(Rabbit target) to start it chasing a rabbit. A method may also do both,
but some authorities (e.g. Bertrand Meyer) recommend they be kept
separate. Sometimes access to the data of an object is restricted to the
methods of its class."

It is important because that's how you communicate with objects. It's the
interface, which is public, instead of the implementation, which is
private.
Calling a function and passing parameters to it, and getting parameters
back, is not something which is unique to OO. It is a standard feature of
EVERY language, therefore to say that it is a fundamental principle of OOP
carries no more weight than saying the ability to declare variables is a
fundamental principle of OOP. It is oneof those obvious things which should
not have to be stated.
But if you understood OO as well as you claim you would understand that.

The difference between an OO and a non-OO language is that one has
encapsulation, inheritance and polymorphism while the other does not. Both
have messaging (the ability to call functions) so that is a complete red
herring.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

[Jerry Stuckle]

Tony Marston wrote:

There is nothing special with messaging. It's a piece of code calling a
function, which has existed in many non-OO languages for decades. There is
no difference between calling a function and calling a method (function)
within an object.

OOP is about encapsulation, inheritance and polymorhism, and the ability to
create objects from classes. It is taken for granted that there is a method
of communicating with each of the objets ou create. There is nothing special
about "messaging" at all.

Well, the fact is, messages (function calls) are OPTIONAL in other languages.
You can build a C program without any functions (other than main()). You can
build an assembler program with no subroutines.

But OO *REQUIRES* messages.

However, wikipedia (which I also mentioned because it might meet your
level of intelligence), says under "Fundamental Concepts":

"Method (also known as message) — how code can use an object of some
class. A method is a form of subroutine operating on a single object

Other languages have had the ability to create subroutines, and to be able
to call those subrutines, for ages. There is nothing special about that
which only eists in OOP.

Sure, they *HAVE THE ABILITY*. In OO, you *MUST CREATE THEM*.

. Methods may be divided into queries returning the current state and
commands changing it:

Other langages have had the ability for a module to have several entry
points, and for each entry point to do something different, for decades.
There is nothing special about his technique which is unique to OOP,
therefore saying that it is a fundamental priciple of OOP is entirely
misleading. AFAIAC it is a fundamental requirement of EVERY language, OO and
non-OO, to be able to call one module from another. This is a standard
requirement, there is nothing special aout it at all.

You just don't seem to understand the difference between *HAVING THE ABILITY*
and *REQUIRING* something.

a Dog could have a query Age to say how old it is, and command chase
(Rabbit target) to start it chasing a rabbit. A method may also do both,
but some authorities (e.g. Bertrand Meyer) recommend they be kept
separate. Sometimes access to the data of an object is restricted to the
methods of its class."

It is important because that's how you communicate with objects. It's the
interface, which is public, instead of the implementation, which is
private.

Calling a function and passing parameters to it, and getting parameters
back, is not something which is unique to OO. It is a standard feature of
EVERY language, therefore to say that it is a fundamental principle of OOP
carries no more weight than saying the ability to declare variables is a
fundamental principle of OOP. It is oneof those obvious things which should
not have to be stated.

Sure it's a fundamental principal. Because OO *REQUIRES IT*.

But if you understood OO as well as you claim you would understand that.

The difference between an OO and a non-OO language is that one has
encapsulation, inheritance and polymorphism while the other does not. Both
have messaging (the ability to call functions) so that is a complete red
herring.

And OO *REQUIRES* message passing. Non-OO languages do not.

You really ARE dense, aren't you?

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

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:HN******************************@comcast.com. ..

Tony Marston wrote:

There is nothing special with messaging. It's a piece of code calling a
function, which has existed in many non-OO languages for decades. There
is no difference between calling a function and calling a method
(function) within an object.

OOP is about encapsulation, inheritance and polymorhism, and the ability
to create objects from classes. It is taken for granted that there is a
method of communicating with each of the objets ou create. There is
nothing special about "messaging" at all.

Well, the fact is, messages (function calls) are OPTIONAL in other
languages. You can build a C program without any functions (other than
main()). You can build an assembler program with no subroutines.

While it is true that you can write a program which doesn't call any
subroutines or functions, it is still part of the language as standard.
But OO *REQUIRES* messages.

So what? Messaging is the same as calling a function or subroutine, and this
is a standard feature of EVERY computer language. There is nothing in OOP
that makes it unique.

However, wikipedia (which I also mentioned because it might meet your
level of intelligence), says under "Fundamental Concepts":

"Method (also known as message) — how code can use an object of some
class. A method is a form of subroutine operating on a single object

Other languages have had the ability to create subroutines, and to be
able to call those subrutines, for ages. There is nothing special about
that which only eists in OOP.

Sure, they *HAVE THE ABILITY*. In OO, you *MUST CREATE THEM*.

. Methods may be divided into queries returning the current state and
commands changing it:

Other langages have had the ability for a module to have several entry
points, and for each entry point to do something different, for decades.
There is nothing special about his technique which is unique to OOP,
therefore saying that it is a fundamental priciple of OOP is entirely
misleading. AFAIAC it is a fundamental requirement of EVERY language, OO
and non-OO, to be able to call one module from another. This is a
standard requirement, there is nothing special aout it at all.

You just don't seem to understand the difference between *HAVING THE
ABILITY* and *REQUIRING* something.

Your point is that messaging is a fundamental principle of OOP which sets it
apart from non-OOP languages. My point is that tyhe same feature exists in
ALL computer languages. If the only real difference is that in OOP it is
*REQUIRED* whereas in other languages it is *OPTIONAL* I think you are
making a mountain out of a molehill. The things which are supposed to make a
language OO instead of non-OO are only supposed to exist in OO languages, so
if messaging already exists in non-OO languages then it cannoit be a
fundamental principle of OO.

a Dog could have a query Age to say how old it is, and command chase
(Rabbit target) to start it chasing a rabbit. A method may also do both,
but some authorities (e.g. Bertrand Meyer) recommend they be kept
separate. Sometimes access to the data of an object is restricted to the
methods of its class."

It is important because that's how you communicate with objects. It's
the interface, which is public, instead of the implementation, which is
private.

Calling a function and passing parameters to it, and getting parameters
back, is not something which is unique to OO. It is a standard feature of
EVERY language, therefore to say that it is a fundamental principle of
OOP carries no more weight than saying the ability to declare variables
is a fundamental principle of OOP. It is oneof those obvious things which
should not have to be stated.

Sure it's a fundamental principal. Because OO *REQUIRES IT*.

That does not make it a fundamental principle in my book. If non-OO
languages did not have messaging then that would be a different matter, but
they do, so it isn't.

But if you understood OO as well as you claim you would understand that.

The difference between an OO and a non-OO language is that one has
encapsulation, inheritance and polymorphism while the other does not.
Both have messaging (the ability to call functions) so that is a complete
red herring.

And OO *REQUIRES* message passing. Non-OO languages do not.

You really ARE dense, aren't you?

Not as dense as you. The principles of OO are features that do not exist in
other languages. Having something which is required instead of optional DOES
NOT MAKE IT A FEATURE. Non-OO languages have had messaging for decades, so
messaging is not a fundamental feature of OO.

Encapsulation, inheritance and polymorphism do not exist in non-OO
languages, so THEY are fundamental principles. Messaging is not. The fact
that OO requires messaging while others do not is totally insignificant.

--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org

[Jerry Stuckle]

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:HN******************************@comcast.com. ..

And OO *REQUIRES* message passing. Non-OO languages do not.

You really ARE dense, aren't you?

Not as dense as you. The principles of OO are features that do not exist in
other languages. Having something which is required instead of optional DOES
NOT MAKE IT A FEATURE. Non-OO languages have had messaging for decades, so
messaging is not a fundamental feature of OO.

Encapsulation, inheritance and polymorphism do not exist in non-OO
languages, so THEY are fundamental principles. Messaging is not. The fact
that OO requires messaging while others do not is totally insignificant.

Not at all. Quite frankly, I really don't care what YOU think. What I'm
worried about are the asinine opinions you foster off onto unsuspecting beginners.

I agree you are an expert - ex meaning "has been" and spert being a "drip under
pressure". Describes you exactly.

Once you get some REAL WORLD experience under your belt - and I'm not talking a
few web pages - I'm talking about projects with dozens of programmers and
hundreds of K LOC, we can talk again. Until then I'll just consider you to be
the uneducated idiot you are.

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

[Jim Carlock]

"Tony Marston" <to**@NOSPAM.demon.co.uk> and
"Jerry Stuckle" <js*******@attglobal.net> argued a bunch
about objects, their encapsulated data, and how events
change the nature of the object...

I'm curious as to what the simplest object oriented program
in PHP would be. Either one of you that might be able to
suggest something or provide a demonstration?

Thanks.

--
Jim Carlock
Post replies to the group.

[Jerry Stuckle]

Jim Carlock wrote:

"Tony Marston" <to**@NOSPAM.demon.co.uk> and
"Jerry Stuckle" <js*******@attglobal.net> argued a bunch
about objects, their encapsulated data, and how events
change the nature of the object...

I'm curious as to what the simplest object oriented program
in PHP would be. Either one of you that might be able to
suggest something or provide a demonstration?

Thanks.

Let's see.. It would be one object with a single attribute and one method. The
program would just need to create an object of

Here's one with a a couple of functions to do something useful. It formats the
current date according to "US" or "European" standards and remembers the format.
Note it can be easily expanded to include other date functions and formats.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Simple date display</title>
<?php
class Date {
private $format = 'm/d/Y';

function setFormat($format) {
switch($format) {
case 'US':
$this->format = 'm/d/Y';
return true;
case 'European':
$this->format = 'd.m.Y';
return true;
}
return false;
}
function today() {
return date($this->format);
}
}
?>
</head>
<body>
<?php

$date = new Date();
echo 'Date in U.S. format: ' . $date->today() . "<br>\n";
$date->setFormat('European');
echo 'Date in European format: ' . $date->today() . "<br>\n";
?>
</body>
</html>

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

[Tony Marston]

"Jim Carlock" <an*******@127.0.0.1> wrote in message
news:PQ*******************@tornado.tampabay.rr.com ...

"Tony Marston" <to**@NOSPAM.demon.co.uk> and
"Jerry Stuckle" <js*******@attglobal.net> argued a bunch
about objects, their encapsulated data, and how events
change the nature of the object...

I'm curious as to what the simplest object oriented program
in PHP would be. Either one of you that might be able to
suggest something or provide a demonstration?

Thanks.

I have a small demonstration application which can be accessed from
http://www.tonymarston.net/php-mysql...plication.html, and also its
big brother which can be accessed at http://www.radicore.org/

--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:WJ******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:HN******************************@comcast.com. ..

And OO *REQUIRES* message passing. Non-OO languages do not.

You really ARE dense, aren't you?

Not as dense as you. The principles of OO are features that do not exist
in other languages. Having something which is required instead of
optional DOES NOT MAKE IT A FEATURE. Non-OO languages have had messaging
for decades, so messaging is not a fundamental feature of OO.

Encapsulation, inheritance and polymorphism do not exist in non-OO
languages, so THEY are fundamental principles. Messaging is not. The fact
that OO requires messaging while others do not is totally insignificant.

Not at all. Quite frankly, I really don't care what YOU think. What I'm
worried about are the asinine opinions you foster off onto unsuspecting
beginners.

I agree you are an expert - ex meaning "has been" and spert being a "drip
under pressure". Describes you exactly.

Once you get some REAL WORLD experience under your belt - and I'm not
talking a few web pages - I'm talking about projects with dozens of
programmers and hundreds of K LOC, we can talk again. Until then I'll
just consider you to be the uneducated idiot you are.

The size of project does not determine what is OO and what is not.

That still does not disguise the fact that what you are calling a
fundamental principle of OO is not unique to OO at all, but something which
has been a part of every other language for decades. The fact that it is
required instead of optional is a trivial point which most intelligent
people would not even consider.

--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org

[Jerry Stuckle]

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:WJ******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:HN******************************@comcast.c om...
And OO *REQUIRES* message passing. Non-OO languages do not.

You really ARE dense, aren't you?
Not as dense as you. The principles of OO are features that do not exist
in other languages. Having something which is required instead of
optional DOES NOT MAKE IT A FEATURE. Non-OO languages have had messaging
for decades, so messaging is not a fundamental feature of OO.

Encapsulation, inheritance and polymorphism do not exist in non-OO
languages, so THEY are fundamental principles. Messaging is not. The fact
that OO requires messaging while others do not is totally insignificant.

Not at all. Quite frankly, I really don't care what YOU think. What I'm
worried about are the asinine opinions you foster off onto unsuspecting
beginners.

I agree you are an expert - ex meaning "has been" and spert being a "drip
under pressure". Describes you exactly.

Once you get some REAL WORLD experience under your belt - and I'm not
talking a few web pages - I'm talking about projects with dozens of
programmers and hundreds of K LOC, we can talk again. Until then I'll
just consider you to be the uneducated idiot you are.

The size of project does not determine what is OO and what is not.

That still does not disguise the fact that what you are calling a
fundamental principle of OO is not unique to OO at all, but something which
has been a part of every other language for decades. The fact that it is
required instead of optional is a trivial point which most intelligent
people would not even consider.

It makes a huge difference. You wouldn't get by with your sloppy practices on a
large project. You would have to follow good OO principles to get the job done.
Quite frankly, Tony, I've seen guys like you on big projects. And they don't
make it. They just can't understand why their practices are a bunch of crap.

And I wonder about what Booch (the creator of OO theory) would say about your
"trivial point" - which he considers a fundamental concept in OO. I think he
knows a *little* more about it than you do!

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

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:8s******************************@comcast.com. ..

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:WJ******************************@comcast.com. ..
<snip>
That still does not disguise the fact that what you are calling a
fundamental principle of OO is not unique to OO at all, but something
which has been a part of every other language for decades. The fact that
it is required instead of optional is a trivial point which most
intelligent people would not even consider.

It makes a huge difference.

When most people are already aware of the fact every language already has a
built-in messaging feature, they do not consider the fact that in OO it is
mandatory instead of optional a point worth considering. So to give it
elevated status and call it a fundamental principle of OO is just OTT. The
fundamental principles of OOP, what sets it apart from other paradigms, is
encapsulation, inheritance and polymorhism. Every paradigm has message
passing, so it cannot be a fundamental principle of any of them. It is a
*standard* feature, not a *differentiating* feature.
You wouldn't get by with your sloppy practices on a large project. You
would have to follow good OO principles to get the job done.
The people on that failed project were following "good OO principles" which
is why the project failed. I ignored their failed ideas and consequently was
able to produce working software in 2 man-weeks instead of their 3
man-years. So you can take your "good OO principles" and stick them where
the sun doesn't shine.
Quite frankly, Tony, I've seen guys like you on big projects. And they
don't make it. They just can't understand why their practices are a bunch
of crap.
And I've seen guys like you on big projects who have a knack of turning OOP
into POO(H).
And I wonder about what Booch (the creator of OO theory) would say about
your "trivial point" - which he considers a fundamental concept in OO. I
think he knows a *little* more about it than you do!
And a *lot* more than you do.
Moron.

Right back at ya.

--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org