php 5 classes: public, protected and private

[jopperdepopper]

Hi,

finally giving php 5 a go, and going over the new approach to classes.
Can someone clarify the public, private and protected to me?

I quote the php manual: "The visibility of a property or method can be
defined by prefixing the declaration with the keywords: public,
protected or private. Public declared items can be accessed
everywhere."

But should I read "...can be accessed everywhere within a given class."
or "...can be accessed by all other classes." ?

Job

[Jerry Stuckle]

Re: php 5 classes: public, protected and private

jopperdepopper wrote:

Hi,
>
finally giving php 5 a go, and going over the new approach to classes.
Can someone clarify the public, private and protected to me?
>
I quote the php manual: "The visibility of a property or method can be
defined by prefixing the declaration with the keywords: public,
protected or private. Public declared items can be accessed
everywhere."
>
But should I read "...can be accessed everywhere within a given class."
or "...can be accessed by all other classes." ?
>
Job
>

Job,

You should read "can be accessed everywhere".

Private members can be accessed by members of the class only.
Protected members can be accessed by members of the class or a derived
class.
Public members can be accessed by anyone, including other classes,
functions and any other code.

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

[jopperdepopper]

Re: php 5 classes: public, protected and private

>
You should read "can be accessed everywhere".
>
Private members can be accessed by members of the class only.
Protected members can be accessed by members of the class or a derived
class.
Public members can be accessed by anyone, including other classes,
functions and any other code.

Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
to classes, and so far having a hard time. I fail to see the 'why'
behind the 'public, protected and private' and stuff like abstraction,
interfaces and whatnot. Feels like things are being over-complicated
somehow... or it's just my being inexperienced on this...

Any other reading material on this suggested, someone?

[Jerry Stuckle]

Re: php 5 classes: public, protected and private

jopperdepopper wrote:

>>You should read "can be accessed everywhere".
>>
>>Private members can be accessed by members of the class only.
>>Protected members can be accessed by members of the class or a derived
>>class.
>>Public members can be accessed by anyone, including other classes,
>>functions and any other code.

>
>
>
Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
to classes, and so far having a hard time. I fail to see the 'why'
behind the 'public, protected and private' and stuff like abstraction,
interfaces and whatnot. Feels like things are being over-complicated
somehow... or it's just my being inexperienced on this...
>
Any other reading material on this suggested, someone?
>

Look for some good books on OO theory and design.

Two of the concepts in OO are 'encapsulation' and 'methods'.

Encapsulation means the internals of an object are managed only by that
object and are not available to anyone else. In PHP these are private
members.

Methods are implemented as functions in PHP. They operate on the object.

The idea is to completely separate the implementation of the class from
the use of it. It means you can change the class any way you want. As
long as the public interface remains the same, it makes no difference.

A good example of this is floating point numbers. They are stored as a

x * 2^y

X is the mantissa, y is the base 2 exponent. For instance, 8 would be
stored as x=1 and y=3, because 8 is 1 * 2^3. But all of this is hidden
behind the scenes; you can do operations on a floating point number such
as add, subtract, print, etc.

And if at some other time PHP changed the implementation to something
else, none of your code would change.

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

[jopperdepopper]

Re: php 5 classes: public, protected and private

Look for some good books on OO theory and design.
>

Thanks Jerry, maybe the php 5 approach is a better implementation than
the php 4 approach? I have always felt that in php 4 using classes (or
at least my way of using them) was more a convenient way to organise
code, grouping some related functions in one class, other related ones
in another...

Gotta get me some books & hope it's going to be a loooong coooold
winter ;)

[Jerry Stuckle]

Re: php 5 classes: public, protected and private

jopperdepopper wrote:

>>Look for some good books on OO theory and design.
>>

>
>
Thanks Jerry, maybe the php 5 approach is a better implementation than
the php 4 approach? I have always felt that in php 4 using classes (or
at least my way of using them) was more a convenient way to organise
code, grouping some related functions in one class, other related ones
in another...
>
Gotta get me some books & hope it's going to be a loooong coooold
winter ;)
>

Yes, I think it is - but then I've been doing OO programming for a
number of years, both in C++ and Java.

Classes are a good way to organize code - but more importantly, they are
a way of organizing code AND DATA. A properly constructed class should,
as much as possible, manage it's own data independent of other classes
and code.

It's a whole different way of thinking which is usually quite a jump for
experienced programmers. In fact, I find newer programmers typically
have less problems, because structured code techniques are not so deeply
ingrained in their mind. :-)

But it's well worth it; the resulting code can be much more readable and
maintainable.

A good example. I needed to implement some pages based on a database.
However, the particular host being used at the time did not have MySQL
available (they claimed they did, but it wasn't very reliable...).

So I implemented the code in flat files using a class for the data being
displayed, and pages to use that class. Later, when they changed to a
host which had MySQL, all I had to do was go back to the class and
change it to read from a database instead of a flat file. No changes to
the pages were needed at all. Very clean and easy to do, because I
segregated the operations on the data in the class, and used the web
page code just to display the data.


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

[Tony Marston]

Re: php 5 classes: public, protected and private


"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
news:Ib6dna_BtY QSifbYnZ2dnUVZ_ sSdnZ2d@comcast .com...

jopperdepopper wrote:

>>>You should read "can be accessed everywhere".
>>>
>>>Private members can be accessed by members of the class only.
>>>Protected members can be accessed by members of the class or a derived
>>>class.
>>>Public members can be accessed by anyone, including other classes,
>>>functions and any other code.

>>
>>
>>
>Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
>to classes, and so far having a hard time. I fail to see the 'why'
>behind the 'public, protected and private' and stuff like abstraction,
>interfaces and whatnot.

Intefaces are not necessary in PHP. Once you have defined a method it is a
total waste to time to also define an interface. Interfaces are a "fix" in
those languages as a means of dealing with optional arguments and statyic
typing. PHP has ifferent ways of dealing with bth of these, therefore
interfaces serve no useful purpose.

>Feels like things are being over-complicated
>somehow... or it's just my being inexperienced on this...
>>
>Any other reading material on this suggested, someone?
>>

>
Look for some good books on OO theory and design.
>
Two of the concepts in OO are 'encapsulation' and 'methods'.
>
Encapsulation means the internals of an object are managed only by that
object and are not available to anyone else. In PHP these are private
members.

Wrong. Encapsulation means that the data and the functions which operate on
that data are contained (encapsulated) within a single object. While the
methods (functions) thenselves may be visible the code behind those methods
(i.e. the implementaton behind those methods) is not. Encapslation is NOT
about hiding information, it is about hiding the implementation. It is not
necessary to use public/private/protected on any methods or properties. It
does not add any functionality, it merely creates restrictions which often
get in the way.

Methods are implemented as functions in PHP. They operate on the object.

That's one thing you got right.

--
Tony Marston

http://www.tonymarston.net

http://www.radicore.org

[Michael Fesser]

Re: php 5 classes: public, protected and private

..oO(Tony Marston)

>Intefaces are not necessary in PHP. Once you have defined a method it is a
>total waste to time to also define an interface. Interfaces are a "fix" in
>those languages as a means of dealing with optional arguments and statyic
>typing. PHP has ifferent ways of dealing with bth of these, therefore
>interfaces serve no useful purpose.

What's called an interface in PHP is a completely different mechanism
than what you described above.

>Wrong. Encapsulation means that the data and the functions which operate on
>that data are contained (encapsulated) within a single object. While the
>methods (functions) thenselves may be visible the code behind those methods
>(i.e. the implementaton behind those methods) is not. Encapslation is NOT
>about hiding information, it is about hiding the implementation. It is not
>necessary to use public/private/protected on any methods or properties.

Of course it is necessary.

>It
>does not add any functionality, it merely creates restrictions which often
>get in the way.

It prevents developers from doing things that shouldn't be done, for
example calling an internal method out of context. I don't want all my
methods being publicly available, simply in order to avoid errors and
unpredictable results.

Micha

[Jerry Stuckle]

Re: php 5 classes: public, protected and private

Tony Marston wrote:

"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
news:Ib6dna_BtY QSifbYnZ2dnUVZ_ sSdnZ2d@comcast .com...
>

>>jopperdepoppe r wrote:
>>

>>>>You should read "can be accessed everywhere".
>>>>
>>>>Private members can be accessed by members of the class only.
>>>>Protected members can be accessed by members of the class or a derived
>>>>class.
>>>>Public members can be accessed by anyone, including other classes,
>>>>functions and any other code.
>>>
>>>
>>>
>>>Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
>>>to classes, and so far having a hard time. I fail to see the 'why'
>>>behind the 'public, protected and private' and stuff like abstraction,
>>>interfaces and whatnot.

>
>
Intefaces are not necessary in PHP. Once you have defined a method it is a
total waste to time to also define an interface. Interfaces are a "fix" in
those languages as a means of dealing with optional arguments and statyic
typing. PHP has ifferent ways of dealing with bth of these, therefore
interfaces serve no useful purpose.
>

Ah, the great Tony Marston is back to trolling again.

Wrong. In OO terms, the interface is the way to interact with the
object. It consists of all public members - both methods (functions, in
PHP) and variables. And for derived classes, the base class adds
protected members.

A PHP interface is something entirely different.

>

>>>Feels like things are being over-complicated
>>>somehow... or it's just my being inexperienced on this...
>>>
>>>Any other reading material on this suggested, someone?
>>>

>>
>>Look for some good books on OO theory and design.
>>
>>Two of the concepts in OO are 'encapsulation' and 'methods'.
>>
>>Encapsulati on means the internals of an object are managed only by that
>>object and are not available to anyone else. In PHP these are private
>>members.

>
>
Wrong. Encapsulation means that the data and the functions which operate on
that data are contained (encapsulated) within a single object. While the
methods (functions) thenselves may be visible the code behind those methods
(i.e. the implementaton behind those methods) is not. Encapslation is NOT
about hiding information, it is about hiding the implementation. It is not
necessary to use public/private/protected on any methods or properties. It
does not add any functionality, it merely creates restrictions which often
get in the way.
>

Wrong again, Tony. Encapsulation means internal representations of the
object are not visible outside of the class. Just like the base &
mantissa are not visible outside of a floating point number.

>

>>Methods are implemented as functions in PHP. They operate on the object.

>
>
That's one thing you got right.
>

More than you got right. Go crawl back into your hole and don't come
out again until you know what you're talking about.

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

[Tony Marston]

Re: php 5 classes: public, protected and private


"Michael Fesser" <netizen@gmx.de wrote in message
news:fdvmm2hngs te2mc3v3q50g23g gkra6u2js@4ax.c om...

.oO(Tony Marston)
>

>>Intefaces are not necessary in PHP. Once you have defined a method it is a
>>total waste to time to also define an interface. Interfaces are a "fix" in
>>those languages as a means of dealing with optional arguments and statyic
>>typing. PHP has ifferent ways of dealing with bth of these, therefore
>>interfaces serve no useful purpose.

>
What's called an interface in PHP is a completely different mechanism
than what you described above.

I disagree. It is possible to define a function (method) within a class,
then to define a separate thng called an "interface" . It is possible access
he function without using the interface, therefore the inteface is not
necessary.

>>Wrong. Encapsulation means that the data and the functions which operate
>>on
>>that data are contained (encapsulated) within a single object. While the
>>methods (functions) thenselves may be visible the code behind those
>>methods
>>(i.e. the implementaton behind those methods) is not. Encapslation is NOT
>>about hiding information, it is about hiding the implementation. It is not
>>necessary to use public/private/protected on any methods or properties.

>
Of course it is necessary.

I disagree. it is *not* necessary for the simple reason that the code will
perform exactly the same function whether methods and properties are marked
as public/private/protected or not.

>>It
>>does not add any functionality, it merely creates restrictions which often
>>get in the way.

That is why I said "It does not add any functionality, it merely creates
restrictions"

It prevents developers from doing things that shouldn't be done, for
example calling an internal method out of context. I don't want all my
methods being publicly available, simply in order to avoid errors and
unpredictable results.

That is a matter for programmer discipline, it is not a matter of additional
functionality. The code will do exactly the same with or without it.

--
Tony Marston

http://www.tonymarston.net

http://www.radicore.org

[Tony Marston]

Re: php 5 classes: public, protected and private


"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
news:j9-dnQB80fVLOvbYnZ 2dnUVZ_rOdnZ2d@ comcast.com...

Tony Marston wrote:

>"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
>news:Ib6dna_Bt YQSifbYnZ2dnUVZ _sSdnZ2d@comcas t.com...
>>

>>>jopperdepopp er wrote:
>>>
>>>>>You should read "can be accessed everywhere".
>>>>>
>>>>>Private members can be accessed by members of the class only.
>>>>>Protecte d members can be accessed by members of the class or a derived
>>>>>class.
>>>>>Public members can be accessed by anyone, including other classes,
>>>>>function s and any other code.
>>>>
>>>>
>>>>
>>>>Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
>>>>to classes, and so far having a hard time. I fail to see the 'why'
>>>>behind the 'public, protected and private' and stuff like abstraction,
>>>>interface s and whatnot.

>>
>>
>Intefaces are not necessary in PHP. Once you have defined a method it is
>a total waste to time to also define an interface. Interfaces are a "fix"
>in those languages as a means of dealing with optional arguments and
>statyic typing. PHP has ifferent ways of dealing with bth of these,
>therefore interfaces serve no useful purpose.
>>

>
Ah, the great Tony Marston is back to trolling again.
>
Wrong. In OO terms, the interface is the way to interact with the object.
It consists of all public members - both methods (functions, in PHP) and
variables. And for derived classes, the base class adds protected
members.
>
A PHP interface is something entirely different.

I disagree. It is possible to define a function (method) within a class,
then to define a separate thing called an "interface" . It is possible access
the function without using the interface, therefore the interface is not
necessary.

>>

>>>>Feels like things are being over-complicated
>>>>somehow.. . or it's just my being inexperienced on this...
>>>>
>>>>Any other reading material on this suggested, someone?
>>>>
>>>
>>>Look for some good books on OO theory and design.
>>>
>>>Two of the concepts in OO are 'encapsulation' and 'methods'.
>>>
>>>Encapsulatio n means the internals of an object are managed only by that
>>>object and are not available to anyone else. In PHP these are private
>>>members.

>>
>>
>Wrong. Encapsulation means that the data and the functions which operate
>on that data are contained (encapsulated) within a single object. While
>the methods (functions) thenselves may be visible the code behind those
>methods (i.e. the implementaton behind those methods) is not.
>Encapslation is NOT about hiding information, it is about hiding the
>implementation . It is not necessary to use public/private/protected on
>any methods or properties. It does not add any functionality, it merely
>creates restrictions which often get in the way.
>>

>
Wrong again, Tony. Encapsulation means internal representations of the
object are not visible outside of the class. Just like the base &
mantissa are not visible outside of a floating point number.

I disagree. Encapsulation means that both the data and the methods which
operate on that data are contained within a single unit or "capsule". The
data names and the method names may be visible, it is only the code which
lies behind each method name which is invisible. A piece of data may be
accessed directly, as in $object->var, or it may be accessed through a
getter, as in $object->getVar().

If you bothered to read the right books you will see that encapsulation
means "implementa tion hiding" and not "informatio n hiding".

>>

>>>Methods are implemented as functions in PHP. They operate on the object.

>>
>>
>That's one thing you got right.
>>

>
More than you got right. Go crawl back into your hole and don't come out
again until you know what you're talking about.

I do know what I'm talking about..

--
Tony Marston

http://www.tonymarston.net

http://www.radicore.org

[Jerry Stuckle]

Re: php 5 classes: public, protected and private

Tony Marston wrote:

"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
news:j9-dnQB80fVLOvbYnZ 2dnUVZ_rOdnZ2d@ comcast.com...
>

>>Tony Marston wrote:
>>

>>>"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
>>>news:Ib6dna_ BtYQSifbYnZ2dnU VZ_sSdnZ2d@comc ast.com...
>>>
>>>
>>>>jopperdepop per wrote:
>>>>
>>>>
>>>>>>You should read "can be accessed everywhere".
>>>>>>
>>>>>>Private members can be accessed by members of the class only.
>>>>>>Protect ed members can be accessed by members of the class or a derived
>>>>>>class.
>>>>>>Public members can be accessed by anyone, including other classes,
>>>>>>functio ns and any other code.
>>>>>
>>>>>
>>>>>
>>>>>Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
>>>>>to classes, and so far having a hard time. I fail to see the 'why'
>>>>>behind the 'public, protected and private' and stuff like abstraction,
>>>>>interfac es and whatnot.
>>>
>>>
>>>Intefaces are not necessary in PHP. Once you have defined a method it is
>>>a total waste to time to also define an interface. Interfaces are a "fix"
>>>in those languages as a means of dealing with optional arguments and
>>>statyic typing. PHP has ifferent ways of dealing with bth of these,
>>>therefore interfaces serve no useful purpose.
>>>

>>
>>Ah, the great Tony Marston is back to trolling again.
>>
>>Wrong. In OO terms, the interface is the way to interact with the object.
>>It consists of all public members - both methods (functions, in PHP) and
>>variables. And for derived classes, the base class adds protected
>>members.
>>
>>A PHP interface is something entirely different.

>
>
I disagree. It is possible to define a function (method) within a class,
then to define a separate thing called an "interface" . It is possible access
the function without using the interface, therefore the interface is not
necessary.
>

Tony,

You really need to learn about OO before spouting off. In OO terms, an
interface is something entirely different than a PHP interface.

PHP is not the only OO language. Some don't even have a term
"interface" as part of the language. But the still have an interface.

Try some of the books by James Rumbaugh, Grady Booch and/or Ivar Jacobson.

>

>>>>>Feels like things are being over-complicated
>>>>>somehow. .. or it's just my being inexperienced on this...
>>>>>
>>>>>Any other reading material on this suggested, someone?
>>>>>
>>>>
>>>>Look for some good books on OO theory and design.
>>>>
>>>>Two of the concepts in OO are 'encapsulation' and 'methods'.
>>>>
>>>>Encapsulati on means the internals of an object are managed only by that
>>>>object and are not available to anyone else. In PHP these are private
>>>>members.
>>>
>>>
>>>Wrong. Encapsulation means that the data and the functions which operate
>>>on that data are contained (encapsulated) within a single object. While
>>>the methods (functions) thenselves may be visible the code behind those
>>>methods (i.e. the implementaton behind those methods) is not.
>>>Encapslati on is NOT about hiding information, it is about hiding the
>>>implementati on. It is not necessary to use public/private/protected on
>>>any methods or properties. It does not add any functionality, it merely
>>>creates restrictions which often get in the way.
>>>

>>
>>Wrong again, Tony. Encapsulation means internal representations of the
>>object are not visible outside of the class. Just like the base &
>>mantissa are not visible outside of a floating point number.

>
>
I disagree. Encapsulation means that both the data and the methods which
operate on that data are contained within a single unit or "capsule". The
data names and the method names may be visible, it is only the code which
lies behind each method name which is invisible. A piece of data may be
accessed directly, as in $object->var, or it may be accessed through a
getter, as in $object->getVar().
>
If you bothered to read the right books you will see that encapsulation
means "implementa tion hiding" and not "informatio n hiding".
>

Again, read the experts before spouting off. You have repeatedly shown
how little you understand about OO programming techniques.

And yes, encapsulation is "implementa tion hiding". And the variables
are part of the IMPLEMENTATION.

>

>>>>Methods are implemented as functions in PHP. They operate on the object.
>>>
>>>
>>>That's one thing you got right.
>>>

>>
>>More than you got right. Go crawl back into your hole and don't come out
>>again until you know what you're talking about.

>
>
I do know what I'm talking about..
>

Then why do you continually disagree with the recognized experts in the
OO community, like the ones I mentioned above?


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

[Tony Marston]

Re: php 5 classes: public, protected and private


"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
news:PeudnRKltL JsufHYnZ2dnUVZ_ u2dnZ2d@comcast .com...

Tony Marston wrote:

>"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
>news:j9-dnQB80fVLOvbYnZ 2dnUVZ_rOdnZ2d@ comcast.com...
>>

>>>Tony Marston wrote:
>>>
>>>>"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
>>>>news:Ib6dna _BtYQSifbYnZ2dn UVZ_sSdnZ2d@com cast.com...
>>>>
>>>>
>>>>>jopperdepo pper wrote:
>>>>>
>>>>>
>>>>>>>You should read "can be accessed everywhere".
>>>>>>>
>>>>>>>Privat e members can be accessed by members of the class only.
>>>>>>>Protecte d members can be accessed by members of the class or a
>>>>>>>derive d
>>>>>>>class.
>>>>>>>Public members can be accessed by anyone, including other classes,
>>>>>>>function s and any other code.
>>>>>>
>>>>>>
>>>>>>
>>>>>>Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
>>>>>>to classes, and so far having a hard time. I fail to see the 'why'
>>>>>>behind the 'public, protected and private' and stuff like abstraction,
>>>>>>interface s and whatnot.
>>>>
>>>>
>>>>Intefaces are not necessary in PHP. Once you have defined a method it is
>>>>a total waste to time to also define an interface. Interfaces are a
>>>>"fix" in those languages as a means of dealing with optional arguments
>>>>and statyic typing. PHP has ifferent ways of dealing with bth of these,
>>>>therefore interfaces serve no useful purpose.
>>>>
>>>
>>>Ah, the great Tony Marston is back to trolling again.
>>>
>>>Wrong. In OO terms, the interface is the way to interact with the
>>>object. It consists of all public members - both methods (functions, in
>>>PHP) and variables. And for derived classes, the base class adds
>>>protected members.
>>>
>>>A PHP interface is something entirely different.

>>
>>
>I disagree. It is possible to define a function (method) within a class,
>then to define a separate thing called an "interface" . It is possible
>access
>the function without using the interface, therefore the interface is not
>necessary.
>>

>
Tony,
>
You really need to learn about OO before spouting off. In OO terms, an
interface is something entirely different than a PHP interface.

How so? All the documentation I have seen describes how an interface simply
describes a method which it imlements. If it is possible to access a method
(a function in PHP) without going though an interface, ten an interface is
not necessary in any language.

PHP is not the only OO language. Some don't even have a term "interface"
as part of the language. But the still have an interface.
>
Try some of the books by James Rumbaugh, Grady Booch and/or Ivar Jacobson.
>

>>

>>>>>>Feels like things are being over-complicated
>>>>>>somehow.. . or it's just my being inexperienced on this...
>>>>>>
>>>>>>Any other reading material on this suggested, someone?
>>>>>>
>>>>>
>>>>>Look for some good books on OO theory and design.
>>>>>
>>>>>Two of the concepts in OO are 'encapsulation' and 'methods'.
>>>>>
>>>>>Encapsulat ion means the internals of an object are managed only by that
>>>>>object and are not available to anyone else. In PHP these are private
>>>>>members.
>>>>
>>>>
>>>>Wrong. Encapsulation means that the data and the functions which operate
>>>>on that data are contained (encapsulated) within a single object. While
>>>>the methods (functions) thenselves may be visible the code behind those
>>>>methods (i.e. the implementaton behind those methods) is not.
>>>>Encapslatio n is NOT about hiding information, it is about hiding the
>>>>implementat ion. It is not necessary to use public/private/protected on
>>>>any methods or properties. It does not add any functionality, it merely
>>>>creates restrictions which often get in the way.
>>>>
>>>
>>>Wrong again, Tony. Encapsulation means internal representations of the
>>>object are not visible outside of the class. Just like the base &
>>>mantissa are not visible outside of a floating point number.

>>
>>
>I disagree. Encapsulation means that both the data and the methods which
>operate on that data are contained within a single unit or "capsule". The
>data names and the method names may be visible, it is only the code which
>lies behind each method name which is invisible. A piece of data may be
>accessed directly, as in $object->var, or it may be accessed through a
>getter, as in $object->getVar().
>>
>If you bothered to read the right books you will see that encapsulation
>means "implementa tion hiding" and not "informatio n hiding".
>>

>
Again, read the experts before spouting off. You have repeatedly shown
how little you understand about OO programming techniques.
>
And yes, encapsulation is "implementa tion hiding". And the variables are
part of the IMPLEMENTATION.

I disagree. Inplementation is code, information is data. If you don't
believe me then read "Encapsulat ion is not information hiding" at
http://www.javaworld.com/javaworld/j...psulation.html and
also "Abstractio n, Encapsulation, and Information Hiding" at

http://www.itmweb.com/essay550.htm

>>

>>>>>Methods are implemented as functions in PHP. They operate on the
>>>>>object.
>>>>
>>>>
>>>>That's one thing you got right.
>>>>
>>>
>>>More than you got right. Go crawl back into your hole and don't come out
>>>again until you know what you're talking about.

>>
>>
>I do know what I'm talking about..
>>

>
Then why do you continually disagree with the recognized experts in the OO
community, like the ones I mentioned above?

I disagree with YOU simply because you clam to be a recognised expert when
in fact you are no such thing. I keep finding papers on the internet which
disagree with your explanations, yet you persist in claiming that you are
right and everybody who dares to disagree with you is wrong. Such arrogance!

--
Tony Marston

http://www.tonymarston.net

http://www.radicore.org

[Jerry Stuckle]

Re: php 5 classes: public, protected and private

Tony Marston wrote:

"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
news:PeudnRKltL JsufHYnZ2dnUVZ_ u2dnZ2d@comcast .com...
>

>>Tony Marston wrote:
>>

>>>"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
>>>news:j9-dnQB80fVLOvbYnZ 2dnUVZ_rOdnZ2d@ comcast.com...
>>>
>>>
>>>>Tony Marston wrote:
>>>>
>>>>
>>>>>"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
>>>>>news:Ib6dn a_BtYQSifbYnZ2d nUVZ_sSdnZ2d@co mcast.com...
>>>>>
>>>>>
>>>>>
>>>>>>jopperdep opper wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>You should read "can be accessed everywhere".
>>>>>>>>
>>>>>>>>Priva te members can be accessed by members of the class only.
>>>>>>>>Protect ed members can be accessed by members of the class or a
>>>>>>>>deriv ed
>>>>>>>>class .
>>>>>>>>Publi c members can be accessed by anyone, including other classes,
>>>>>>>>functio ns and any other code.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
>>>>>>>to classes, and so far having a hard time. I fail to see the 'why'
>>>>>>>behind the 'public, protected and private' and stuff like abstraction,
>>>>>>>interfac es and whatnot.
>>>>>
>>>>>
>>>>>Inteface s are not necessary in PHP. Once you have defined a method it is
>>>>>a total waste to time to also define an interface. Interfaces are a
>>>>>"fix" in those languages as a means of dealing with optional arguments
>>>>>and statyic typing. PHP has ifferent ways of dealing with bth of these,
>>>>>therefor e interfaces serve no useful purpose.
>>>>>
>>>>
>>>>Ah, the great Tony Marston is back to trolling again.
>>>>
>>>>Wrong. In OO terms, the interface is the way to interact with the
>>>>object. It consists of all public members - both methods (functions, in
>>>>PHP) and variables. And for derived classes, the base class adds
>>>>protected members.
>>>>
>>>>A PHP interface is something entirely different.
>>>
>>>
>>>I disagree. It is possible to define a function (method) within a class,
>>>then to define a separate thing called an "interface" . It is possible
>>>access
>>>the function without using the interface, therefore the interface is not
>>>necessary.
>>>

>>
>>Tony,
>>
>>You really need to learn about OO before spouting off. In OO terms, an
>>interface is something entirely different than a PHP interface.

>
>
How so? All the documentation I have seen describes how an interface simply
describes a method which it imlements. If it is possible to access a method
(a function in PHP) without going though an interface, ten an interface is
not necessary in any language.
>

You need to understand the difference between an interface as described
in OO terms and the PHP interface.

The PHP interface defines a set of methods (function) which are required
by the classes which implement the interface. Java is similar in that
respect. But both are a subset of the total interface.

>

>>PHP is not the only OO language. Some don't even have a term "interface"
>>as part of the language. But the still have an interface.
>>
>>Try some of the books by James Rumbaugh, Grady Booch and/or Ivar Jacobson.
>>
>>

>>>>>>>Feels like things are being over-complicated
>>>>>>>somehow. .. or it's just my being inexperienced on this...
>>>>>>>
>>>>>>>Any other reading material on this suggested, someone?
>>>>>>>
>>>>>>
>>>>>>Look for some good books on OO theory and design.
>>>>>>
>>>>>>Two of the concepts in OO are 'encapsulation' and 'methods'.
>>>>>>
>>>>>>Encapsula tion means the internals of an object are managed only by that
>>>>>>object and are not available to anyone else. In PHP these are private
>>>>>>members .
>>>>>
>>>>>
>>>>>Wrong. Encapsulation means that the data and the functions which operate
>>>>>on that data are contained (encapsulated) within a single object. While
>>>>>the methods (functions) thenselves may be visible the code behind those
>>>>>methods (i.e. the implementaton behind those methods) is not.
>>>>>Encapslati on is NOT about hiding information, it is about hiding the
>>>>>implementa tion. It is not necessary to use public/private/protected on
>>>>>any methods or properties. It does not add any functionality, it merely
>>>>>creates restrictions which often get in the way.
>>>>>
>>>>
>>>>Wrong again, Tony. Encapsulation means internal representations of the
>>>>object are not visible outside of the class. Just like the base &
>>>>mantissa are not visible outside of a floating point number.
>>>
>>>
>>>I disagree. Encapsulation means that both the data and the methods which
>>>operate on that data are contained within a single unit or "capsule". The
>>>data names and the method names may be visible, it is only the code which
>>>lies behind each method name which is invisible. A piece of data may be
>>>accessed directly, as in $object->var, or it may be accessed through a
>>>getter, as in $object->getVar().
>>>
>>>If you bothered to read the right books you will see that encapsulation
>>>means "implementa tion hiding" and not "informatio n hiding".
>>>

>>
>>Again, read the experts before spouting off. You have repeatedly shown
>>how little you understand about OO programming techniques.
>>
>>And yes, encapsulation is "implementa tion hiding". And the variables are
>>part of the IMPLEMENTATION.

>
>
I disagree. Inplementation is code, information is data. If you don't
believe me then read "Encapsulat ion is not information hiding" at
http://www.javaworld.com/javaworld/j...psulation.html and
also "Abstractio n, Encapsulation, and Information Hiding" at

http://www.itmweb.com/essay550.htm

>

OK, so you quote a couple of blogs by people who have their own opinions.

Read books by the authors I mentioned. They are the experts on OO, not
just anyone who can post a blog or essay on the web.

>

>>>>>>Methods are implemented as functions in PHP. They operate on the
>>>>>>object.
>>>>>
>>>>>
>>>>>That's one thing you got right.
>>>>>
>>>>
>>>>More than you got right. Go crawl back into your hole and don't come out
>>>>again until you know what you're talking about.
>>>
>>>
>>>I do know what I'm talking about..
>>>

>>
>>Then why do you continually disagree with the recognized experts in the OO
>>community, like the ones I mentioned above?

>
>
I disagree with YOU simply because you clam to be a recognised expert when
in fact you are no such thing. I keep finding papers on the internet which
disagree with your explanations, yet you persist in claiming that you are
right and everybody who dares to disagree with you is wrong. Such arrogance!
>

No, you disagree with every recognized expert in the field. Read what
the authors I mentioned have to say about it. THEY are the recognized
experts in the field.

I can create a paper on the internet saying the sun rises in the west.
It's quite simple to do. But that doesn't make it a fact.

Now go home and do some reading. You might actually learn something.


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

[Michael Fesser]

Re: php 5 classes: public, protected and private

..oO(Tony Marston)

>I disagree. it is *not* necessary for the simple reason that the code will
>perform exactly the same function whether methods and properties are marked
>as public/private/protected or not.

Then why do we use OOP and high-level languages like PHP at all? Pure
hand-written assembler code will perform exactly the same function.

>It prevents developers from doing things that shouldn't be done, for
>example calling an internal method out of context. I don't want all my
>methods being publicly available, simply in order to avoid errors and
>unpredictabl e results.

>
>That is a matter for programmer discipline, it is not a matter of additional
>functionalit y. The code will do exactly the same with or without it.

The code written in a language like Delphi for example will also do
exactly the same with all type checks, range checks, overflow checks
etc. turned off. But does it make sense to do that and just rely on
"programmer discipline"? No, it doesn't, because it will lead to
erroneous code on the long run.

Compilers are able to automatically check a lot of things and warn the
developer if he made a mistake. Such checks and restrictions don't add
any functionality, but are necessary in order to write reliable code.

The same goes for visibility declarations. I don't rely on discipline or
a comment like "please don't call this method". If a method is not meant
to be called directly then it's declared as such - problem solved.

Micha