f



Object Oriented PHP

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?

0
wtr_clr (75)
6/17/2006 6:11:54 PM
comp.lang.php 32646 articles. 0 followers. Post Follow

74 Replies
32363 Views

Similar Articles

[PageSpeed] 39

Not a tutorial, but an example:
http://www.w-p.dds.nl/tinyunit.htm

Water Cooler v2 wrote:
> 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?
> 
0
nospam30 (870)
6/17/2006 6:34:48 PM
I've seen the C++ scope resolution operator used in some place in PHP
code. I do not recall where I saw it.

What's that (::) for? Does it have the same use as in C++?

0
wtr_clr (75)
6/17/2006 6:53:58 PM
Water Cooler v2 wrote:
>
> 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?

Start with the Manual:

http://www.php.net/OOP
http://www.php.net/OOP5

Note that there are differences between PHP 4 and PHP 5 when it comes
to OO syntax.  

Cheers, 
NC

0
nc (1051)
6/17/2006 7:09:07 PM
Water Cooler v2 wrote:
>
> What's that (::) for? Does it have the same use as in C++?

It's all in the Manual:

http://www.php.net/manual/en/keyword.paamayim-nekudotayim.php
http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.php

Cheers, 
NC

0
nc (1051)
6/17/2006 7:10:58 PM
Thanks very much. :-)

0
wtr_clr (75)
6/17/2006 7:45:30 PM
Water Cooler v2 wrote:
> Thanks very much. :-)

Here's an OO versus Procedural example of making a MySQLi connection

http://au.php.net/manual/en/function.mysqli-prepare.php

0
6/18/2006 10:12:28 PM
Water Cooler v2 wrote:

> Thanks very much. :-)
> 
You can olso read 
http://www-128.ibm.com/developerworks/opensource/library/os-php-flexobj/?ca=dgr-lnxw01DynamicPHP
http://www.onlamp.com/pub/a/php/2005/06/16/overloading.html
The thread "PHP Dynamic Database Code" started by josh.kuo@gmail.com on 
Fri, 9 Jun 2006 23:13:21 +0000 (UTC) (from which i have the above urls) 
may also be interesting.

Once you have a reasonable understanding of the basics of OOP, you could 
take a look at the examples/turorial of phpPeanuts, experiment with it 
and dig into its code using the hypercode browsers to try to understand 
how the framework works. It's very OO ;-)

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.
0
news18670 (95)
6/23/2006 11:00:15 PM
In article <e7hrmq$od8$1@news6.zwoll1.ov.home.nl>, Henk Verhoeven says...
>
>Water Cooler v2 wrote:
>
>> Thanks very much. :-)
>> 
>You can olso read 
>http://www-128.ibm.com/developerworks/opensource/library/os-php-flexobj/?ca=dgr-lnxw01DynamicPHP
>http://www.onlamp.com/pub/a/php/2005/06/16/overloading.html
>The thread "PHP Dynamic Database Code" started by josh.kuo@gmail.com on 
>Fri, 9 Jun 2006 23:13:21 +0000 (UTC) (from which i have the above urls) 
>may also be interesting.
>
>Once you have a reasonable understanding of the basics of OOP, you could 
>take a look at the examples/turorial of phpPeanuts, experiment with it 
>and dig into its code using the hypercode browsers to try to understand 
>how the framework works. It's very OO ;-)
>
>Greetings,
>
>Henk Verhoeven,
>www.phpPeanuts.org.

If I haven't worked with OOP much would PHP be a safe starting point, or is
there a better programming language to start with?


-- 
Newsguy Express 30 GB $9.95/month
http://newsguy.com/overview.htm
0
427SOHC
6/24/2006 1:09:16 AM
427SOHC wrote:
>
> If I haven't worked with OOP much would PHP be a safe
> starting point, or is there a better programming language
> to start with?

If you haven't worked with OOP before, start by learning OOP in the
language you otherwise know well.  Once you understand the basic
concepts (encapsulation, inheritance, polymorphism, etc.), you will be
able to ask intelligent questions about how those concepts are
implemented in other languages.

Also, note that PHP 4 and PHP 5 have different object models; the one
in PHP 5 is more in line with what you find in other languages, while
the one in PHP 4 is simpler, but more restrictive.  

Cheers, 
NC

0
nc (1051)
6/24/2006 5:43:15 AM
"NC" <nc@iname.com> wrote in message 
news:1151127795.486389.113090@b68g2000cwa.googlegroups.com...
> 427SOHC wrote:
>>
>> If I haven't worked with OOP much would PHP be a safe
>> starting point, or is there a better programming language
>> to start with?
>
> If you haven't worked with OOP before, start by learning OOP in the
> language you otherwise know well.  Once you understand the basic
> concepts (encapsulation, inheritance, polymorphism, etc.), you will be
> able to ask intelligent questions about how those concepts are
> implemented in other languages.
>
> Also, note that PHP 4 and PHP 5 have different object models; the one
> in PHP 5 is more in line with what you find in other languages, while
> the one in PHP 4 is simpler, but more restrictive.

"More restrictive" is a point of view. It is possible to write OO code in 
PHP 4 that also runs in PHP 5, as I have proved with my sample application 
and later my full-blown framework.

AFAIAC the extra OO features in PHP 5 are nothing more than eye candy as 
they do not provide any additional functionality which is worthy of merit. 
They were only included to appease the OO purists.

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


0
tony155 (869)
6/24/2006 8:49:19 AM
Tony Marston wrote:
> "NC" <nc@iname.com> wrote in message 
> news:1151127795.486389.113090@b68g2000cwa.googlegroups.com...
> 
>>427SOHC wrote:
>>
>>>If I haven't worked with OOP much would PHP be a safe
>>>starting point, or is there a better programming language
>>>to start with?
>>
>>If you haven't worked with OOP before, start by learning OOP in the
>>language you otherwise know well.  Once you understand the basic
>>concepts (encapsulation, inheritance, polymorphism, etc.), you will be
>>able to ask intelligent questions about how those concepts are
>>implemented in other languages.
>>
>>Also, note that PHP 4 and PHP 5 have different object models; the one
>>in PHP 5 is more in line with what you find in other languages, while
>>the one in PHP 4 is simpler, but more restrictive.
> 
> 
> "More restrictive" is a point of view. It is possible to write OO code in 
> PHP 4 that also runs in PHP 5, as I have proved with my sample application 
> and later my full-blown framework.
> 
> AFAIAC the extra OO features in PHP 5 are nothing more than eye candy as 
> they do not provide any additional functionality which is worthy of merit. 
> They were only included to appease the OO purists.
> 

Actually, things like private declarations are very important.  They are 
unimportant only to those who don't understand OO programming - or those who are 
sloppy in their implementations.



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/24/2006 7:43:18 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:25Sdne4XpP1UCADZnZ2dnUVZ_vmdnZ2d@comcast.com...
> Tony Marston wrote:
>> "NC" <nc@iname.com> wrote in message 
>> news:1151127795.486389.113090@b68g2000cwa.googlegroups.com...
>>
>>>427SOHC wrote:
>>>
>>>>If I haven't worked with OOP much would PHP be a safe
>>>>starting point, or is there a better programming language
>>>>to start with?
>>>
>>>If you haven't worked with OOP before, start by learning OOP in the
>>>language you otherwise know well.  Once you understand the basic
>>>concepts (encapsulation, inheritance, polymorphism, etc.), you will be
>>>able to ask intelligent questions about how those concepts are
>>>implemented in other languages.
>>>
>>>Also, note that PHP 4 and PHP 5 have different object models; the one
>>>in PHP 5 is more in line with what you find in other languages, while
>>>the one in PHP 4 is simpler, but more restrictive.
>>
>>
>> "More restrictive" is a point of view. It is possible to write OO code in 
>> PHP 4 that also runs in PHP 5, as I have proved with my sample 
>> application and later my full-blown framework.
>>
>> AFAIAC the extra OO features in PHP 5 are nothing more than eye candy as 
>> they do not provide any additional functionality which is worthy of 
>> merit. They were only included to appease the OO purists.
>>
>
> Actually, things like private declarations are very important.  They are 
> unimportant only to those who don't understand OO programming - or those 
> who are sloppy in their implementations.

You don't *need* private declarations. Code will work just as well without 
them.

-- 
Tony Marston

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



0
tony155 (869)
6/24/2006 9:56:20 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> Actually, things like private declarations are very important.  They are 
>> unimportant only to those who don't understand OO programming - or those 
>> who are sloppy in their implementations.
> 
> You don't *need* private declarations. Code will work just as well without 
> them.
> 

What the heck! Let's just throw away multiply and divide. We don't 
*need* them. We can just use add and subtract.

Heck! Why do we need subtract? We can just add negative values.

Hey! Assembler works well without private declarations. Let's just pitch 
PHP all together.

The point is that constructs are added to language to assist in the 
functionality and maintainability of programs written in that language. 
The introduction of private and protected adds to the maintainability 
both through its inherent protection capabilities and its clarity of 
intent for the maintainer.

Now if PHP could just get polymorphism...

-david-

0
6/25/2006 12:10:29 AM
David Haynes wrote:
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>> Actually, things like private declarations are very important.  They 
>>> are unimportant only to those who don't understand OO programming - 
>>> or those who are sloppy in their implementations.
>>
>> You don't *need* private declarations. Code will work just as well 
>> without them.
>>
> 
> What the heck! Let's just throw away multiply and divide. We don't 
> *need* them. We can just use add and subtract.
> 
> Heck! Why do we need subtract? We can just add negative values.
> 
> Hey! Assembler works well without private declarations. Let's just pitch 
> PHP all together.
> 
> The point is that constructs are added to language to assist in the 
> functionality and maintainability of programs written in that language. 
> The introduction of private and protected adds to the maintainability 
> both through its inherent protection capabilities and its clarity of 
> intent for the maintainer.
> 
> Now if PHP could just get polymorphism...
> 
> -david-
> 

Sorry I am new to PHP but use Java. My question is how can you have a 
OOP Language and not have polymorphic features. Sorry, I have not gotten 
up to par on PHP yet.

Thanks in Advance...
IchBin, Pocono Lake, Pa, USA http://weconsultants.awardspace.com
__________________________________________________________________________

'If there is one, Knowledge is the "Fountain of Youth"'
-William E. Taylor,  Regular Guy (1952-)
0
weconsul (1131)
6/25/2006 1:05:24 AM
IchBin wrote:
> David Haynes wrote:
> 
>> Tony Marston wrote:
>>
>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>
>>>> Actually, things like private declarations are very important.  They 
>>>> are unimportant only to those who don't understand OO programming - 
>>>> or those who are sloppy in their implementations.
>>>
>>>
>>> You don't *need* private declarations. Code will work just as well 
>>> without them.
>>>
>>
>> What the heck! Let's just throw away multiply and divide. We don't 
>> *need* them. We can just use add and subtract.
>>
>> Heck! Why do we need subtract? We can just add negative values.
>>
>> Hey! Assembler works well without private declarations. Let's just 
>> pitch PHP all together.
>>
>> The point is that constructs are added to language to assist in the 
>> functionality and maintainability of programs written in that 
>> language. The introduction of private and protected adds to the 
>> maintainability both through its inherent protection capabilities and 
>> its clarity of intent for the maintainer.
>>
>> Now if PHP could just get polymorphism...
>>
>> -david-
>>
> 
> Sorry I am new to PHP but use Java. My question is how can you have a 
> OOP Language and not have polymorphic features. Sorry, I have not gotten 
> up to par on PHP yet.
> 
> Thanks in Advance...
> IchBin, Pocono Lake, Pa, USA http://weconsultants.awardspace.com
> __________________________________________________________________________
> 
> 'If there is one, Knowledge is the "Fountain of Youth"'
> -William E. Taylor,  Regular Guy (1952-)

PHP does have some polymorphic-like abilities, but that's because of the untyped 
nature of the variables.

PHP is getting better in it's OO aspects, but I doubt it will ever be quite like 
Java.  There's just a basic difference between languages with typed and untyped 
variables.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/25/2006 1:26:53 AM
Jerry Stuckle wrote:
> IchBin wrote:
>> David Haynes wrote:
>>
>>> Tony Marston wrote:
>>>
>>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>>
>>>>> Actually, things like private declarations are very important.  
>>>>> They are unimportant only to those who don't understand OO 
>>>>> programming - or those who are sloppy in their implementations.
>>>>
>>>>
>>>> You don't *need* private declarations. Code will work just as well 
>>>> without them.
>>>>
>>>
>>> What the heck! Let's just throw away multiply and divide. We don't 
>>> *need* them. We can just use add and subtract.
>>>
>>> Heck! Why do we need subtract? We can just add negative values.
>>>
>>> Hey! Assembler works well without private declarations. Let's just 
>>> pitch PHP all together.
>>>
>>> The point is that constructs are added to language to assist in the 
>>> functionality and maintainability of programs written in that 
>>> language. The introduction of private and protected adds to the 
>>> maintainability both through its inherent protection capabilities and 
>>> its clarity of intent for the maintainer.
>>>
>>> Now if PHP could just get polymorphism...
>>>
>>> -david-
>>>
>>
>> Sorry I am new to PHP but use Java. My question is how can you have a 
>> OOP Language and not have polymorphic features. Sorry, I have not 
>> gotten up to par on PHP yet.
>>
>> Thanks in Advance...
>> IchBin, Pocono Lake, Pa, USA http://weconsultants.awardspace.com
>> __________________________________________________________________________ 
>>
>>
>> 'If there is one, Knowledge is the "Fountain of Youth"'
>> -William E. Taylor,  Regular Guy (1952-)
> 
> PHP does have some polymorphic-like abilities, but that's because of the 
> untyped nature of the variables.
> 
> PHP is getting better in it's OO aspects, but I doubt it will ever be 
> quite like Java.  There's just a basic difference between languages with 
> typed and untyped variables.
> 
> 
Thanks for the info..

I read something about PHP version 5, OOP\OOD and typed Objects. So I 
guess there are really not fully typed object. I have to read more and 
not take OOP references as used by say smalltalk and Java and others.

-- 

Thanks in Advance...
IchBin, Pocono Lake, Pa, USA http://weconsultants.awardspace.com
__________________________________________________________________________

'If there is one, Knowledge is the "Fountain of Youth"'
-William E. Taylor,  Regular Guy (1952-)
0
weconsul (1131)
6/25/2006 1:51:49 AM
Jerry Stuckle wrote:
> PHP does have some polymorphic-like abilities, but that's because of the 
> untyped nature of the variables.
> 
> PHP is getting better in it's OO aspects, but I doubt it will ever be 
> quite like Java.  There's just a basic difference between languages with 
> typed and untyped variables.

I was thinking about this the other day and it may not be all that 
difficult to add it.

Consider that you can already type the arguments to the constructor. 
Given this, it would not be all that hard to derive a typed signature 
which could then be applied.

-david-

0
6/25/2006 2:31:09 AM
David Haynes wrote:
> Jerry Stuckle wrote:
> 
>> PHP does have some polymorphic-like abilities, but that's because of 
>> the untyped nature of the variables.
>>
>> PHP is getting better in it's OO aspects, but I doubt it will ever be 
>> quite like Java.  There's just a basic difference between languages 
>> with typed and untyped variables.
> 
> 
> I was thinking about this the other day and it may not be all that 
> difficult to add it.
> 
> Consider that you can already type the arguments to the constructor. 
> Given this, it would not be all that hard to derive a typed signature 
> which could then be applied.
> 
> -david-
> 

I really don't know how hard it would be to add - but I would like to see it 
added.  One thing I don't like all that much is the untyped variables.  It makes 
things "easy" - but leads to some sloppy programming.

It also means you can't overload functions - at least not with the same number 
of parms.  Typing the constructor arguments is a good start.  But expanding that 
to other functions without breaking existing code might be more difficult.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/25/2006 3:00:56 AM
"David Haynes" <david.haynes2@sympatico.ca> wrote in message 
news:Tvkng.22537$oG2.21662@fe26.usenetserver.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>> Actually, things like private declarations are very important.  They are 
>>> unimportant only to those who don't understand OO programming - or those 
>>> who are sloppy in their implementations.
>>
>> You don't *need* private declarations. Code will work just as well 
>> without them.
>>
>
> What the heck! Let's just throw away multiply and divide. We don't *need* 
> them. We can just use add and subtract.
>
> Heck! Why do we need subtract? We can just add negative values.
>
> Hey! Assembler works well without private declarations. Let's just pitch 
> PHP all together.
>
> The point is that constructs are added to language to assist in the 
> functionality and maintainability of programs written in that language. 
> The introduction of private and protected adds to the maintainability both 
> through its inherent protection capabilities and its clarity of intent for 
> the maintainer.
>
> Now if PHP could just get polymorphism...

OOP with PHP already has polymorphism. You obviously don't know what 
polymorphism means.

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 8:25:51 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:4K2dnSM18oD9YQDZnZ2dnUVZ_oWdnZ2d@comcast.com...
> David Haynes wrote:
>> Jerry Stuckle wrote:
>>
< snip >

> I really don't know how hard it would be to add - but I would like to see 
> it added.  One thing I don't like all that much is the untyped variables. 
> It makes things "easy" - but leads to some sloppy programming.
>
> It also means you can't overload functions - at least not with the same 
> number of parms.  Typing the constructor arguments is a good start.  But 
> expanding that to other functions without breaking existing code might be 
> more difficult.

You don't need function overloading in PHP. Why? First you need to look at 
why other languages need it:
(a) To accept arguments of different types.
(b) To make some arguments optional.

With PHP you can accept an argument of any type and then cast it to the one 
you want, so item (a) is irrelevant.

With PHP you can define a default value for an argument if it is not 
supplied, so item (b) is irrelevant.

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 8:30:14 AM
Tony Marston wrote:
> "David Haynes" <david.haynes2@sympatico.ca> wrote in message 
> news:Tvkng.22537$oG2.21662@fe26.usenetserver.com...
>> Tony Marston wrote:
>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>> Actually, things like private declarations are very important.  They are 
>>>> unimportant only to those who don't understand OO programming - or those 
>>>> who are sloppy in their implementations.
>>> You don't *need* private declarations. Code will work just as well 
>>> without them.
>>>
>> What the heck! Let's just throw away multiply and divide. We don't *need* 
>> them. We can just use add and subtract.
>>
>> Heck! Why do we need subtract? We can just add negative values.
>>
>> Hey! Assembler works well without private declarations. Let's just pitch 
>> PHP all together.
>>
>> The point is that constructs are added to language to assist in the 
>> functionality and maintainability of programs written in that language. 
>> The introduction of private and protected adds to the maintainability both 
>> through its inherent protection capabilities and its clarity of intent for 
>> the maintainer.
>>
>> Now if PHP could just get polymorphism...
> 
> OOP with PHP already has polymorphism. You obviously don't know what 
> polymorphism means.
> 
Tony:

PHP5 has weak polymorphism but not true polymorphism in the sense that 
it is used in OOP.

You cannot, for instance, have multiple constructors for an object where 
the number of the arguments to the constructor are variable. Yes, you 
may supply default values to 'optional' arguments but consider this example:

class Foo {
function __construct($one, $two="two", $three="three") {

I cannot instantiate this object as new Foo($one, $three) since there is 
no typing on the arguments and, therefore, no signature for a 'one, 
three' contructor. Nor could I define multiple __constructor() methods 
to allow for the new Foo($one, $three) case.

This type of action is common in other OOP languages such as Java and C++.

To add to the confusion from an OOP programmer's viewpoint, in order to 
invoke the 'default' value for $three, I *must* supply a value for $two. 
That is, new Foo($one, , $three) is syntactically illegal and there is 
AFAIK no way to specify that we want $two to take its default value 
while supplying a value for $three.

So, maybe its not me who is unclear on the concept of polymorphism...

-david-

0
6/25/2006 9:39:33 AM
On 2006-06-25, David Haynes <david.haynes2@sympatico.ca> wrote:
> PHP5 has weak polymorphism but not true polymorphism in the sense that 
> it is used in OOP.

So how would you define polymorphism? And what exactly are the
differences between 'weak' and 'true' polymorphism?

If i look at http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29

"The concept of polymorphism applies to data types in addition to
functions. A function that can evaluate to and be applied to values of
different types is known as a polymorphic function. A data type that
contains elements of different types is known as a polymorphic data
type."

> function __construct($one, $two="two", $three="three") {
>
> I cannot instantiate this object as new Foo($one, $three) since there is 
> no typing on the arguments and, therefore, no signature for a 'one, 
> three' contructor. 

Imho that's the same as saying: I'm standing with my back against a wall, 
and now i'm wondering why i can't step backwards anymore...

Define your constructor as __constructor($args) and handle with
func_num_args and func_get_args(s) any number of parameters...

(I do agree that the language/compiler can, probably should, make this
easier... But that's a different discussion.)

-- 
Met vriendelijke groeten,
Tim Van Wassenhove <http://timvw.madoka.be>
0
timvw (193)
6/25/2006 12:01:06 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:4K2dnSM18oD9YQDZnZ2dnUVZ_oWdnZ2d@comcast.com...
> 
>>David Haynes wrote:
>>
>>>Jerry Stuckle wrote:
>>>
> 
> < snip >
> 
>>I really don't know how hard it would be to add - but I would like to see 
>>it added.  One thing I don't like all that much is the untyped variables. 
>>It makes things "easy" - but leads to some sloppy programming.
>>
>>It also means you can't overload functions - at least not with the same 
>>number of parms.  Typing the constructor arguments is a good start.  But 
>>expanding that to other functions without breaking existing code might be 
>>more difficult.
> 
> 
> You don't need function overloading in PHP. Why? First you need to look at 
> why other languages need it:
> (a) To accept arguments of different types.
> (b) To make some arguments optional.
> 
> With PHP you can accept an argument of any type and then cast it to the one 
> you want, so item (a) is irrelevant.
> 
> With PHP you can define a default value for an argument if it is not 
> supplied, so item (b) is irrelevant.
> 

Sure.  I would love to be able to have a function which does different things 
based on the type of parameter passed.  It would save a lot of work trying to 
sort out parameters and potentially having to change existing code when adding 
new parameter types.

But we already know you don't understand or appreciate real OO programming, 
Tony.  So quite frankly, I don't give a damn what you think.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/25/2006 1:23:46 PM
Tony Marston wrote:
> "David Haynes" <david.haynes2@sympatico.ca> wrote in message 
> news:Tvkng.22537$oG2.21662@fe26.usenetserver.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>
>>>>Actually, things like private declarations are very important.  They are 
>>>>unimportant only to those who don't understand OO programming - or those 
>>>>who are sloppy in their implementations.
>>>
>>>You don't *need* private declarations. Code will work just as well 
>>>without them.
>>>
>>
>>What the heck! Let's just throw away multiply and divide. We don't *need* 
>>them. We can just use add and subtract.
>>
>>Heck! Why do we need subtract? We can just add negative values.
>>
>>Hey! Assembler works well without private declarations. Let's just pitch 
>>PHP all together.
>>
>>The point is that constructs are added to language to assist in the 
>>functionality and maintainability of programs written in that language. 
>>The introduction of private and protected adds to the maintainability both 
>>through its inherent protection capabilities and its clarity of intent for 
>>the maintainer.
>>
>>Now if PHP could just get polymorphism...
> 
> 
> OOP with PHP already has polymorphism. You obviously don't know what 
> polymorphism means.
> 

No, Tony, you really don't know what polymorphism is, do you?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/25/2006 1:24:21 PM
Tim Van Wassenhove wrote:
> On 2006-06-25, David Haynes <david.haynes2@sympatico.ca> wrote:
>> PHP5 has weak polymorphism but not true polymorphism in the sense that 
>> it is used in OOP.
> 
> So how would you define polymorphism? And what exactly are the
> differences between 'weak' and 'true' polymorphism?
> 
> If i look at http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29
> 
> "The concept of polymorphism applies to data types in addition to
> functions. A function that can evaluate to and be applied to values of
> different types is known as a polymorphic function. A data type that
> contains elements of different types is known as a polymorphic data
> type."

Keep reading the article you referenced.

"This type of polymorphism [overloading] is common in object-oriented 
programming languages, many of which allow operators to be overloaded in 
a manner similar to functions (see operator overloading). It is also 
used extensively in the purely functional programming language Haskell 
in the form of type classes. Many languages lacking ad-hoc polymorphism 
suffer from long-winded names such as print_int, print_string, etc. (see 
C, Objective Caml)."

>> function __construct($one, $two="two", $three="three") {
>>
>> I cannot instantiate this object as new Foo($one, $three) since there is 
>> no typing on the arguments and, therefore, no signature for a 'one, 
>> three' contructor. 
> 
> Imho that's the same as saying: I'm standing with my back against a wall, 
> and now i'm wondering why i can't step backwards anymore...
> 
> Define your constructor as __constructor($args) and handle with
> func_num_args and func_get_args(s) any number of parameters...
> 
> (I do agree that the language/compiler can, probably should, make this
> easier... But that's a different discussion.)

What you have specified is a non-overloaded generic constructor. I view 
this as a work-around due to the inability of the PHP interpreter to 
handle overloading polymorphism.

I'm not saying that this is a bad thing - in fact if you rewind your 
news feed about a week - you will see that I recommended such an 
approach to another coder, but I am saying that most strongly-typed OO 
languages do support overloading as part of the their OOP environment.

-david-


0
6/25/2006 1:26:51 PM
Tim Van Wassenhove wrote:
> On 2006-06-25, David Haynes <david.haynes2@sympatico.ca> wrote:
> 
>>PHP5 has weak polymorphism but not true polymorphism in the sense that 
>>it is used in OOP.
> 
> 
> So how would you define polymorphism? And what exactly are the
> differences between 'weak' and 'true' polymorphism?
> 
> If i look at http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29
> 
> "The concept of polymorphism applies to data types in addition to
> functions. A function that can evaluate to and be applied to values of
> different types is known as a polymorphic function. A data type that
> contains elements of different types is known as a polymorphic data
> type."
> 
> 
>>function __construct($one, $two="two", $three="three") {
>>
>>I cannot instantiate this object as new Foo($one, $three) since there is 
>>no typing on the arguments and, therefore, no signature for a 'one, 
>>three' contructor. 
> 
> 
> Imho that's the same as saying: I'm standing with my back against a wall, 
> and now i'm wondering why i can't step backwards anymore...
> 
> Define your constructor as __constructor($args) and handle with
> func_num_args and func_get_args(s) any number of parameters...
> 
> (I do agree that the language/compiler can, probably should, make this
> easier... But that's a different discussion.)
> 

The constructor overloading example isn't really polymorphism.  It's just 
function overloading.

Polymorphism is the ability to operate on objects of derived classes, without 
knowing what the derived classes are (or potentially even the existence of the 
derived classes).

For instance - let's say we have class "mammal" with function "eats".  Now all 
mammals eat something, but what the class of mammals eats is not defines.

So, derive from mammal the class "ape" and have eats return "bananas".  Also 
derive the class "horse" and have eats return "oats".

Now - when you create an object of the class "ape" you can pass it to a function 
which takes a "mammal".  And you can print out what *this* mammal eats.  The 
same with a horse.

Polymorphism is closely tied to inheritance.  But while inheritance allows the 
programmer to take advantage of the commonalities between classes, polymorphism 
allows the program to take advantage of the differences.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/25/2006 1:32:33 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:l7mdnYQJ5OPlEwPZnZ2dnUVZ_q-dnZ2d@comcast.com...
> Tony Marston wrote:
>> "David Haynes" <david.haynes2@sympatico.ca> wrote in message 
>> news:Tvkng.22537$oG2.21662@fe26.usenetserver.com...
>>
>>>Tony Marston wrote:
>>>
>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>>
>>>>>Actually, things like private declarations are very important.  They 
>>>>>are unimportant only to those who don't understand OO programming - or 
>>>>>those who are sloppy in their implementations.
>>>>
>>>>You don't *need* private declarations. Code will work just as well 
>>>>without them.
>>>>
>>>
>>>What the heck! Let's just throw away multiply and divide. We don't *need* 
>>>them. We can just use add and subtract.
>>>
>>>Heck! Why do we need subtract? We can just add negative values.
>>>
>>>Hey! Assembler works well without private declarations. Let's just pitch 
>>>PHP all together.
>>>
>>>The point is that constructs are added to language to assist in the 
>>>functionality and maintainability of programs written in that language. 
>>>The introduction of private and protected adds to the maintainability 
>>>both through its inherent protection capabilities and its clarity of 
>>>intent for the maintainer.
>>>
>>>Now if PHP could just get polymorphism...
>>
>>
>> OOP with PHP already has polymorphism. You obviously don't know what 
>> polymorphism means.
>>
>
> No, Tony, you really don't know what polymorphism is, do you?

The simplest definition of polymorphism is "same interface, different 
implementation". This means that different objects can share the same 
interface but which do different things. What do you think it means?

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 1:43:14 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:l7mdnYUJ5OPIEwPZnZ2dnUVZ_q-dnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:4K2dnSM18oD9YQDZnZ2dnUVZ_oWdnZ2d@comcast.com...
>>
>>>David Haynes wrote:
>>>
>>>>Jerry Stuckle wrote:
>>>>
>>
>> < snip >
>>
>>>I really don't know how hard it would be to add - but I would like to see 
>>>it added.  One thing I don't like all that much is the untyped variables. 
>>>It makes things "easy" - but leads to some sloppy programming.
>>>
>>>It also means you can't overload functions - at least not with the same 
>>>number of parms.  Typing the constructor arguments is a good start.  But 
>>>expanding that to other functions without breaking existing code might be 
>>>more difficult.
>>
>>
>> You don't need function overloading in PHP. Why? First you need to look 
>> at why other languages need it:
>> (a) To accept arguments of different types.
>> (b) To make some arguments optional.
>>
>> With PHP you can accept an argument of any type and then cast it to the 
>> one you want, so item (a) is irrelevant.
>>
>> With PHP you can define a default value for an argument if it is not 
>> supplied, so item (b) is irrelevant.
>>
>
> Sure.  I would love to be able to have a function which does different 
> things based on the type of parameter passed.  It would save a lot of work 
> trying to sort out parameters and potentially having to change existing 
> code when adding new parameter types.
>
> But we already know you don't understand or appreciate real OO 
> programming, Tony.  So quite frankly, I don't give a damn what you think.

Just because my understanding and implementation of OOP is different from 
yours does not make you right and me wrong.

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 1:45:01 PM
"David Haynes" <david.haynes2@sympatico.ca> wrote in message 
news:pRsng.22585$ax6.3306@fe43.usenetserver.com...
> Tony Marston wrote:
>> "David Haynes" <david.haynes2@sympatico.ca> wrote in message 
>> news:Tvkng.22537$oG2.21662@fe26.usenetserver.com...
>>> Tony Marston wrote:
>>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>>> Actually, things like private declarations are very important.  They 
>>>>> are unimportant only to those who don't understand OO programming - or 
>>>>> those who are sloppy in their implementations.
>>>> You don't *need* private declarations. Code will work just as well 
>>>> without them.
>>>>
>>> What the heck! Let's just throw away multiply and divide. We don't 
>>> *need* them. We can just use add and subtract.
>>>
>>> Heck! Why do we need subtract? We can just add negative values.
>>>
>>> Hey! Assembler works well without private declarations. Let's just pitch 
>>> PHP all together.
>>>
>>> The point is that constructs are added to language to assist in the 
>>> functionality and maintainability of programs written in that language. 
>>> The introduction of private and protected adds to the maintainability 
>>> both through its inherent protection capabilities and its clarity of 
>>> intent for the maintainer.
>>>
>>> Now if PHP could just get polymorphism...
>>
>> OOP with PHP already has polymorphism. You obviously don't know what 
>> polymorphism means.
>>
> Tony:
>
> PHP5 has weak polymorphism but not true polymorphism in the sense that it 
> is used in OOP.
>
> You cannot, for instance, have multiple constructors for an object where 
> the number of the arguments to the constructor are variable. Yes, you may 
> supply default values to 'optional' arguments but consider this example:
>
> class Foo {
> function __construct($one, $two="two", $three="three") {
>
> I cannot instantiate this object as new Foo($one, $three) since there is 
> no typing on the arguments and, therefore, no signature for a 'one, three' 
> contructor. Nor could I define multiple __constructor() methods to allow 
> for the new Foo($one, $three) case.

Polymorphism means "same interface, different implementation". It has 
nothing to do with overloading.

> This type of action is common in other OOP languages such as Java and C++.

Just because those languages have to employ a certain mechanism to achieve a 
certain result does not mean that EVERY language has to employ the same 
mechanism to achieve the same result. Different languages work differently, 
so you should expect different languages to achieve similar results with 
different techniques. If everything was the same there would be no need for 
different languages, would there?

> To add to the confusion from an OOP programmer's viewpoint, in order to 
> invoke the 'default' value for $three, I *must* supply a value for $two. 
> That is, new Foo($one, , $three) is syntactically illegal and there is 
> AFAIK no way to specify that we want $two to take its default value while 
> supplying a value for $three.
>
> So, maybe its not me who is unclear on the concept of polymorphism...

I repeat, overloading has nothing to do with polymorphism.

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 1:50:53 PM
"Tim Van Wassenhove" <timvw@users.sourceforge.net> wrote in message 
news:e7ltu2$cjc$1@ikaria.belnet.be...
> On 2006-06-25, David Haynes <david.haynes2@sympatico.ca> wrote:
>> PHP5 has weak polymorphism but not true polymorphism in the sense that
>> it is used in OOP.
>
> So how would you define polymorphism? And what exactly are the
> differences between 'weak' and 'true' polymorphism?
>
> If i look at 
> http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29
>
> "The concept of polymorphism applies to data types in addition to
> functions. A function that can evaluate to and be applied to values of
> different types is known as a polymorphic function.

Exactly! Same interface, different implementation.

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 1:52:05 PM
"David Haynes" <david.haynes2@sympatico.ca> wrote in message 
news:wawng.46054$dP1.24219@fe03.usenetserver.com...
> Tim Van Wassenhove wrote:
>> On 2006-06-25, David Haynes <david.haynes2@sympatico.ca> wrote:
>>> PHP5 has weak polymorphism but not true polymorphism in the sense that 
>>> it is used in OOP.
>>
>> So how would you define polymorphism? And what exactly are the
>> differences between 'weak' and 'true' polymorphism?
>>
>> If i look at 
>> http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29
>>
>> "The concept of polymorphism applies to data types in addition to
>> functions. A function that can evaluate to and be applied to values of
>> different types is known as a polymorphic function. A data type that
>> contains elements of different types is known as a polymorphic data
>> type."
>
> Keep reading the article you referenced.
>
> "This type of polymorphism [overloading] is common in object-oriented 
> programming languages, many of which allow operators to be overloaded in a 
> manner similar to functions (see operator overloading). It is also used 
> extensively in the purely functional programming language Haskell in the 
> form of type classes. Many languages lacking ad-hoc polymorphism suffer 
> from long-winded names such as print_int, print_string, etc. (see C, 
> Objective Caml)."
>
>>> function __construct($one, $two="two", $three="three") {
>>>
>>> I cannot instantiate this object as new Foo($one, $three) since there is 
>>> no typing on the arguments and, therefore, no signature for a 'one, 
>>> three' contructor.
>>
>> Imho that's the same as saying: I'm standing with my back against a wall, 
>> and now i'm wondering why i can't step backwards anymore...
>>
>> Define your constructor as __constructor($args) and handle with
>> func_num_args and func_get_args(s) any number of parameters...
>>
>> (I do agree that the language/compiler can, probably should, make this
>> easier... But that's a different discussion.)
>
> What you have specified is a non-overloaded generic constructor. I view 
> this as a work-around due to the inability of the PHP interpreter to 
> handle overloading polymorphism.

Just because PHP does not handle overloading in the way that other languages 
do does not mean that it does not support polymorphism. Overloading is not 
the same as polymorphism. They are different concepts that may or may not be 
employed at the same time.

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 1:54:45 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:SY2dnb9_bL74DQPZnZ2dnUVZ_sadnZ2d@comcast.com...
> Tim Van Wassenhove wrote:
>> On 2006-06-25, David Haynes <david.haynes2@sympatico.ca> wrote:
>>
>>>PHP5 has weak polymorphism but not true polymorphism in the sense that it 
>>>is used in OOP.
>>
>>
>> So how would you define polymorphism? And what exactly are the
>> differences between 'weak' and 'true' polymorphism?
>>
>> If i look at 
>> http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29
>>
>> "The concept of polymorphism applies to data types in addition to
>> functions. A function that can evaluate to and be applied to values of
>> different types is known as a polymorphic function. A data type that
>> contains elements of different types is known as a polymorphic data
>> type."
>>
>>
>>>function __construct($one, $two="two", $three="three") {
>>>
>>>I cannot instantiate this object as new Foo($one, $three) since there is 
>>>no typing on the arguments and, therefore, no signature for a 'one, 
>>>three' contructor.
>>
>>
>> Imho that's the same as saying: I'm standing with my back against a wall, 
>> and now i'm wondering why i can't step backwards anymore...
>>
>> Define your constructor as __constructor($args) and handle with
>> func_num_args and func_get_args(s) any number of parameters...
>>
>> (I do agree that the language/compiler can, probably should, make this
>> easier... But that's a different discussion.)
>>
>
> The constructor overloading example isn't really polymorphism.  It's just 
> function overloading.

Absolutely correct. Polymorphism means "same interface, different 
implememtation". You do not need overloading to make polymorphism work.

-- 
Tony Marston

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



> Polymorphism is the ability to operate on objects of derived classes, 
> without knowing what the derived classes are (or potentially even the 
> existence of the derived classes).
>
> For instance - let's say we have class "mammal" with function "eats".  Now 
> all mammals eat something, but what the class of mammals eats is not 
> defines.
>
> So, derive from mammal the class "ape" and have eats return "bananas". 
> Also derive the class "horse" and have eats return "oats".
>
> Now - when you create an object of the class "ape" you can pass it to a 
> function which takes a "mammal".  And you can print out what *this* mammal 
> eats.  The same with a horse.
>
> Polymorphism is closely tied to inheritance.  But while inheritance allows 
> the programmer to take advantage of the commonalities between classes, 
> polymorphism allows the program to take advantage of the differences.
>
>
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstucklex@attglobal.net
> ================== 


0
tony155 (869)
6/25/2006 1:56:57 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:l7mdnYUJ5OPIEwPZnZ2dnUVZ_q-dnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>news:4K2dnSM18oD9YQDZnZ2dnUVZ_oWdnZ2d@comcast.com...
>>>
>>>
>>>>David Haynes wrote:
>>>>
>>>>
>>>>>Jerry Stuckle wrote:
>>>>>
>>>
>>>< snip >
>>>
>>>>I really don't know how hard it would be to add - but I would like to see 
>>>>it added.  One thing I don't like all that much is the untyped variables. 
>>>>It makes things "easy" - but leads to some sloppy programming.
>>>>
>>>>It also means you can't overload functions - at least not with the same 
>>>>number of parms.  Typing the constructor arguments is a good start.  But 
>>>>expanding that to other functions without breaking existing code might be 
>>>>more difficult.
>>>
>>>
>>>You don't need function overloading in PHP. Why? First you need to look 
>>>at why other languages need it:
>>>(a) To accept arguments of different types.
>>>(b) To make some arguments optional.
>>>
>>>With PHP you can accept an argument of any type and then cast it to the 
>>>one you want, so item (a) is irrelevant.
>>>
>>>With PHP you can define a default value for an argument if it is not 
>>>supplied, so item (b) is irrelevant.
>>>
>>
>>Sure.  I would love to be able to have a function which does different 
>>things based on the type of parameter passed.  It would save a lot of work 
>>trying to sort out parameters and potentially having to change existing 
>>code when adding new parameter types.
>>
>>But we already know you don't understand or appreciate real OO 
>>programming, Tony.  So quite frankly, I don't give a damn what you think.
> 
> 
> Just because my understanding and implementation of OOP is different from 
> yours does not make you right and me wrong.
> 

Other than the fact your understanding and implementation is different from 
every expert in the field.

You *think* you understand OO.  But you have no idea what *real* OO is about. 
Otherwise you wouldn't be making some of your comments.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/25/2006 4:35:45 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>
>>No, Tony, you really don't know what polymorphism is, do you?
> 
> 
> The simplest definition of polymorphism is "same interface, different 
> implementation". This means that different objects can share the same 
> interface but which do different things. What do you think it means?
> 

I rest my case.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/25/2006 4:38:15 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:cY6dnZggTfrJJgPZnZ2dnUVZ_oidnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message

<snip>

>> Just because my understanding and implementation of OOP is different from 
>> yours does not make you right and me wrong.
>>
>
> Other than the fact your understanding and implementation is different 
> from every expert in the field.

What you mean is that people who think like you are the so-called *experts* 
while those who choose to think differently are *idiots*. What an arrogant 
pratt you are to think that YOUR brand of OO is the only true brand.

> You *think* you understand OO.  But you have no idea what *real* OO is 
> about. Otherwise you wouldn't be making some of your comments.

OO is about encapsulation, polymorphism and inheritance. Nothing more, 
nothing less. What you choose to call *real* OO I call *bastardised* OO 
because some people of low intelligence are trying to make it more difficult 
than it really is.

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 5:34:58 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:ms-dnS6A-pd2JgPZnZ2dnUVZ_radnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>
>>>No, Tony, you really don't know what polymorphism is, do you?
>>
>>
>> The simplest definition of polymorphism is "same interface, different 
>> implementation". This means that different objects can share the same 
>> interface but which do different things. What do you think it means?
>>
>
> I rest my case.

Without answering the question, I notice. Is it too difficult for you? I 
take my definition from http://c2.com/cgi/wiki?PolyMorphism and 
http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Where did you 
get yours? The toilet?

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 5:40:26 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:cY6dnZggTfrJJgPZnZ2dnUVZ_oidnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> 
> 
> <snip>
> 
>>>Just because my understanding and implementation of OOP is different from 
>>>yours does not make you right and me wrong.
>>>
>>
>>Other than the fact your understanding and implementation is different 
>>from every expert in the field.
> 
> 
> What you mean is that people who think like you are the so-called *experts* 
> while those who choose to think differently are *idiots*. What an arrogant 
> pratt you are to think that YOUR brand of OO is the only true brand.
> 

My understanding comes from people like Grady Booch, James Rumbaugh and Ivar 
Jacobson - and is in complete agreement with these people.  But of course, they 
disagree with you, so you'll call them idiots, also.
> 
>>You *think* you understand OO.  But you have no idea what *real* OO is 
>>about. Otherwise you wouldn't be making some of your comments.
> 
> 
> OO is about encapsulation, polymorphism and inheritance. Nothing more, 
> nothing less. What you choose to call *real* OO I call *bastardised* OO 
> because some people of low intelligence are trying to make it more difficult 
> than it really is.
> 

Also message passing - which you seem to conveniently forget.  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.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/25/2006 6:16:28 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:ms-dnS6A-pd2JgPZnZ2dnUVZ_radnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>
>>>>No, Tony, you really don't know what polymorphism is, do you?
>>>
>>>
>>>The simplest definition of polymorphism is "same interface, different 
>>>implementation". This means that different objects can share the same 
>>>interface but which do different things. What do you think it means?
>>>
>>
>>I rest my case.
> 
> 
> Without answering the question, I notice. Is it too difficult for you? I 
> take my definition from http://c2.com/cgi/wiki?PolyMorphism and 
> http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Where did you 
> get yours? The toilet?
> 

No need to answer your question.  You're "definition" speaks for itself.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/25/2006 6:17:12 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:ceOdneIn6a2GTgPZnZ2dnUVZ_oWdnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:ms-dnS6A-pd2JgPZnZ2dnUVZ_radnZ2d@comcast.com...
>>
>>>Tony Marston wrote:
>>>
>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>>
>>>>>No, Tony, you really don't know what polymorphism is, do you?
>>>>
>>>>
>>>>The simplest definition of polymorphism is "same interface, different 
>>>>implementation". This means that different objects can share the same 
>>>>interface but which do different things. What do you think it means?
>>>>
>>>
>>>I rest my case.
>>
>>
>> Without answering the question, I notice. Is it too difficult for you? I 
>> take my definition from http://c2.com/cgi/wiki?PolyMorphism and 
>> http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Where did 
>> you get yours? The toilet?
>>
>
> No need to answer your question.  You're "definition" speaks for itself.

You mean that the definition I use is correct while yours is a pile a poo?

My definition is shared by experts. Your definition is shared by people who 
think they're experts.

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 11:02:53 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:cY6dnZggTfrJJgPZnZ2dnUVZ_oidnZ2d@comcast.com...
>>
>>>Tony Marston wrote:
>>>
>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>
>>
>> <snip>
>>
>>>>Just because my understanding and implementation of OOP is different 
>>>>from yours does not make you right and me wrong.
>>>>
>>>
>>>Other than the fact your understanding and implementation is different 
>>>from every expert in the field.
>>
>>
>> What you mean is that people who think like you are the so-called 
>> *experts* while those who choose to think differently are *idiots*. What 
>> an arrogant pratt you are to think that YOUR brand of OO is the only true 
>> brand.
>>
>
> My understanding comes from people like Grady Booch, James Rumbaugh and 
> Ivar Jacobson - and is in complete agreement with these people.  But of 
> course, they disagree with you, so you'll call them idiots, also.
>>
>>>You *think* you understand OO.  But you have no idea what *real* OO is 
>>>about. Otherwise you wouldn't be making some of your comments.
>>
>>
>> OO is about encapsulation, polymorphism and inheritance. Nothing more, 
>> nothing less. What you choose to call *real* OO I call *bastardised* OO 
>> because some people of low intelligence are trying to make it more 
>> difficult than it really is.
>>
>
> Also message passing - which you seem to conveniently forget.

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.

-- 
Tony Marston

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



0
tony155 (869)
6/25/2006 11:06:24 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>news:cY6dnZggTfrJJgPZnZ2dnUVZ_oidnZ2d@comcast.com...
>>>
>>>
>>>>Tony Marston wrote:
>>>>
>>>>
>>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>
>>>
>>><snip>
>>>
>>>>>Just because my understanding and implementation of OOP is different 
>>>>
>>>>>from yours does not make you right and me wrong.
>>>>
>>>>Other than the fact your understanding and implementation is different 
>>>
>>>>from every expert in the field.
>>>
>>>
>>>What you mean is that people who think like you are the so-called 
>>>*experts* while those who choose to think differently are *idiots*. What 
>>>an arrogant pratt you are to think that YOUR brand of OO is the only true 
>>>brand.
>>>
>>
>>My understanding comes from people like Grady Booch, James Rumbaugh and 
>>Ivar Jacobson - and is in complete agreement with these people.  But of 
>>course, they disagree with you, so you'll call them idiots, also.
>>
>>>>You *think* you understand OO.  But you have no idea what *real* OO is 
>>>>about. Otherwise you wouldn't be making some of your comments.
>>>
>>>
>>>OO is about encapsulation, polymorphism and inheritance. Nothing more, 
>>>nothing less. What you choose to call *real* OO I call *bastardised* OO 
>>>because some people of low intelligence are trying to make it more 
>>>difficult than it really is.
>>>
>>
>>Also message passing - which you seem to conveniently forget.
> 
> 
> 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.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/26/2006 12:04:14 AM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>news:cY6dnZggTfrJJgPZnZ2dnUVZ_oidnZ2d@comcast.com...
>>>
>>>
>>>>Tony Marston wrote:
>>>>
>>>>
>>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>
>>>
>>><snip>
>>>
>>>>>Just because my understanding and implementation of OOP is different 
>>>>
>>>>>from yours does not make you right and me wrong.
>>>>
>>>>Other than the fact your understanding and implementation is different 
>>>
>>>>from every expert in the field.
>>>
>>>
>>>What you mean is that people who think like you are the so-called 
>>>*experts* while those who choose to think differently are *idiots*. What 
>>>an arrogant pratt you are to think that YOUR brand of OO is the only true 
>>>brand.
>>>
>>
>>My understanding comes from people like Grady Booch, James Rumbaugh and 
>>Ivar Jacobson - and is in complete agreement with these people.  But of 
>>course, they disagree with you, so you'll call them idiots, also.
>>
>>>>You *think* you understand OO.  But you have no idea what *real* OO is 
>>>>about. Otherwise you wouldn't be making some of your comments.
>>>
>>>
>>>OO is about encapsulation, polymorphism and inheritance. Nothing more, 
>>>nothing less. What you choose to call *real* OO I call *bastardised* OO 
>>>because some people of low intelligence are trying to make it more 
>>>difficult than it really is.
>>>
>>
>>Also message passing - which you seem to conveniently forget.
> 
> 
> 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 the way you use OO is a bastardization of OO techniques.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/26/2006 12:09:40 AM
Tim Van Wassenhove wrote:
> On 2006-06-25, David Haynes <david.haynes2@sympatico.ca> wrote:
> > PHP5 has weak polymorphism but not true polymorphism in the sense that
> > it is used in OOP.
>
> So how would you define polymorphism? And what exactly are the
> differences between 'weak' and 'true' polymorphism?
>
> If i look at http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29
>
> "The concept of polymorphism applies to data types in addition to
> functions. A function that can evaluate to and be applied to values of
> different types is known as a polymorphic function. A data type that
> contains elements of different types is known as a polymorphic data
> type."
>
> > function __construct($one, $two="two", $three="three") {
> >
> > I cannot instantiate this object as new Foo($one, $three) since there is
> > no typing on the arguments and, therefore, no signature for a 'one,
> > three' contructor. .
>
> Imho that's the same as saying: I'm standing with my back against a wall,
> and now i'm wondering why i can't step backwards anymore...
>
> Define your constructor as __constructor($args) and handle with
> func_num_args and func_get_args(s) any number of parameters...
>
> (I do agree that the language/compiler can, probably should, make this
> easier... But that's a different discussion.)
>
> --
> Met vriendelijke groeten,
> Tim Van Wassenhove <http://timvw.madoka.be>


There are two annoying problems with this, which is why its such a nice
feature to have:

1) It is a pain in the but to have to order out and determine the types
of the passed variables.  Whenever I make classes i always end up
having to spend 100+ lines trying to figure out the types of variables
passed to sort out what goes where.  Why?  One object returns an
indexed array, another an associative array, other return other objects
of various types.  The reason for being able to call the function with
any of these types is so that I don't have to pre-process the data and
can operate more efficently on the passed value.  What ends up
happening is converting everything to an array, or string, or object,
or what not.  A lot of extra work on my part and the program's part
that would otherwise be handled by a compiler.

They have type hints in PHP5, but they are more like type requirements,
as it causes a fatal error and is largely useless unless you
pre-process things to match that definition.  I'd much rather be able
to create multiple methods with different signatures that could be
called if the parameters match, but thats not really feasible in a
typeless language.

2) It makes overriding methods harder in derived classes.  Why?
Because the overridden method is completely hidden and you must convert
parameters to what it expects to be able to use its functionality.
This happened to me while extending HTML_Table from pear.  Its addRow
method accepts 2 types of arrays, and invokes different completely code
paths depending on the array type, which is determined by a private
method thats not (well, shouldn't be) accesible from the derived class.


Ideally, all i would have to do is override addRow, modify the incoming
data to match what the original addRow expects, then pass it up.
Extension with minimum effort.  However, because the addRow method uses
several private methods and a bunch of code and logic to determine what
to do, I either have to:
 - Duplicate all that logic and code (including the private methods,
default values, etc), then pass it up to addRow to have it done again,
which is a lot of redunant work, or
 - Pass it up to addRow then modify the object accordingly, which
performs several of the same operations addRow did originally (as well
as introducing a caveat of overwriting instead of updating certain
attributes, which limits the functionality in a few cases).

If i could just override the method to accept the single object i
wanted to pass it, while the original method existed and could be
called directly, all of that could have been avoided.

Then there is the lack of multiple inheritence in PHP.  Considering the
wide breadth of small operations a single object should be able to do,
its completely insane to have to rewrite the exact same interface code
again and again for the smallest of operations (a problem that rears
its head in java gui programing, when you have to implement an
interface then manually delegate all methods to an instance of a class
that has a handle back to the container, more needless complication
that could have been handled by MI).  I'm getting off topic though.
Please, continue the flame war.

0
richardlev (182)
6/26/2006 8:03:14 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:GcmdnahZBuoluALZnZ2dnUVZ_vednZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@comcast.com...
>>
<snip>
>>
>>>>OO is about encapsulation, polymorphism and inheritance. Nothing more, 
>>>>nothing less. What you choose to call *real* OO I call *bastardised* OO 
>>>>because some people of low intelligence are trying to make it more 
>>>>difficult than it really is.
>>>>
>>>
>>>Also message passing - which you seem to conveniently forget.
>>
>>
>> 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 the way you use OO is a bastardization of OO techniques.

That's just your opinion. Just because my implementation of OO is different 
from yours does not make it wrong, merely different. If you believe that 
YOUR way is the ONLY way then you are just being arrogant.

-- 
Tony Marston

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



0
tony155 (869)
6/26/2006 8:09:33 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:tMydnfBVrd_suQLZnZ2dnUVZ_o6dnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@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.

-- 
Tony Marston

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



0
tony155 (869)
6/26/2006 8:13:32 AM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:tMydnfBVrd_suQLZnZ2dnUVZ_o6dnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@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.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/26/2006 10:37:00 AM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:GcmdnahZBuoluALZnZ2dnUVZ_vednZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@comcast.com...
>>>
> 
> <snip>
> 
>>>>>OO is about encapsulation, polymorphism and inheritance. Nothing more, 
>>>>>nothing less. What you choose to call *real* OO I call *bastardised* OO 
>>>>>because some people of low intelligence are trying to make it more 
>>>>>difficult than it really is.
>>>>>
>>>>
>>>>Also message passing - which you seem to conveniently forget.
>>>
>>>
>>>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 the way you use OO is a bastardization of OO techniques.
> 
> 
> That's just your opinion. Just because my implementation of OO is different 
> from yours does not make it wrong, merely different. If you believe that 
> YOUR way is the ONLY way then you are just being arrogant.
> 

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

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

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

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/26/2006 10:41:26 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:7fCdnbmMO7sjJQLZnZ2dnUVZ_tidnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:tMydnfBVrd_suQLZnZ2dnUVZ_o6dnZ2d@comcast.com...
>>
>>>Tony Marston wrote:
>>>
>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@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?

-- 
Tony Marston

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



0
tony155 (869)
6/26/2006 4:31:05 PM
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.
0
news18670 (95)
6/26/2006 4:32:05 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:qe-dnUu6EIRUJALZnZ2dnUVZ_vSdnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:GcmdnahZBuoluALZnZ2dnUVZ_vednZ2d@comcast.com...
>>
>>>Tony Marston wrote:
>>>
>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@comcast.com...
>>>>
>>
>> <snip>
>>
>>>>>>OO is about encapsulation, polymorphism and inheritance. Nothing more, 
>>>>>>nothing less. What you choose to call *real* OO I call *bastardised* 
>>>>>>OO because some people of low intelligence are trying to make it more 
>>>>>>difficult than it really is.
>>>>>>
>>>>>
>>>>>Also message passing - which you seem to conveniently forget.
>>>>
>>>>
>>>>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 the way you use OO is a bastardization of OO techniques.
>>
>>
>> That's just your opinion. Just because my implementation of OO is 
>> different from yours does not make it wrong, merely different. If you 
>> believe that YOUR way is the ONLY way then you are just being arrogant.
>>
>
> 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.

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

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

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

-- 
Tony Marston

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



0
tony155 (869)
6/26/2006 4:41:10 PM
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.

0
richardlev (182)
6/26/2006 5:29:22 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:7fCdnbmMO7sjJQLZnZ2dnUVZ_tidnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>news:tMydnfBVrd_suQLZnZ2dnUVZ_o6dnZ2d@comcast.com...
>>>
>>>
>>>>Tony Marston wrote:
>>>>
>>>>
>>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>>news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@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/SoftwareEngineering/ObjectOrientedDesign.shtml
http://en.wikipedia.org/wiki/Object-oriented_programming
http://www.awprofessional.com/bookstore/product.asp?isbn=0201824191&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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/27/2006 12:58:35 AM
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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/27/2006 1:03:05 AM
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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/27/2006 1:15:26 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:Teadndafls4zHz3ZnZ2dnUVZ_v-dnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:7fCdnbmMO7sjJQLZnZ2dnUVZ_tidnZ2d@comcast.com...
>>
>>>Tony Marston wrote:
>>>
>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>news:tMydnfBVrd_suQLZnZ2dnUVZ_o6dnZ2d@comcast.com...
>>>>
>>>>
>>>>>Tony Marston wrote:
>>>>>
>>>>>
>>>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>>>news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@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/SoftwareEngineering/ObjectOrientedDesign.shtml
> http://en.wikipedia.org/wiki/Object-oriented_programming
> http://www.awprofessional.com/bookstore/product.asp?isbn=0201824191&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?PolymorphismEncapsulationInheritance
http://en.wikipedia.org/wiki/Object-oriented_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 


0
tony155 (869)
6/27/2006 8:58:44 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:CbWdnQMrCZUgHj3ZnZ2dnUVZ_rGdnZ2d@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 


0
tony155 (869)
6/27/2006 9:08:26 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:IrOdnQkOaac8Gz3ZnZ2dnUVZ_omdnZ2d@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/jw-05-2001/jw-0518-encapsulation.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.
> jstucklex@attglobal.net
> ================== 


0
tony155 (869)
6/27/2006 9:12:21 AM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:Teadndafls4zHz3ZnZ2dnUVZ_v-dnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>news:7fCdnbmMO7sjJQLZnZ2dnUVZ_tidnZ2d@comcast.com...
>>>
>>>
>>>>Tony Marston wrote:
>>>>
>>>>
>>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>>news:tMydnfBVrd_suQLZnZ2dnUVZ_o6dnZ2d@comcast.com...
>>>>>
>>>>>
>>>>>
>>>>>>Tony Marston wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>>>>news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@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/SoftwareEngineering/ObjectOrientedDesign.shtml
>>http://en.wikipedia.org/wiki/Object-oriented_programming
>>http://www.awprofessional.com/bookstore/product.asp?isbn=0201824191&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?PolymorphismEncapsulationInheritance
> http://en.wikipedia.org/wiki/Object-oriented_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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/27/2006 11:00:52 AM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:CbWdnQMrCZUgHj3ZnZ2dnUVZ_rGdnZ2d@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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/27/2006 11:09:12 AM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:IrOdnQkOaac8Gz3ZnZ2dnUVZ_omdnZ2d@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/jw-05-2001/jw-0518-encapsulation.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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/27/2006 11:13:43 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:T4SdnWif9KBWjDzZnZ2dnUVZ_oGdnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:CbWdnQMrCZUgHj3ZnZ2dnUVZ_rGdnZ2d@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 


0
tony155 (869)
6/27/2006 2:40:02 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:oMSdndxexPBAjzzZnZ2dnUVZ_tidnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:IrOdnQkOaac8Gz3ZnZ2dnUVZ_omdnZ2d@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/jw-05-2001/jw-0518-encapsulation.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 


0
tony155 (869)
6/27/2006 2:43:19 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:T4SdnWif9KBWjDzZnZ2dnUVZ_oGdnZ2d@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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/27/2006 3:00:22 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:7sudnawIL7dKkjzZnZ2dnUVZ_v-dnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:Teadndafls4zHz3ZnZ2dnUVZ_v-dnZ2d@comcast.com...
>>
>>>Tony Marston wrote:
>>>
>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>news:7fCdnbmMO7sjJQLZnZ2dnUVZ_tidnZ2d@comcast.com...
>>>>
>>>>
>>>>>Tony Marston wrote:
>>>>>
>>>>>
>>>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>>>news:tMydnfBVrd_suQLZnZ2dnUVZ_o6dnZ2d@comcast.com...
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Tony Marston wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>>>>>>news:ceOdneMn6a1vTwPZnZ2dnUVZ_oWdnZ2d@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/SoftwareEngineering/ObjectOrientedDesign.shtml
>>>http://en.wikipedia.org/wiki/Object-oriented_programming
>>>http://www.awprofessional.com/bookstore/product.asp?isbn=0201824191&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?PolymorphismEncapsulationInheritance
>> http://en.wikipedia.org/wiki/Object-oriented_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 


0
tony155 (869)
6/27/2006 3:00:23 PM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:oMSdndxexPBAjzzZnZ2dnUVZ_tidnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>news:IrOdnQkOaac8Gz3ZnZ2dnUVZ_omdnZ2d@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/jw-05-2001/jw-0518-encapsulation.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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/27/2006 3:01:35 PM
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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/27/2006 8:37:57 PM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:HNadnet0zsaECjzZnZ2dnUVZ_uudnZ2d@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



0
tony155 (869)
6/27/2006 11:53:15 PM
"Tony Marston" <tony@NOSPAM.demon.co.uk> and
"Jerry Stuckle" <jstucklex@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.


0
Jim
6/28/2006 12:13:35 AM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:HNadnet0zsaECjzZnZ2dnUVZ_uudnZ2d@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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/28/2006 12:27:49 AM
Jim Carlock wrote:
> "Tony Marston" <tony@NOSPAM.demon.co.uk> and
> "Jerry Stuckle" <jstucklex@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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/28/2006 2:49:21 AM
"Jim Carlock" <anonymous@127.0.0.1> wrote in message 
news:PQjog.21061$LT2.18735@tornado.tampabay.rr.com...
> "Tony Marston" <tony@NOSPAM.demon.co.uk> and
> "Jerry Stuckle" <jstucklex@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/sample-application.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



0
tony155 (869)
6/28/2006 8:11:43 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:WJSdnXcda45lUTzZnZ2dnUVZ_oKdnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:HNadnet0zsaECjzZnZ2dnUVZ_uudnZ2d@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



0
tony155 (869)
6/28/2006 8:16:33 AM
Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:WJSdnXcda45lUTzZnZ2dnUVZ_oKdnZ2d@comcast.com...
> 
>>Tony Marston wrote:
>>
>>>"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>news:HNadnet0zsaECjzZnZ2dnUVZ_uudnZ2d@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.
> 

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.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
6/28/2006 11:01:22 AM
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:8sCdnSW4dsbo_D_ZnZ2dnUVZ_qSdnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:WJSdnXcda45lUTzZnZ2dnUVZ_oKdnZ2d@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




0
tony155 (869)
6/28/2006 2:10:23 PM
Reply: