subject:"RE\: \[PHP\] Beginner Tutorials for using CLASSES in PHP4"


Larry Garfield [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 On Tuesday 09 October 2007, Tony Marston wrote:

 I have bought and read several books on design patterns without being
 impressed. I have seen countless examples of how particular design 
 patterns
 can be implemented, and I am even more unimpressed. Unless you can 
 explain,
 simply and with simple examples, of things that can ONLY be achieved
 through the use of interfaces then I will continue to say tha they are a
 waste of time.

 Classic OOP (C++/PHP/Java, etc.) is, really, an extension on top of 
 procedural
 programming.  Nothing that you do with objects couldn't be done without 
 them.
 They are equally expressive.

 OOP is just syntactic sugar to make writing certain logical structures 
 easier
 (less code, more readable code, code that's harder, but not impossible, 
 for
 someone else to break, etc.).  There is absolutely nothing that can ONLY 
 be
 achieved through, for instance, interfaces.  It's just that interfaces 
 make
 it a hell of a lot easier to solve certain problems than doing everything
 with non-dynamic functions.

 Anything you can do with functions you can also do with GOTO statements.
 functions are just syntactic sugar to make writing logical structures 
 easier.
 Until you can explain, with examples, some problem that can ONLY be solved
 through the use of functions I will continue to say that they are a waste 
 of
 time.

 Anything that you can do in PHP you could also do in assembler.  PHP is 
 just
 syntactic sugar to make writing logical structures easier.  Until you can
 explain, with examples, some problem that can ONLY be solved through the 
 use
 of PHP I will continue to say that it is a waste of time.

 Yes, I am making fun of you for a piss-stupid Luddite argument. :-)

But you still cannot provide a convincing argument for using interfaces. The 
fact that you CAN use interfaces does not mean that you MUST use interfaces. 
I manage to get by without them.

 *My* definition of encapsulation is *the* definition of encapsulation as 
 it
 was originally intended. The fact that other smart arse numbskulls have
 corrupted it with their own stupid embellishments is something which I
 choose to ignore.

Encapsulation does not REQUIRE data to be hidden. It is an option, therefore 
I have the right to exercse the option of ignoring it.

 *My* definition of dark green is *the* definition as it was originally
 intended.  The fact that other smart-ass numbskulls have corrupted it with
 their own stupid saturation embellishments is something which I choose to
 ignore.

 (Yes, I am making fun of you again.)

What a pathetic example.

  but  you admit, the php5 construct is better and  therefore strengthen 
  my
  initial argument, which was, if php5 is better and php4 is deprecated;
  why bother
  w/ php4.

 Your statement was that it would be absolutely pointless trying to learn
 OOP with PHP 4 which implies that it is not possible to write object
 oriented programs wth PHP 4 at all. That is absolute crap as PHP 4 
 provides
 ALL the basic necessities for OOP, which are encapsulation, inheritance 
 and
 polyorphism.

 Here's a better reason to not bother learning PHP 4-style OOP.  You have 
 less
 than a year until running PHP 4 at all is considered an unsupported 
 security
 risk.  Don't waste your time, since PHP 5 OOP IS different, because 
 reference
 handling changed drastically which means what is fast and easy in PHP 4 
 OOP
 and what is fast and easy in PHP 5 OOP is hugely different.

That still does not hide the fact that PHP 4's OOP style is still perfactly 
valid. As for the new features in PHP 5, I shall only use them when they can 
provide demonstrable benefits, and not just because they are there.

  if  you read that one chapter i recommended you will see; acquiring the
  behavior of the parent is not always desirable.

 Then why inherit from the parent in the first place? Or why not create a
 method in the subclass which overrides the method in the superclass, thus
 changing the behaviour to what you prefer? I certainly don't need
 interfaces to do that.

 Because I want to syntactically guarantee the existence of certain methods 
 so
 that I can reliably call functionality on them.

But if you have defined a method in a class then the method exists. You do 
not need a separate interface to make that method accessible. That is my 
whole point - interfaces are optional, not mandatory, and I have never found 
agood reason to use them.

 Call-and-pray is an
 unreliable methodology.  Yes, that is syntactic sugar.  See above.

If you try to call an object method which did not exist you would soon know 
about it, interface or not.

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

 Can we stop with the pissing contest now?

 -- 
 Larry Garfield AIM: LOLG42
 [EMAIL PROTECTED] ICQ: 6817012

 If nature has made any one thing less susceptible than all others of
 exclusive

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4


tedd [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 At 9:54 PM -0400 10/9/07, Nathan Nobbe wrote:
  i hope i have been able to contribute something to someone
amidst all the arguing.

-nathan


 Yeah, you gave me a better appreciation of some of the members of this 
 list -- we have some smart people here (i.e., Rob, Tony, Larry).

When people use the word smart to describe me they usually follow it up 
with ass.  :)

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

 Cheers,

 tedd

 -- 
 ---
 http://sperling.com  http://ancientstones.com  http://earthstones.com 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

2007-10-10 Thread tedd


At 9:54 PM -0400 10/9/07, Nathan Nobbe wrote:

 i hope i have been able to contribute something to someone
amidst all the arguing.

-nathan



Yeah, you gave me a better appreciation of some of the members of 
this list -- we have some smart people here (i.e., Rob, Tony, Larry).


Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/10/07, tedd [EMAIL PROTECTED] wrote:

 At 9:54 PM -0400 10/9/07, Nathan Nobbe wrote:
   i hope i have been able to contribute something to someone
 amidst all the arguing.
 
 -nathan


 Yeah, you gave me a better appreciation of some of the members of
 this list -- we have some smart people here (i.e., Rob, Tony, Larry).

 Cheers,

 tedd


i was waiting for an insult to that remark; thanks for filling the slot
tedd.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Wed, 2007-10-10 at 08:55 -0400, tedd wrote:
 At 9:54 PM -0400 10/9/07, Nathan Nobbe wrote:
   i hope i have been able to contribute something to someone
 amidst all the arguing.
 
 -nathan
 
 
 Yeah, you gave me a better appreciation of some of the members of 
 this list -- we have some smart people here (i.e., Rob, Tony, Larry).

All lies... I'm winging it... someday you'll see through my smoke and
mirrors :)

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4


Nathan Nobbe [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:


 Nathan Nobbe [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
  On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:
 
  There's your problem, then. You are wasting your time trying to
 implement
  fancy design patterns just because design patterns are supposed to be
  cool.  Loader class, Controller Base class, Front Controller - I 
  have
  none
  of that crap in my code, so I don't encounter the problems you have.
 
 
  your site talks about the use of mvc in radicore so we can assume youre
  using at least one design pattern;

 When I say that I do not use design patterns I mean that I do not try to
 implemet as many design patterns as possible,


 i never suggested any one do that nor did i suggest that i do that.

 and I certainly do not litter
 my conversations with this pattern or that pattern.

 then  you failed to grasp one of the most important concepts about design
 patterns.
 they provide a common vocabulary to allow designers to talk about
 implementing
 systems at a high level without having to waste time talking about 
 specific
 details.

Yes, but many of today's programmers regard design patterns with a religious 
zeal which borders on fanaticism. Such people cannot bring anything of value 
to the conversation.

 In the whole of my
 career there have only ever been two patterns that I have read about and
 subsequently sought to implement, and thoose are the Three Tier
 Architecture
 and the Singleton. The fact that my framework contains an example of MVC
 is
 pure coincidence. It just happened that way. It was only after someone
 else
 looked at my code and said You've implemented the MVC pattern that I
 read
 about it and discovered that it was a perfect match. I certainly did not
 read about MVC and then try to implement it.


 that is very common.  many if not most people implement patterns all the
 time and dont realize it.

Just because someone may see a pattern in my code does not mean that I first 
studied the pattern and then implemented it. I wrote the code without any 
knowledge of the pattern, therefore I did not use the pattern when writing 
my code.

 one benefit of patterns is people can communicate at the pattern
 level.  recognition is powerful as well; if you happen to see a pattern 
 when
 you are working out a design; the pieces just fall into place; or at least 
 you have
 a road map.

I don't waste my time talking about design patterns to the pattern zealots. 
It is as productive as attempting to have a theological discussion with a 
religeous fanatic - a total waste of time unless you share their point of 
view.

Too many of today's programmers can only see patterns after they have read 
about them in a book. They vie with each other to see how many patterns they 
can juggle at the same time, or complain that someone els'e implementation 
of a particular pattern is unsound or impure.

 and if radicore has a single point of entry you are using a front 
 controller.

 I do not have a single point entry. Each page has its own controller, so 
 I
 have hundreds of page controllers. A single front controller is something
 that is used in compiled languages.


 its also used heavily in php; take a look at code igniter for a first
 example.

Just because people use font controllers in PHP does not make them a good 
thing. I personally think they are crap.

 might want to knock the dust off the old design pattern books just to jog
  your memory:)

 I've put my books of design patterns on the top shelf where they shall
 remain untouched as they contain nothing of use to me. They may give 
 hints
 to novices, but I am no longer a novice. I no longer need training wheels
 on my bicycle, so why do I need books on design patterns?


 ill be honest; i like what youve done w/ xsl, you even taught me some
 things; but when it comes to oop; well i think you should get the books
 back down from the top shelf.

 -nathan


Why? What is wrong with my implementation of OOP? Surely I have used 
encapsulation, inheritance and polymorphism to increase code reuse and 
decrease maintenance, therefore my implementation can only be regarded as 
effective. The fact that you don't like my style is your problem, not mine.

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

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4


Nathan Nobbe [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:

 On Tue, 2007-10-09 at 21:37 -0400, Nathan Nobbe wrote:
 
  does a lawn mower not have blades; and gas and a control panel; does it
 not
  have
  wheels?  my object modeling of a lawn mower would certainly have these
  things;
  and most likely i would mark components of the engine as private.
  and what does a lawn mower cut anyway; grass; i thought that was it. 
  so
 if
  there
  was no grass could there still be an algorithm to cut it?
  i say grass is part of the grass-cutting algorithm.

 Well it helps to refine the algorithm, but let's say we use fingers
 instead as our measure... I'm sure we would find that we could cut grass
 also :)


 good point.
 the lawn mower is still consistent of its own parts and they
 comprise its implementation.

 -nathan

Yes, but a lawnmower does not contain grass, it is used to cut grass. Whole 
grass goes in and cut grass comes out. The lawnmower does not have any grass 
in its construction, therefore grass is not part of the implementation.

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

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Wed, 2007-10-10 at 14:44 +0100, Tony Marston wrote:
 Nathan Nobbe [EMAIL PROTECTED] wrote in message 
 news:[EMAIL PROTECTED]
  On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:
 
  On Tue, 2007-10-09 at 21:37 -0400, Nathan Nobbe wrote:
  
   does a lawn mower not have blades; and gas and a control panel; does it
  not
   have
   wheels?  my object modeling of a lawn mower would certainly have these
   things;
   and most likely i would mark components of the engine as private.
   and what does a lawn mower cut anyway; grass; i thought that was it. 
   so
  if
   there
   was no grass could there still be an algorithm to cut it?
   i say grass is part of the grass-cutting algorithm.
 
  Well it helps to refine the algorithm, but let's say we use fingers
  instead as our measure... I'm sure we would find that we could cut grass
  also :)
 
 
  good point.
  the lawn mower is still consistent of its own parts and they
  comprise its implementation.
 
  -nathan
 
 Yes, but a lawnmower does not contain grass, it is used to cut grass. Whole 
 grass goes in and cut grass comes out. The lawnmower does not have any grass 
 in its construction, therefore grass is not part of the implementation.

It may not be part of it's construction, but it certainly is a member
variable. It's along the lines of the following:

?php

class Lawnmower
{
var $works = true;
var $grassyMulchCrapStuckToUndersideOfLawnmower = 0;

function mow( $what )
{
if( !$this-works )
{
return false;
}

if( $what == 'grass' )
{
$this-grassyMulchCrapStuckToUndersideOfLawnmower +=
rand( 1, 100 );

if( $this-grassyMulchCrapStuckToUndersideOfLawnmower 
1000 )
{
return $this-seize();
}
}
else
if( $what == 'fingers' )
{
// :)
}

return true;
}

function seize()
{
return ($this-works = false);
}
}

?

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/10/07, Tony Marston [EMAIL PROTECTED] wrote:


 Nathan Nobbe [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
  On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:
 
 
  Nathan Nobbe [EMAIL PROTECTED] wrote in message
  news:[EMAIL PROTECTED]
   On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:
  
   There's your problem, then. You are wasting your time trying to
  implement
   fancy design patterns just because design patterns are supposed to
 be
   cool.  Loader class, Controller Base class, Front Controller - I
   have
   none
   of that crap in my code, so I don't encounter the problems you have.
  
  
   your site talks about the use of mvc in radicore so we can assume
 youre
   using at least one design pattern;
 
  When I say that I do not use design patterns I mean that I do not try
 to
  implemet as many design patterns as possible,
 
 
  i never suggested any one do that nor did i suggest that i do that.
 
  and I certainly do not litter
  my conversations with this pattern or that pattern.
 
  then  you failed to grasp one of the most important concepts about
 design
  patterns.
  they provide a common vocabulary to allow designers to talk about
  implementing
  systems at a high level without having to waste time talking about
  specific
  details.

 Yes, but many of today's programmers regard design patterns with a
 religious
 zeal which borders on fanaticism. Such people cannot bring anything of
 value
 to the conversation.


many is a generalization; i have never suggested that patterns be used
without regard
or care.

 In the whole of my
  career there have only ever been two patterns that I have read about
 and
  subsequently sought to implement, and thoose are the Three Tier
  Architecture
  and the Singleton. The fact that my framework contains an example of
 MVC
  is
  pure coincidence. It just happened that way. It was only after someone
  else
  looked at my code and said You've implemented the MVC pattern that I
  read
  about it and discovered that it was a perfect match. I certainly did
 not
  read about MVC and then try to implement it.
 
 
  that is very common.  many if not most people implement patterns all the
  time and dont realize it.

 Just because someone may see a pattern in my code does not mean that I
 first
 studied the pattern and then implemented it.


precisely

I wrote the code without any
 knowledge of the pattern, therefore I did not use the pattern when writing
 my code.


 you used the pattern and you didnt realize it until later; like i said;
very common.

 one benefit of patterns is people can communicate at the pattern
  level.  recognition is powerful as well; if you happen to see a pattern
  when
  you are working out a design; the pieces just fall into place; or at
 least
  you have
  a road map.

 I don't waste my time talking about design patterns to the pattern
 zealots.
 It is as productive as attempting to have a theological discussion with a
 religeous fanatic - a total waste of time unless you share their point of
 view.

 Too many of today's programmers can only see patterns after they have
 read
 about them in a book. They vie with each other to see how many patterns
 they
 can juggle at the same time, or complain that someone els'e implementation
 of a particular pattern is unsound or impure.

  and if radicore has a single point of entry you are using a front
  controller.
 
  I do not have a single point entry. Each page has its own controller,
 so
  I
  have hundreds of page controllers. A single front controller is
 something
  that is used in compiled languages.
 
 
  its also used heavily in php; take a look at code igniter for a first
  example.

 Just because people use font controllers in PHP does not make them a good
 thing. I personally think they are crap.


i prefer them over multiple points of entry; apparently code igniter does
too.

 might want to knock the dust off the old design pattern books just to jog
   your memory:)
 
  I've put my books of design patterns on the top shelf where they shall
  remain untouched as they contain nothing of use to me. They may give
  hints
  to novices, but I am no longer a novice. I no longer need training
 wheels
  on my bicycle, so why do I need books on design patterns?
 
 
  ill be honest; i like what youve done w/ xsl, you even taught me some
  things; but when it comes to oop; well i think you should get the books
  back down from the top shelf.
 
  -nathan
 

 Why? What is wrong with my implementation of OOP? Surely I have used
 encapsulation, inheritance and polymorphism to increase code reuse and
 decrease maintenance, therefore my implementation can only be regarded as
 effective. The fact that you don't like my style is your problem, not
 mine.


because you keep saying you dont see the benefits of the features in php5;
repeatedly you ask why, why, why; why interfaces for example.
as i have suggested; pick up a book and read about it.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/10/07, Tony Marston [EMAIL PROTECTED] wrote:


 Nathan Nobbe [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
  On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:
 
  On Tue, 2007-10-09 at 21:37 -0400, Nathan Nobbe wrote:
  
   does a lawn mower not have blades; and gas and a control panel; does
 it
  not
   have
   wheels?  my object modeling of a lawn mower would certainly have
 these
   things;
   and most likely i would mark components of the engine as private.
   and what does a lawn mower cut anyway; grass; i thought that was it.
   so
  if
   there
   was no grass could there still be an algorithm to cut it?
   i say grass is part of the grass-cutting algorithm.
 
  Well it helps to refine the algorithm, but let's say we use fingers
  instead as our measure... I'm sure we would find that we could cut
 grass
  also :)
 
 
  good point.
  the lawn mower is still consistent of its own parts and they
  comprise its implementation.
 
  -nathan

 Yes, but a lawnmower does not contain grass, it is used to cut grass.
 Whole
 grass goes in and cut grass comes out. The lawnmower does not have any
 grass
 in its construction, therefore grass is not part of the implementation.


yes, you are right about the grass not being part of the implementation; i
agree.
however; the mower as i pointed out has its own member variables that
comprise its
implementation; and earlier you suggested that member variables dont
constitute the
implementation of a class; which is wrong;

here is my example; note; no grass; but it has member variables which
comprise its implementation.

?php
class Lawnmower {
const GAS_MIN = 0;
const GAS_MAX = 10;

private $engineOn = false;
private $gasLevel = 5;

public function turnOn() {
if($this-canRun()) {
$this-engineOn = true;
} else {
echo 'you need to add gas to run the mower!';
}
}

public function mowGrass() {
echo 'the grass [or pehaps fingers] are being cut...';
}

public function turnOf() {
$this-enginOn = false;
}

public function addGas($amountOfGas) {
if(($amountOfGas + $this-gasLevel)  self::GAS_MAX) {
$this-amountOfGas += $amountOfGas;
} else {
echo 'you will overflow the tank w/ all that gas.';
return false;
}
}

public function checkGasLevel() {
return $this-gasLevel;
}

private function canRun() {
$canRun = false;

if($this-gasLevel  self::GAS_MIN) {
$canRun = true;
}

return $canRun;
}
}
?

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

and here is the interface example youve (Tony) been asking for.
the reason an interface is the best option here is because human hands and
grass are not related,
but they can both be cut (i didnt start the fingers thing, but it works for
the example so im using it).

also, notice the benefit of composition.  the same mower can be used invoke
the cut method on
different Cuttables at runtime.
the reason this works is because Cuttable encapsulates a family of similar
algorithms.  know what
that ones called; the strategy pattern; i must be a patterns zealot.

also, regarding the, is grass part of the algorithm thing; i thought about
it more; i think this boils down to
definition vs. instantiation.  take functions for example; they have formal
and actual parameters.

function someFunction($formalParameter) {
echo $formalParameter . PHP_EOL;
}

$actualParameter = 'Hello World';

someFunction($actualParameter);

$actualParameter is not part of the someFunction implementation, but
$formalParameter is.

in the same way (in the following example) the Grass instances are not part
of the Lawnmower implementation,
but the member variables and method signatures (of Lawnmower) do constitute
its implementation.

?php
class Lawnmower {
const GAS_MIN = 0;
const GAS_MAX = 10;
const BLADE_HEIGHT_MIN = 1;
const BLADE_HEIGHT_MAX = 5;

private $engineOn = false;
private $gasLevel = 5;
private $bladeHeight = 3;

public function turnOn() {
if($this-canRun()) {
$this-engineOn = true;
} else {
echo 'you need to add gas to run the mower!' . PHP_EOL;
}
}

public function mowGrass(Cuttable $theGrass) {
$theGrass-cut($this-bladeHeight);
}

public function turnOf() {
$this-enginOn = false;
}

public function addGas($amountOfGas) {
if(($amountOfGas + $this-gasLevel)  self::GAS_MAX) {
$this-amountOfGas += $amountOfGas;
} else {
echo 'you will overflow the tank w/ all that gas.' . PHP_EOL;
return false;
}
}

public function decreaseBladeHeight() {
if($this-bladeHeight  self::BLADE_MIN_HEIGHT) {
$this-bladeHeight--;
} else {
echo 'the blades are already at their lowest setting' . PHP_EOL;
}
}

public function increaseBladeHeight() {
if($this-bladeHeight  self::BLADE_HEIGHT_MAX) {
$this-bladeHeight++;
} else {
echo 'the blades are already at their highest setting' .
PHP_EOL;
}
}

public function checkGas() {
return $this-gasLevel;
}

private function canRun() {
$canRun = false;

if($this-gasLevel  self::GAS_MIN) {
$canRun = true;
}

return $canRun;
}
}

interface Cuttable {
function cut($newHeight);
}

class Grass implements Cuttable {
const MIN_HEIGHT = 0;

private $grassHeight = 3;

public function grow() {
$this-grassHeight++;
}

public function cut($newHeight) {
if($newHeight  self::MIN_HEIGHT) {
echo 'dirt flying in every direction!' . PHP_EOL;
$this-grassHeight = self::MIN_HEIGHT;
} else {
$this-grassHeight = $newHeight;
}
}
}

class HumanHand implements Cuttable {
private $numFingers = 5;

public function cut($newHeight) {
 TODO: ROB CAN FILL IN THE PART ABOUT WHAT HAPPENS TO THE
FINGERS :)
echo 'oh dear, i have to go to the hospital!' . PHP_EOL;
}
}


$myLawn = new Grass();
$neighborsLawn = new Grass();
$myMower = new Lawnmower();
$myHand = new HumanHand();

// neighbors havent cut their grass in weeks
$neighborsLawn-grow();
$neighborsLawn-grow();

echo 'ill cut my grass first at the standard blade height' . PHP_EOL;
$myMower-turnOn();
$myMower-mowGrass($myLawn);

echo 'now ill adjust the blade height, because the neighbors like their
grass tall' . PHP_EOL;
$myMower-increaseBladeHeight();
$myMower-mowGrass($neighborsLawn);

echo 'bummer; there is some gunk on the underside of the mower; pehaps ill
use my hand to dig it out..' . PHP_EOL;
$myMower-mowGrass($myHand);
?

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

All your examples all falling on deaf ears. The fact of the matter is that 
encapsulation does NOT mean data hiding, therefore I do NOT have to make all 
my member variables private.

The fact that you have used interfaces in that example proves nothing to me. 
It is possible to code a solution which does not use interfaces, so what are 
the benefits of the with interfaces solution over thewithout interfaces 
solution. If there are no benefits then I prefer to stick with the without 
interfaces solution.

Just because you CAN use interfaces does not mean that you MUST use 
interfaces. I can build solutions without them, so I do not see any 
advantage in using them.

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

Nathan Nobbe [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 and here is the interface example youve (Tony) been asking for.
 the reason an interface is the best option here is because human hands and
 grass are not related,
 but they can both be cut (i didnt start the fingers thing, but it works 
 for
 the example so im using it).

 also, notice the benefit of composition.  the same mower can be used 
 invoke
 the cut method on
 different Cuttables at runtime.
 the reason this works is because Cuttable encapsulates a family of similar
 algorithms.  know what
 that ones called; the strategy pattern; i must be a patterns zealot.

 also, regarding the, is grass part of the algorithm thing; i thought about
 it more; i think this boils down to
 definition vs. instantiation.  take functions for example; they have 
 formal
 and actual parameters.

 function someFunction($formalParameter) {
echo $formalParameter . PHP_EOL;
 }

 $actualParameter = 'Hello World';

 someFunction($actualParameter);

 $actualParameter is not part of the someFunction implementation, but
 $formalParameter is.

 in the same way (in the following example) the Grass instances are not 
 part
 of the Lawnmower implementation,
 but the member variables and method signatures (of Lawnmower) do 
 constitute
 its implementation.

 ?php
 class Lawnmower {
const GAS_MIN = 0;
const GAS_MAX = 10;
const BLADE_HEIGHT_MIN = 1;
const BLADE_HEIGHT_MAX = 5;

private $engineOn = false;
private $gasLevel = 5;
private $bladeHeight = 3;

public function turnOn() {
if($this-canRun()) {
$this-engineOn = true;
} else {
echo 'you need to add gas to run the mower!' . PHP_EOL;
}
}

public function mowGrass(Cuttable $theGrass) {
$theGrass-cut($this-bladeHeight);
}

public function turnOf() {
$this-enginOn = false;
}

public function addGas($amountOfGas) {
if(($amountOfGas + $this-gasLevel)  self::GAS_MAX) {
$this-amountOfGas += $amountOfGas;
} else {
echo 'you will overflow the tank w/ all that gas.' . PHP_EOL;
return false;
}
}

public function decreaseBladeHeight() {
if($this-bladeHeight  self::BLADE_MIN_HEIGHT) {
$this-bladeHeight--;
} else {
echo 'the blades are already at their lowest setting' . 
 PHP_EOL;
}
}

public function increaseBladeHeight() {
if($this-bladeHeight  self::BLADE_HEIGHT_MAX) {
$this-bladeHeight++;
} else {
echo 'the blades are already at their highest setting' .
 PHP_EOL;
}
}

public function checkGas() {
return $this-gasLevel;
}

private function canRun() {
$canRun = false;

if($this-gasLevel  self::GAS_MIN) {
$canRun = true;
}

return $canRun;
}
 }

 interface Cuttable {
function cut($newHeight);
 }

 class Grass implements Cuttable {
const MIN_HEIGHT = 0;

private $grassHeight = 3;

public function grow() {
$this-grassHeight++;
}

public function cut($newHeight) {
if($newHeight  self::MIN_HEIGHT) {
echo 'dirt flying in every direction!' . PHP_EOL;
$this-grassHeight = self::MIN_HEIGHT;
} else {
$this-grassHeight = $newHeight;
}
}
 }

 class HumanHand implements Cuttable {
private $numFingers = 5;

public function cut($newHeight) {
 TODO: ROB CAN FILL IN THE PART ABOUT WHAT HAPPENS TO THE
 FINGERS :)
echo 'oh dear, i have to go to the hospital!' . PHP_EOL;
}
 }


 $myLawn = new Grass();
 $neighborsLawn = new Grass();
 $myMower = new Lawnmower();
 $myHand = new HumanHand();

 // neighbors havent cut their grass in weeks
 $neighborsLawn-grow();
 $neighborsLawn-grow();

 echo 'ill cut my grass first at the standard blade height' . PHP_EOL;
 $myMower-turnOn();
 $myMower-mowGrass($myLawn);

 echo 'now ill adjust the blade height, because the neighbors like their
 grass tall' . PHP_EOL;
 $myMower-increaseBladeHeight();
 $myMower-mowGrass($neighborsLawn);

 echo 'bummer; there is some gunk on the underside of the

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/10/07, Tony Marston [EMAIL PROTECTED] wrote:

 All your examples all falling on deaf ears. The fact of the matter is that
 encapsulation does NOT mean data hiding, therefore I do NOT have to make
 all
 my member variables private.


i thought we agreed  to disagree on that  point; im done discussing it.

The fact that you have used interfaces in that example proves nothing to me.
 It is possible to code a solution which does not use interfaces, so what
 are
 the benefits of the with interfaces solution over thewithout
 interfaces
 solution. If there are no benefits then I prefer to stick with the
 without
 interfaces solution.


lets see your w/o example then.

Just because you CAN use interfaces does not mean that you MUST use
 interfaces. I can build solutions without them, so I do not see any
 advantage in using them.


i told you what the benefit is; HumanHand and Grass have no relationship
other than
they are both Cuttable.
the advantage to using them in this case is if Grass and HumanHand both
inherited from
the same base class they would have common member variables which makes no
sense
because they arent directly related.

there are plenty of libraries that are open source and utilize interfaces in
their design.
look at ezc, onphp and SPL for more examples.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/10/07, Larry Garfield [EMAIL PROTECTED] wrote:


 On Wed, 10 Oct 2007 13:39:31 -0400, Nathan Nobbe [EMAIL PROTECTED]
 wrote:

  The fact that you have used interfaces in that example proves nothing to
  me.
  It is possible to code a solution which does not use interfaces, so
 what
  are
  the benefits of the with interfaces solution over thewithout
  interfaces
  solution. If there are no benefits then I prefer to stick with the
  without
  interfaces solution.
 
 
  lets see your w/o example then.


 That it is possible to write functioning code without Interfaces has never
 been disputed.


and im not disputing it either.

 Just because you CAN use interfaces does not mean that you MUST use
  interfaces. I can build solutions without them, so I do not see any
  advantage in using them.
 
 
  i told you what the benefit is; HumanHand and Grass have no relationship
  other than
  they are both Cuttable.
  the advantage to using them in this case is if Grass and HumanHand both
  inherited from
  the same base class they would have common member variables which makes
 no
  sense
  because they arent directly related.
 
  there are plenty of libraries that are open source and utilize
 interfaces
  in
  their design.
  look at ezc, onphp and SPL for more examples.
 
  -nathan

 Multiple inheritance.  If you extend a class, you can do so at most once
 for a given child class.  But you can implement many interfaces.


right; thats a benefit of interfaces i mentioned yesterday, but implementors
dont get behavior from the interfaces the implement.
which is a benefit exhibited by the lawnmower example that uses interfaces.

-nathan

RE: [PHP] Beginner Tutorials for using CLASSES in PHP4

2007-10-10 Thread Jay Blanchard

[snip]
so what are the benefits of the with interfaces solution over
thewithout
 interfaces solution
[/snip]

Polymorphism.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/10/07, Tony Marston [EMAIL PROTECTED] wrote:


 Jay Blanchard [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
 [snip]
  so what are the benefits of the with interfaces solution over
 thewithout interfaces solution
 [/snip]

  Polymorphism.

 Are you saying that it is not possible to have polymorphism without using
 interfaces? If so you are very much mistaken.


no, but what you still havent been able to grasp is the alternate
polymorphic facility that interfaces offer.

how would you do the lawnmower w/o interfaces?  use arrays instead, for
grass and human hand,
then you loose polymorphism.
if you instead make human hand and grass extend from a common base class
then youre combining the
passing the behavior of some strange parent class to two mostly unrelated
children.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4


Jay Blanchard [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
[snip]
 so what are the benefits of the with interfaces solution over
thewithout interfaces solution
[/snip]

 Polymorphism.

Are you saying that it is not possible to have polymorphism without using 
interfaces? If so you are very much mistaken.

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

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4


Nathan Nobbe [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 On 10/10/07, Tony Marston [EMAIL PROTECTED] wrote:


 Jay Blanchard [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
 [snip]
  so what are the benefits of the with interfaces solution over
 thewithout interfaces solution
 [/snip]

  Polymorphism.

 Are you saying that it is not possible to have polymorphism without using
 interfaces? If so you are very much mistaken.


 no, but what you still havent been able to grasp is the alternate
 polymorphic facility that interfaces offer.

But I don't need an alternative facility for polymorphism as the one I have 
without interfaces is more than sufficient for my needs.

 how would you do the lawnmower w/o interfaces?

I wouldn't play with a lawnmower class in the first place. I use PHP to 
write web applications which deal with database tables, not lawnmowers, and 
I have yet to find a good reason for using interfaces in such applications. 
Your contrived examples do not convince me of anything.

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

 use arrays instead, for grass and human hand,
 then you loose polymorphism.
 if you instead make human hand and grass extend from a common base class
 then youre combining the
 passing the behavior of some strange parent class to two mostly unrelated
 children.

 -nathan
 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Beginner Tutorials for using CLASSES in PHP4

2007-10-10 Thread Jay Blanchard

[snip]
I wouldn't play with a lawnmower class in the first place. I use PHP to 
write web applications which deal with database tables, not lawnmowers,
and 
I have yet to find a good reason for using interfaces in such
applications. 
Your contrived examples do not convince me of anything.
[/snip]

This is the best supporting argument that you have provided for your
case, and you are correct...it is not necessary to implement an
interface to perform polymorphism.

We have several applications that dealer with customers and we achieve
polymorphism for the different customer types through interfaces. It is
convenient, easy to document and easy to maintain. Still a relatively
simple application, customer database and all. We also use interfaces to
achieve polymorphism for certain product types.

We used to do all of this functionally or procedurally and made it as
easy to maintain as possible. It worked pretty well but was not nearly a
scalable as required. We also did this in PHP4 OOP without interfaces
and it was easier to maintain and we were able to achieve a limited
polymorphism. PHP5 gave use greater polymorphism without interfaces,
interfaces are just icing on the cake.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Wed, 2007-10-10 at 13:30 -0500, Jay Blanchard wrote:
 [snip]
 so what are the benefits of the with interfaces solution over
 thewithout
  interfaces solution
 [/snip]
 
 Polymorphism.

Bleh, polymorphism isn't unique to interfaces. In fact, PHP has
polymorphism all over the place by virtue of it's loose type system. I
can pass ANY object to any function or method (that doesn't use PHP5's
restrictive type hinting stuff) and the code will just use it as long
as the appropriate member functions/variables exist. PHP doesn't need
inheritance or interfaces to achieve this. In fact this is far more
flexible than the restrictive nature of interfaces. Lemme illustrate:

class Finger
{
function wiggle()
{
echo 'A finger wiggles ominously.';
}
}

class Earthworm
{
function wiggle()
{
echo 'An earthworm wiggles around.';
}
}

function wiggle( $something )
{
if( method_exists( $something, 'wiggle' ) )
{
$something-wiggle();
}
else
{
echo 'Nothing happens.';
}
}

$finger = new Finger();
$jim = new Earthworm();

wiggle( $finger );
wiggle( $jim );

Look Ma, no inheritance, no interfaces, and we have polymorphism. in
fact, our wiggle function can take absolutely anything and just try to
wiggle it. Undoubtedly OOP purists are going to scream at this because
it just feels wrong, *hah*, too bad :)

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/10/07, Robert Cummings [EMAIL PROTECTED] wrote:

 On Wed, 2007-10-10 at 13:30 -0500, Jay Blanchard wrote:
  [snip]
  so what are the benefits of the with interfaces solution over
  thewithout
   interfaces solution
  [/snip]
 
  Polymorphism.

 Bleh, polymorphism isn't unique to interfaces. In fact, PHP has
 polymorphism all over the place by virtue of it's loose type system. I
 can pass ANY object to any function or method (that doesn't use PHP5's
 restrictive type hinting stuff) and the code will just use it as long
 as the appropriate member functions/variables exist. PHP doesn't need
 inheritance or interfaces to achieve this. In fact this is far more
 flexible than the restrictive nature of interfaces. Lemme illustrate:

 class Finger
 {
 function wiggle()
 {
 echo 'A finger wiggles ominously.';
 }
 }

 class Earthworm
 {
 function wiggle()
 {
 echo 'An earthworm wiggles around.';
 }
 }

 function wiggle( $something )
 {
 if( method_exists( $something, 'wiggle' ) )
 {
 $something-wiggle();
 }
 else
 {
 echo 'Nothing happens.';
 }
 }

 $finger = new Finger();
 $jim = new Earthworm();

 wiggle( $finger );
 wiggle( $jim );

 Look Ma, no inheritance, no interfaces, and we have polymorphism. in
 fact, our wiggle function can take absolutely anything and just try to
 wiggle it. Undoubtedly OOP purists are going to scream at this because
 it just feels wrong, *hah*, too bad :)


another interesting code example, but  the use of method_exists is in
userspace and
would have to be called everywhere you wanted to use the 'wiggleable'
interface.

could you imagine using interfaces with multiple methods and multiple
parameters w/
this technique; i think it would get rather messy.

interface A {
   function a($someVar);
   function b($someOtherVar, $anotherOtherVar);
   function c($someStupidVar)
}

very easily identified by A.

vs.

function doSomethingWithA($classInstance) {
   if(method_exists($classInstance, 'a') 
  method_exists($classInstance, 'b') 
  method_exists($classInstance, 'c')) {
$classInstance-a('a');
$classInstance-b('b', 'c');
$classInstance-c('c');
 }
}

and we dont have the ability to count the number of parameters in each
method
without using reflection or going into some unorthodox technique; more
specifically,
php doesnt provide a function similar to func_num_args() for class methods.
at
least i didnt see one here http://us3.php.net/manual/en/ref.classobj.php.
so identifying one method, no parameter interfaces would work with this
technique.
it doesnt do well for moderately complex interfaces which ill define as any
interface
with more than one method where those methods have 1 or more parameters.
yes,
code using this technique would be quite ugly for such interfaces.

another benefit of going w/ the language constructs is the existence of the
interfaces, or
other classes that would be used polymorphically is that they are defined
outside of the
code that uses them.  thats a little cleaner.
i hate digging through code where some functionality is in one place and
then mysteriously
its in another; and then a light turns on and i realize its the same
functionality in two different
places w/o a label to let me know w/o thinking they are the same.
this example is a little better than that, but still not as nice as the
language keywords.

there is a new art that php exposes; one that mingles functions and objects
without
requiring objects.  functions are not first class citizens but they have a
global visibility.
one interesting argument is that in java static methods are essentially a
way (the only way)
 to provide a global method call.  in php that isnt necessary, a function
could just be written.
but i still like the static class method; because there is the association
of the function w/
some other functions that belong to the class; there is encapsulation.

this example is cool because it illustrates some of the neat things that can
be done w/ phps
mix of objects and functions.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

2007-10-10 Thread tedd


At 9:38 AM -0400 10/10/07, Nathan Nobbe wrote:

On 10/10/07, tedd mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:

At 9:54 PM -0400 10/9/07, Nathan Nobbe wrote:

 i hope i have been able to contribute something to someone
amidst all the arguing.

-nathan



Yeah, you gave me a better appreciation of some of the members of
this list -- we have some smart people here (i.e., Rob, Tony, Larry).

Cheers,

tedd


i was waiting for an insult to that remark; thanks for filling the slot tedd.

-nathan


-nathan:

No insult was intended.  My apologies if my comment was taken that way.

I was just commenting that the above named people impressed me -- not 
that you haven't in the past. But this time, I think you're 
outnumbered for good reason. It might be a good time to reflect on 
what these fine people are saying.


Cheers,

tedd
--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/10/07, Robert Cummings [EMAIL PROTECTED] wrote:

 What I was really illustrating is how interfaces are syntactic
 sugar only. In my above example what I've really shown is an
 implicit interface :) Since OOP is largely meant to model real
 world things, ask yourself this... when a doctor sews a pig's
 heart into a human, do you think there's an explicit interface
 someplace that checks for compatibility, or does it just work
 if the conditions are right. Food for thought, pork in fact ;)


i would look at that as a great example of an interface in action.
the pigs heart has to be compatible with the human body in some
way; they both have the same interface; namely the holes the tubes
connect to.  i assume the doctors are the ones who run the interface
compatibility check.
the implementation is different i suppose (im not a biologist, just
guessing here :))  but thats the beauty of an interface; you just get
a contract, not behavior.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Wed, 2007-10-10 at 17:46 -0400, Nathan Nobbe wrote:
 On 10/10/07, Robert Cummings [EMAIL PROTECTED] wrote:
 On Wed, 2007-10-10 at 13:30 -0500, Jay Blanchard wrote:
  [snip]
  so what are the benefits of the with interfaces solution
 over
  thewithout
   interfaces solution
  [/snip] 
 
  Polymorphism.
 
 Bleh, polymorphism isn't unique to interfaces. In fact, PHP
 has
 polymorphism all over the place by virtue of it's loose type
 system. I
 can pass ANY object to any function or method (that doesn't
 use PHP5's 
 restrictive type hinting stuff) and the code will just use
 it as long
 as the appropriate member functions/variables exist. PHP
 doesn't need
 inheritance or interfaces to achieve this. In fact this is far
 more 
 flexible than the restrictive nature of interfaces. Lemme
 illustrate:
 
 class Finger
 {
 function wiggle()
 {
 echo 'A finger wiggles ominously.';
 }
 }
 
 class Earthworm 
 {
 function wiggle()
 {
 echo 'An earthworm wiggles around.';
 }
 }
 
 function wiggle( $something )
 {
 if( method_exists( $something, 'wiggle' ) )
 {
 $something-wiggle();
 }
 else
 {
 echo 'Nothing happens.';
 }
 }
 
 $finger = new Finger();
 $jim = new Earthworm();
 
 wiggle( $finger );
 wiggle( $jim ); 
 
 Look Ma, no inheritance, no interfaces, and we have
 polymorphism. in
 fact, our wiggle function can take absolutely anything and
 just try to
 wiggle it. Undoubtedly OOP purists are going to scream at this
 because 
 it just feels wrong, *hah*, too bad :)
 
 
 another interesting code example, but  the use of method_exists is in
 userspace and 
 would have to be called everywhere you wanted to use the 'wiggleable'
 interface. 

 could you imagine using interfaces with multiple methods and multiple 
 parameters w/ 
 this technique; i think it would get rather messy.
 
 interface A {
function a($someVar);
function b($someOtherVar, $anotherOtherVar); 
function c($someStupidVar)
 }
 
 very easily identified by A.
 
 vs.
 
 function doSomethingWithA($classInstance) {
if(method_exists($classInstance, 'a') 
   method_exists($classInstance, 'b')  
   method_exists($classInstance, 'c')) {
 $classInstance-a('a');
 $classInstance-b('b', 'c');
 $classInstance-c('c');
  }
 } 
 
 and we dont have the ability to count the number of parameters in each method
 without using reflection or going into some unorthodox technique; more 
 specifically,
 php doesnt provide a function similar to func_num_args() for class methods.  
 at 
 least i didnt see one here.
 so identifying one method, no parameter interfaces would work with this 
 technique.
 it doesnt do well for moderately complex interfaces which ill define as any 
 interface 
 with more than one method where those methods have 1 or more parameters.  yes,
 code using this technique would be quite ugly for such interfaces.
 
 another benefit of going w/ the language constructs is the existence of the 
 interfaces, or 
 other classes that would be used polymorphically is that they are defined 
 outside of the
 code that uses them.  thats a little cleaner.
 i hate digging through code where some functionality is in one place and then 
 mysteriously 
 its in another; and then a light turns on and i realize its the same 
 functionality in two different
 places w/o a label to let me know w/o thinking they are the same.
 this example is a little better than that, but still not as nice as the 
 language keywords. 
 
 there is a new art that php exposes; one that mingles functions and objects 
 without
 requiring objects.  functions are not first class citizens but they have a 
 global visibility.
 one interesting argument is that in java static methods are essentially a way 
 (the only way) 
  to provide a global method call.  in php that isnt necessary, a function 
 could just be written.
 but i still like the static class method; because there is the association of 
 the function w/ 
 some other functions that belong to the class; there is encapsulation. 
 
 this example is cool because it illustrates some of the neat things that can 
 be done w/ phps
 mix of objects and functions.

What I was really illustrating is how interfaces are syntactic
sugar only. In my above example what I've really shown is an
implicit interface :) Since OOP is largely meant to model real
world things, ask yourself this... when a doctor

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Wed, 2007-10-10 at 17:46 -0400, Nathan Nobbe wrote:
 On 10/10/07, Robert Cummings [EMAIL PROTECTED] wrote:
 On Wed, 2007-10-10 at 13:30 -0500, Jay Blanchard wrote:
  [snip]
  so what are the benefits of the with interfaces solution
 over
  thewithout
   interfaces solution
  [/snip] 
 
  Polymorphism.
 
 Bleh, polymorphism isn't unique to interfaces. In fact, PHP
 has
 polymorphism all over the place by virtue of it's loose type
 system. I
 can pass ANY object to any function or method (that doesn't
 use PHP5's 
 restrictive type hinting stuff) and the code will just use
 it as long
 as the appropriate member functions/variables exist. PHP
 doesn't need
 inheritance or interfaces to achieve this. In fact this is far
 more 
 flexible than the restrictive nature of interfaces. Lemme
 illustrate:
 
 class Finger
 {
 function wiggle()
 {
 echo 'A finger wiggles ominously.';
 }
 }
 
 class Earthworm 
 {
 function wiggle()
 {
 echo 'An earthworm wiggles around.';
 }
 }
 
 function wiggle( $something )
 {
 if( method_exists( $something, 'wiggle' ) )
 {
 $something-wiggle();
 }
 else
 {
 echo 'Nothing happens.';
 }
 }
 
 $finger = new Finger();
 $jim = new Earthworm();
 
 wiggle( $finger );
 wiggle( $jim ); 
 
 Look Ma, no inheritance, no interfaces, and we have
 polymorphism. in
 fact, our wiggle function can take absolutely anything and
 just try to
 wiggle it. Undoubtedly OOP purists are going to scream at this
 because 
 it just feels wrong, *hah*, too bad :)
 
 
 another interesting code example, but  the use of method_exists is in
 userspace and 
 would have to be called everywhere you wanted to use the 'wiggleable'
 interface. 

 could you imagine using interfaces with multiple methods and multiple
parameters w/ 
 this technique; i think it would get rather messy.
 
 interface A {
function a($someVar);
function b($someOtherVar, $anotherOtherVar); 
function c($someStupidVar)
 }
 
 very easily identified by A.
 
 vs.
 
 function doSomethingWithA($classInstance) {
if(method_exists($classInstance, 'a') 
   method_exists($classInstance, 'b')  
   method_exists($classInstance, 'c')) {
 $classInstance-a('a');
 $classInstance-b('b', 'c');
 $classInstance-c('c');
  }
 } 
 
 and we dont have the ability to count the number of parameters in each
method
 without using reflection or going into some unorthodox technique; more
specifically,
 php doesnt provide a function similar to func_num_args() for class
methods.  at 
 least i didnt see one here.
 so identifying one method, no parameter interfaces would work with this
technique.
 it doesnt do well for moderately complex interfaces which ill define as
any interface 
 with more than one method where those methods have 1 or more parameters.
yes,
 code using this technique would be quite ugly for such interfaces.
 
 another benefit of going w/ the language constructs is the existence of
the interfaces, or 
 other classes that would be used polymorphically is that they are defined
outside of the
 code that uses them.  thats a little cleaner.
 i hate digging through code where some functionality is in one place and
then mysteriously 
 its in another; and then a light turns on and i realize its the same
functionality in two different
 places w/o a label to let me know w/o thinking they are the same.
 this example is a little better than that, but still not as nice as the
language keywords. 
 
 there is a new art that php exposes; one that mingles functions and
objects without
 requiring objects.  functions are not first class citizens but they have a
global visibility.
 one interesting argument is that in java static methods are essentially a
way (the only way) 
  to provide a global method call.  in php that isnt necessary, a function
could just be written.
 but i still like the static class method; because there is the association
of the function w/ 
 some other functions that belong to the class; there is encapsulation. 
 
 this example is cool because it illustrates some of the neat things that
can be done w/ phps
 mix of objects and functions.

What I was really illustrating is how interfaces are syntactic
sugar only. In my above example what I've really shown is an
implicit interface :) Since OOP is largely meant to model real
world things, ask yourself this... when a doctor sews a pig's
heart into a human, do

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Wed, 2007-10-10 at 20:45 -0400, Nathan Nobbe wrote:
 On 10/10/07, Robert Cummings [EMAIL PROTECTED] wrote:
 
  What I was really illustrating is how interfaces are syntactic
  sugar only. In my above example what I've really shown is an
  implicit interface :) Since OOP is largely meant to model real
  world things, ask yourself this... when a doctor sews a pig's
  heart into a human, do you think there's an explicit interface
  someplace that checks for compatibility, or does it just work
  if the conditions are right. Food for thought, pork in fact ;)
 
 
 i would look at that as a great example of an interface in action.
 the pigs heart has to be compatible with the human body in some
 way; they both have the same interface; namely the holes the tubes
 connect to.  i assume the doctors are the ones who run the interface
 compatibility check.
 the implementation is different i suppose (im not a biologist, just
 guessing here :))  but thats the beauty of an interface; you just get
 a contract, not behavior.

That's right... it's an implicit interface, not an explicit interface,
the doctor doesn't run to some God/Evolution/Simulation mandated
interface to check his implementation. He just wires things up, does
some tweaking, hopes for the best. He doesn't get any feedback like
Sorry, pig's heart must implement HumanBlood interface. If it isn't
compatible the human dies-- that's a perfect example of an implicit
interface, the body will just do what it usually does regardless of
whether you hook up a pig's heart or a kitchen sink. Compatibility will
be decided at run-time :)

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Wed, 2007-10-10 at 20:57 -0500, Larry Garfield wrote:
 On Wednesday 10 October 2007, Nathan Nobbe wrote:
  On 10/10/07, Robert Cummings [EMAIL PROTECTED] wrote:
   What I was really illustrating is how interfaces are syntactic
   sugar only. In my above example what I've really shown is an
   implicit interface :) Since OOP is largely meant to model real
   world things, ask yourself this... when a doctor sews a pig's
   heart into a human, do you think there's an explicit interface
   someplace that checks for compatibility, or does it just work
   if the conditions are right. Food for thought, pork in fact ;)
 
  i would look at that as a great example of an interface in action.
  the pigs heart has to be compatible with the human body in some
  way; they both have the same interface; namely the holes the tubes
  connect to.  i assume the doctors are the ones who run the interface
  compatibility check.
  the implementation is different i suppose (im not a biologist, just
  guessing here :))  but thats the beauty of an interface; you just get
  a contract, not behavior.
 
  -nathan
 
 Pig heart transpants?  That's almost as good as Godwin's Law. :-)  (This 
 thread has been going on long enough that the statistical odds of it cropping 
 up are getting good.)

Whatever you say thread Nazi!

;) ;) ;)

I invoke Godwin's Law.
Now I invoke Quirk's exception.

Nyah, nyah :)

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

2007-10-10 Thread Larry Garfield

On Wednesday 10 October 2007, Nathan Nobbe wrote:
 On 10/10/07, Robert Cummings [EMAIL PROTECTED] wrote:
  What I was really illustrating is how interfaces are syntactic
  sugar only. In my above example what I've really shown is an
  implicit interface :) Since OOP is largely meant to model real
  world things, ask yourself this... when a doctor sews a pig's
  heart into a human, do you think there's an explicit interface
  someplace that checks for compatibility, or does it just work
  if the conditions are right. Food for thought, pork in fact ;)

 i would look at that as a great example of an interface in action.
 the pigs heart has to be compatible with the human body in some
 way; they both have the same interface; namely the holes the tubes
 connect to.  i assume the doctors are the ones who run the interface
 compatibility check.
 the implementation is different i suppose (im not a biologist, just
 guessing here :))  but thats the beauty of an interface; you just get
 a contract, not behavior.

 -nathan

Pig heart transpants?  That's almost as good as Godwin's Law. :-)  (This 
thread has been going on long enough that the statistical odds of it cropping 
up are getting good.)

-- 
Larry Garfield  AIM: LOLG42
[EMAIL PROTECTED]   ICQ: 6817012

If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it.  -- Thomas 
Jefferson

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

well i have to say i dont really see the difference between an implicit and
explicit interface.

the example you gave looks like it works just like the example i gave.

in your example the check for the function is performed at runtime.
in the example i gave the check for the interface is performed at runtime.

the only difference is that in mine php does the check and in yours
method_exists()
does the check.

if somebody wanted to do something innocuous in the lawn mower example
they could try to cut a brick; that would probly bend the blades or
something.


-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Wed, 2007-10-10 at 22:15 -0400, Nathan Nobbe wrote:
 well i have to say i dont really see the difference between an
 implicit and explicit interface.
 
 the example you gave looks like it works just like the example i gave.
 
 in your example the check for the function is performed at runtime. 
 in the example i gave the check for the interface is performed at
 runtime.

Interfaces are checked at parse time. I'm very sure you need to include
the interface description before you can implement it. That makes it
explicit. My example doesn't need any interface description, the
interface of wiggle() is implicit.

 the only difference is that in mine php does the check and in yours
 method_exists()
 does the check.

I only put that there for fun. I could have skipped the check entirely.
Then it would be expected that the wiggle() method existed. If the
method doesn't exist then at run time the script will stop-- fortunately
with a fatal error :)

Cheers,
Rob
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/10/07, Robert Cummings [EMAIL PROTECTED] wrote:

 On Wed, 2007-10-10 at 22:15 -0400, Nathan Nobbe wrote:
  well i have to say i dont really see the difference between an
  implicit and explicit interface.
 
  the example you gave looks like it works just like the example i gave.
 
  in your example the check for the function is performed at runtime.
  in the example i gave the check for the interface is performed at
  runtime.

 Interfaces are checked at parse time. I'm very sure you need to include
 the interface description before you can implement it. That makes it
 explicit. My example doesn't need any interface description, the
 interface of wiggle() is implicit.

  the only difference is that in mine php does the check and in yours
  method_exists()
  does the check.

 I only put that there for fun. I could have skipped the check entirely.
 Then it would be expected that the wiggle() method existed. If the
 method doesn't exist then at run time the script will stop-- fortunately
 with a fatal error :)


i suppose the same could be done with the interface construct as well;
simply remove the type hinting with the name of the interface and the
call becomes implicit.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/7/07, Robert Cummings [EMAIL PROTECTED] wrote:

   it just so happens i
  have a good friend with a very strong php background who tells me
  practically the same thing, ppp isnt that big of a deal.

 It isn't.


i disagree.

 i disagree, why,
  is it because ive had a classical education in oop

 What the heck is a classical education in OOP? Are you saying your old
 and therefore smarter? Young and therefor smarter? WTF?


just saying i studied oop in college.  i started w/ c++; moved on to java
and then took a brief look
at .net and delphi (very brief :))  anyway coming from those languages to
php4,
well php4 looks minimalistic.
age has nothing to do with it; i provided 4 definitions from 4 books
on oop; they all conicide w/ what ive been saying about encapsualtion;
infact they practically
say encapsulation is data hiding.
i would like to see an example of encapsulation where data hiding isnt
required to conceal the
implementation.

 , because ive worked with
  a number of languages that dont allow you to create class members
 without
  specifying an access level?

 Many of us have done this. Your point?


php4 is the first language i encountered that didnt offer ppp.

   for those reasons and because ive had the
  misfortune of working in places that have tightly coupled code.  im
 talking
  about hundreds of thousands of lines of madness.  ppp could have saved
 these
  systems greatly.

 Once again, just because someone writes bad programs doesn't make PPP
 the superior choice. A shitty programmer faced with PPP will more than
 likely declare all of their member variables as public and as such will
 have gained nothing.

  Also, don't forget that abstraction, encapsulation, and information
   hiding all have a price
 
  if youre referring to performance i think the price of not using these
 tools
  is also worth mention.  namely code which is easily subject to tight
  coupling, which as i said leads to systems that are difficult to
 maintain
  and extend.
  personally i value maintainability and extensibility over performance,
 but
  thats merely a personal preference.

 Tell that to an embedded systems programmer.


ok.
embedded systems programmer -  i develop web applications w/ php.  i use oop
and build systems designed for large audiences and large numbers of
developers.
being able to extend, modify, and maintain the code are more important than
small
performance gains here and there; because i can always call dell for another
1u.

 (tony)
   I strongly disagree. It *IS* possible to write perfectly adequate OO
  programs
   using PHP 4. If you cannot then you have been taught some bad habits.

 Hear hear.


on the contrary, im trying to emphasize what i have learned to be bad habits
so others
might not use them in the first place.  one of which i have mentioned
is allowing direct access to class members.  and i was never taught to do
that, because as
i mentioned, i worked with languages that require use of ppp in the past,
and one of the first
things thats covered is marking member variables private, and certain member
functions of
course.

 and what exactly does adequate mean?  any oo php4 'program' is inherently
  weak for the reasons i have sighted, namely the implementation can be

 I'm sur eyou meant cited above.


yes

 latched onto producing tightly coupled code.
  dont worry tony, i can construe some pretty decent php4 code myself; i
 wrote
  a date time package that ive ported to 3 projects including a conversion
 to
  php5 in one of those.  the point is that the other developers i work
 with
  dont have a clue about object oriented concepts which in my experience
  constitutes the vast majority of php developers.  the even bigger point,
 on
  the topic of this thread is that php4 is out the door, so there is yet
  another possibly more important reason not to waste time learning oop
  studying php4.

 Once again, if you suck at programming you suck at programming. Those
 sucky programmers are probably going to declare all their member vars
 public, aren't going to understand encapsulation, probably will have
 terrible class hierarchies, etc. You can't make a good programmer by
 holding their hand.


again; all the books ive ever read on oop, show class member variables being
marked private.
also, they emphasize protecting certain methods as well.  php4 doesnt offer
ppp, so it opens
the door to bad habits.
you can however protect your underlying codebase from misuse.  how practical
is it
to get a company that consists entirely of excellent programmers?

 ive studied oop for years and worked with a number of oop languages; many
 of
  the bad habits i had at one point or another have been removed.  guess
 what
  the first one was, not letting client code access member variables
 directly
  :)

 I've worked with many languages too. I found my code getting better
 while using C. I learned to properly prefix function names, collect them
 together in the same file, use structures instead

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/6/07, Tony Marston [EMAIL PROTECTED] wrote:

 Encapsulation and information hiding are separate topics. It is possible
 to
 have one without the other.


see the revision of my php4 critique.

 here are excerpts from 4
  books, 2 on java, one on c++, and one on php:
 
  This abstraction works only if we are careful to respect its boundaries.
  An
  object should be self-governing, which means
  that the variables contained in an object should be modified only within
  the
  object.  Only the methods within an object should
  have access to the variables in that object.

 The principle of encapsulation has no such rule! Encapsulation is merely
 the
 act of placing variables and the methods which act upon those variables in
 the same object. It is not necessary to hide any variables.

 Encapsulation is NOT data hiding. Take a look at

 http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
 http://www.itmweb.com/essay550.htm
 http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding

   For example, the methods of
  the Coin class should be solely responsible for changing
  the value of the face variable.  We should make it difficult, if not
  impossible, for code outside of a class to reach in and change the
  value of a variable that is declared inside the class.
  Page 220. - 221
  Java Software Solutions foundations of program design 3rd edition Lewis
 
  Loftus
  The specification of what a function does and how it is invoked defines
  its
  interface.  By hiding a module implementation, or encapsulating
  the module, we can make changes to it without changing the main
 function,
  as
  long as the interface remains the same.  For example, you
  might rewrite the body of a function using a more efficient algorithm.
  Encpasulation: Hiding a module implementation in a separate block with a
  formally specified interface.

 The implementation is the CODE behind the method, not the DATA that the
 code
 manipulates. Encapsulation is IMPLEMENTATION hiding, not DATA hiding.


when variables store data needed to realize  the outcome of some method;
they
become part of the implementation and therefore should not be exposed to
client code.

 Page 354
  Programming and Problem Solving with C++ Second Edition
  Nell Dale, Chip Weems, Mark Headington
 
  OOP revolves around the concept of grouping code and data together in
  logical units called classes.  This process is usually referred to as
  encapsulation,

 Correct.

  or information hiding,

 INCORRECT

  since its goal is that of dividing an
  application into separate entities whose internal components can
  change without altering their external interfaces.

 No. The idea behind encapsulation is that the implementation, the code
 behind a method, can change at any time without the outside world being
 aware of it. Data is *NOT* the implemetation.

  Page 113.
  Zend PHP5 Certification Study Guide
  Davey Shafik
 
  Access control is often referred to as implementation hiding.

 But wrongly! Access control is NOT implementation hiding, it is a totally
 separate issue.

  Wrapping data
  and methods within classes in combination with implementation
  hiding is often called encapsulation4*

 That is correct. But only the implementation (the code behnd each method)
 is
 hidden, not the data.

   The result is a data type with
  characteristics and behaviors.
  * However, people often refer to implementation hiding alone as
  encapsulation.
  Page 231
  Thinking in Java Third Edition
  Bruce Eckel
 
  tonight when i get home ill post
   a  snippet from an entry level oop book (such that i recommend
 earlier)
   that
   says almost
   verbatim what i have.
  
   practically any non-trivial class will have member variables that it
  uses
   in
   order to facilitate
   its member functions.
 
  So what? Those variables do not have to be private or protected in
 order
  to
  function.
 
 
  They dont have to be marked private or protected to function, but in
 order
  to prevent
  client code from latching onto the implementation details of the class;
  they
  need to be
  hidden.

 Wrong! DATA does not define the implementation, it is the CODE which
 manipulates that data which defines the implementation. The idea of
 encapsulation is that you can change the code within any method at will
 without the outside world being aware of it.


it is also about client code not being able to  view and manipulate the
implementation.
if client code can access data that the implementation (as you define it
[not consisting of data])
uses, or relys upon, then the outcome of the implementation can be altered
by client code.
that is a violation of encapsulation, which is precisely why data is part of
the implementation,
and it needs to be concealed from client code to maintain the integrity of
the implementation.

The fundamental concepts of OOP consist of nothing more than encapsulation,
 inheritance and polymorphism. Data hiding, interfaces and all that

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/7/07, Robert Cummings [EMAIL PROTECTED] wrote:

 On Sun, 2007-10-07 at 11:42 +0100, Tony Marston wrote:
 
  The definition of OOP is programming which is oriented around objects,
 thus
  taking advantage of Encapsulation, Polymorphism, and Inheritance to
 increase
  code reuse and decrease code maintenance. It is possible to do this in
 PHP
  4 without all the fancy add-ons which appeared in PHP 5. How do I know?
  Because I have written an entire framework using objects in PHP 4, and
 the
  result is high code reuse and low maintainence. There are no additional
 OO
  features in PHP 5 which could deliver any measurable improvements.


not all systems will stand to gain from the features in php5.  but  ppp is a
very important  feature;
i would say any code that is not using  ppp could stand to benefit from it.
the interface construct is in my opinion the biggest enhancement to the php5
oop feature set, as
it offers a new avenue for polymorphic code.


any oo php4 'program' is inherently
   weak for the reasons i have sighted, namely the implementation can be
   latched onto producing tightly coupled code.
 
  Coupling is the degree of interaction between two modules. Low levels of
  coupling tend to create code which is more reusable, whereas high levels
 of
  coupling tend to create code which is less reusable. Coupling is
 therefore
  directly related to reusability. Making all variables private does not
 *in
  itself* make the code more reusable, therefore it does not make the code
  more coupled or less coupled.


all i said is that it prevents client code from becoming dependent upon
implementation
details, which doesnt reduce reusability, but does make the code difficult
to change
because at that point the client code needs to be changed as well.

Well, Nathan is assuming that if you have a public member that you
 probably didn't provide get/set wrappers for it. As such directly using
 the member variable does indeed increase the couple of your code to that
 module because if the variable needs to change in some way it's not
 possible to change the behaviour across the board without updating all
 uses of the member variable.

 However, just because it's public doesn't mean it doesn't have a get/set
 wrapper and doesn't mean it should be used directly. Yes, using a
 private declaration enforces use of the get/set wrapper, but once again,
 documentation can make this point also and as such marking a member
 variable as private is just syntactic sugar.

 Strangely enough though, PHP5 provides the means to NOT provide get/set
 methods and still modify the behaviour of direct access to a member
 variable via the magic __get/__set methods. Therefore the coupling issue
 is pretty moot for PHP5 regardless of how the variable is accessed.


a class writer would have to use the __get and __ set methods in their class
to expose access to private members.  those methods are suitable for special
purposes and anyway client code cant use them if theyre not defined in a
class,
so i dont consider the coupling issue moot.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

wow, this thread has blown into a massive debate about oop.
well, i guess im the only one on the list who doesnt think php4 brings
enough to the table with its oop offerings.
the conversation has taken focus on what encapsulation is or isnt, but
recall, i pointed out there are many advantages php5 has.  i just think ppp
is one of the major features, if not the major feature that php4 lacks that
makes me shy away from it.
im not the only one who feels this way; i just must be the only one on the
list
who cares to say anything about it.  well here is an excerpt from the source
of code igniter, a popular open source php framework written in both php4
and
php5.

/**
 * CI_BASE - For PHP 4
 *
 * This file is used only when CodeIgniter is being run under PHP 4.
 *
 * In order to allow CI to work under PHP 4 we had to make the Loader class
 * the parent of the Controller Base class.  It's the only way we can
 * enable functions like $this-load-library('email') to instantiate
 * classes that can then be used within controllers as $this-email-send()
 *
 * PHP 4 also has trouble referencing the CI super object within application
 * constructors since objects do not exist until the class is fully
 * instantiated.  Basically PHP 4 sucks...
 *
 * Since PHP 5 doesn't suffer from this problem so we load one of
 * two files based on the version of PHP being run.
 *
 * @packageCodeIgniter
 * @subpackagecodeigniter
 * @categoryfront-controller
 * @authorRick Ellis
 * @linkhttp://www.codeigniter.com/user_guide/
 */

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/9/07, Nathan Nobbe [EMAIL PROTECTED] wrote:

 On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:
 
 
  Then how come these languages still offer PUBLIC access as an option?



 to expose a well defined interface of course.

 -nathan


and i have a question for you, Tony;
are variables local to a function not part of the function implementation?
i would say they are.  and in that light it is understandable, even
believable that class member variables comprise the implementation of the
class, no ?

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:


 Then how come these languages still offer PUBLIC access as an option?



to expose a well defined interface of course.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4


Nathan Nobbe [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 On 10/7/07, Robert Cummings [EMAIL PROTECTED] wrote:

   it just so happens i
  have a good friend with a very strong php background who tells me
  practically the same thing, ppp isnt that big of a deal.

 It isn't.

 i disagree.

And I disagree with you. Marking variables, or even methods, as anything 
other than public is purely OPTIONAL. If it were a requirement then the 
public keyword simply would not exist.

 i disagree, why,
  is it because ive had a classical education in oop

 What the heck is a classical education in OOP? Are you saying your old
 and therefore smarter? Young and therefor smarter? WTF?

 just saying i studied oop in college.  i started w/ c++; moved on to java
 and then took a brief look
 at .net and delphi (very brief :))  anyway coming from those languages to
 php4,

Just because it is what you were taught does not necessarily make it the 
gospel truth. Different teachers teach different things, and they cannot all 
be right.

 well php4 looks minimalistic.
 age has nothing to do with it; i provided 4 definitions from 4 books
 on oop; they all conicide w/ what ive been saying about encapsualtion;
 infact they practically
 say encapsulation is data hiding.
 i would like to see an example of encapsulation where data hiding isnt
 required to conceal the implementation.

Encapsulation is NOT data hiding. Take a look at

http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
http://www.itmweb.com/essay550.htm
http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding

Encapsulation is about *implementation* hiding and implementation is *code*, 
not *data*. Data is information, and encapsulation does NOT mean 
*information hiding.

 because ive worked with
 a number of languages that dont allow you to create class members
 without specifying an access level?

 Many of us have done this. Your point?

 php4 is the first language i encountered that didnt offer ppp.

So what? PHP is the first language I have use in the past 30 years which 
supported OOP. None of the languages I have *ever* used have supported the 
notion of private or protected access - apart from the permissions system in 
the underlying database, of course.

I have learned to program without PPP, so I do not see any signifcant 
advantage in using it.

  for those reasons and because ive had the
 misfortune of working in places that have tightly coupled code.  im
 talking about hundreds of thousands of lines of madness.  ppp could have
 saved these systems greatly.

 Once again, just because someone writes bad programs doesn't make PPP
 the superior choice. A shitty programmer faced with PPP will more than
 likely declare all of their member variables as public and as such will
 have gained nothing.

snip

 (tony)
 I strongly disagree. It *IS* possible to write perfectly adequate OO
 programs using PHP 4. If you cannot then you have been taught some bad 
 habits.

 Hear hear.

 on the contrary, im trying to emphasize what i have learned to be bad 
 habits
 so others
 might not use them in the first place.  one of which i have mentioned
 is allowing direct access to class members.  and i was never taught to do
 that, because as
 i mentioned, i worked with languages that require use of ppp in the past,
 and one of the first
 things thats covered is marking member variables private, and certain 
 member
 functions of course.

Just because YOU were taught to always make variables private does not mean 
that everybody else should do the same. A competent programmer can produce 
perfectly functional programs without using ppp at all, so it is not 
necessary.

snip

 again; all the books ive ever read on oop, show class member variables 
 being
 marked private.

So what? None of the books or articles I have ever read on OOP have shown 
any such thing. They simply point out where it MAY be used to stop an 
incompetent programmer from screwing things up, but whatever obstacles you 
put in their way will only cause them to find other ways to screw up.

 also, they emphasize protecting certain methods as well.  php4 doesnt 
 offer
 ppp, so it opens
 the door to bad habits.

In your opinion.

 you can however protect your underlying codebase from misuse.  how 
 practical
 is it to get a company that consists entirely of excellent programmers?

It is simply not possible to protect ANY program from misuse. As soon as 
someone thinks that they have made something idiot proof the universe 
esponds by creating a better class of idiot.

 ive studied oop for years and worked with a number of oop languages; many
 of
  the bad habits i had at one point or another have been removed.  guess
 what
  the first one was, not letting client code access member variables
 directly

Then how come these languages still offer PUBLIC access as an option?

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

-- 
PHP General Mailing List

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:

 You are confusing member variables with local variables. Member variables
 are part of the object's data which need to be made available to the
 outside
 world. Local variables are internal to the function, and do not need to be
 made available to the outside world. Local variables are part of the
 implementation, member varables are not.


no im not confusing anything;
local variables are within the scope of the function; therefore they are
part of the function
implementation.
instance variables are part of the scope of a class instance, therefore they
are part of its
implementation.

Implementation means the act of changing data, therefore it means the code
 and not the data itself.


code is nothing w/o data to manipulate; what is an algorithm w/o data to
manipulate; it
simply would not exist.

snip

  it is also about client code not being able to  view and manipulate the
  implementation.
  if client code can access data that the implementation (as you define it
  [not consisting of data])
  uses, or relys upon, then the outcome of the implementation can be
 altered
  by client code.

 Then surely if a programmer fucks things up in such a fashion it would
 become apparent during unit testing? Then the culprit can be soundly
 whipped
 until he lears NOT to fuck up.


or better yet; protect the  implementation so he wouldnt have to be whipped
in the
first place.

 that is a violation of encapsulation,

 I disagree.Encapsulation is the act of placing the data, and the
 operations
 which act upon that data, in the same object. A violation of encapsulation
 is therefore to put the data and its operations in more than one object.
 Encapsulation has absolutely nothing to do with how those objects are used
 (or abused).

  which is precisely why data is part of the implementation,
  and it needs to be concealed from client code to maintain the integrity
 of
  the implementation.
 
  The fundamental concepts of OOP consist of nothing more than
  encapsulation,
  inheritance and polymorphism. Data hiding, interfaces and all that
 other
  fancy stuff are irrelevant.
 
  youre missing out on like the last decade or so of oop.

 I am sticking to the fundamentals and deliberately ignoring all the crap
 which has been added on by everybody and his dog.


hmm; the rest of the oop community seems to be flocking to the crap.

im not going to take the
  time to try and explain the power of the interface construct.  imho,
 you
  have a long way to
  go before you can grasp the power of the mechanism.
 
  I have never seen any gain from using interfaces in PHP, only pain,
  therefore I refuse to use them. Yet what functinality I am losing? None
  whatsoever.
 
  not every system will benefit from interfaces.
  it sounds like you dont fully understand the use of them; and i wont say
  its
  immediately obvious.

 If it is not obvious in the way that interfaces can provide benefits then
 they are useless as far as I am concerned. I have never seen ANY
 documentation which shows ANY benefits from using interfaces, so I simply
 do
 not see the point in using them.

  as i said they offer an additional polymorphic mechanism
  one that php4 doesnt supply.

 I can achieve all the polymorphism I need WITHOUT using interfaces, so I
 do
 not see the point in using them.


like i said not every system will benefit.

 if you want a great example of how they are used and when extension is not
  desirable (because the behavior is passed along) read the first chapter
 of
  heads first design patterns.

 I refuse to read any more books on design patterns. In my opinion they are
 abused, over-used and over-rated. Just because one or two design patterns
 use interfaces does not mean that interfaces are the best thing since
 sliced
 bread.


it would be nice if you saw just one example why they are sometimes better
than
inheritance and therefore useful.

 in summary, i still maintain, based upon the contents of this post and
  the
  many previous posts
  that sitting down and trying to learn oop with php4 is a waste of
 time.
 
  I strongly disagee. It *IS* possible to write perfectly adequate OO
  programs
  using PHP 4. If you cannot then you have been taught some bad habits.
 
 
  actually, im trying to illustrate  bad habits so they may be avoided by
  other developers.
 
  That is just your opinion. My opinion is totally different.
 
 
  thats why i gave an alternate critique based upon your definition of
  encapsulation.
 
  also, i should mention its occurred to me that the abstract class
  mechanism
  in php5 is superior to your mechanism in php4.
  if a method marked as abstract in php5 is not overridden by client code,
  an
  error is raised at
  compile time, and the class is  not allowed to be utilized.

 This still does not get away from the fact hat it is still possible to
 create an absract class in PHP 4 without having to use the keyword
 abstract in the class definition.

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Tue, 2007-10-09 at 09:12 -0400, Nathan Nobbe wrote:
 On 10/7/07, Robert Cummings [EMAIL PROTECTED] wrote:

  Nothing brittle at all about PHP4 code. I can completely screw
  up any PHP5 code you send my way too.

 ok;
 without modifying this class, set the value of $someInt to a value
 greater than
 100 or less than 0.
 
 class TryToViolateEncapsulation {
 private $someInt = 0;
 
 public function getSomeInt() { 
return $this-someInt;
 }
 
 public function setSomeInt($someInt) {
 $success = false;  // assume failure
 $someInt = (int) $someInt;
 if($this-isValid($someInt)) { 
   $this-someInt = $someInt;
   $success = true;
 }
 
 return $success;
 }
 
 private function isValid($someInt) {
$isValid = true;
if($someInt  0 || $someInt  100) { 
   $isValid = false;
}
return $isValid;
}
 }

$sucker = new TryToViolateEncapsulation();
$sucker = (array)$sucker;
 
$keys = array_keys( $sucker );
$sucker[reset( $keys )] = 500;

$sucker = serialize( (object)$sucker );
$sucker = 'O:25:TryToViolateEncapsulation'.substr( $sucker, 14 );
$sucker = unserialize( $sucker );

print_r( $sucker );

:::

Maybe next time you'll have a challenge for me ;) And don't whine about
how I achieved what I did.

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

2007-10-09 Thread Christoph Boget


 Maybe next time you'll have a challenge for me ;) And don't whine about
 how I achieved what I did.


Brilliant!  I never would have thought of that. ;)

thnx,
Christoph

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:

 Maybe next time you'll have a challenge for me ;)


bravo!  i expected you would come up w/ something.

And don't whine about
 how I achieved what I did.


fair enough.


maybe for your next trick youll build an interface in php4; or address the
problem outlined in
the code igniter comment.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Tue, 2007-10-09 at 11:41 -0400, Christoph Boget wrote:
 
  Maybe next time you'll have a challenge for me ;) And don't whine about
  how I achieved what I did.
 
 
 Brilliant!  I never would have thought of that. ;)

It gets easier... here's a quick toolset for completely violating PHP5
objects :)

function objectCast( $object, $class )
{
$newObject =
'O:'.strlen( $class ).':'.$class.''
   .substr( serialize( (object)(array)$object ), 14 );

$newObject = unserialize( $newObject );

$object = $newObject;
}
 
function arraySetPrivateField
( $objectArray, $className, $fieldName, $value )
{
$objectArray[\x00$className\x00$fieldName] = $value;
}
 
 
echo \n;

$sucker = new TryToViolateEncapsulation();
$sucker = (array)$sucker;

print_r( $sucker );

arraySetPrivateField( $sucker, 'TryToViolateEncapsulation', 'someInt',
501 );
objectCast( $sucker, 'TryToViolateEncapsulation' );

print_r( $sucker );


-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4


Nathan Nobbe [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:

 You are confusing member variables with local variables. Member variables
 are part of the object's data which need to be made available to the
 outside
 world. Local variables are internal to the function, and do not need to 
 be
 made available to the outside world. Local variables are part of the
 implementation, member varables are not.


 no im not confusing anything;
 local variables are within the scope of the function; therefore they are
 part of the function
 implementation.
 instance variables are part of the scope of a class instance, therefore 
 they
 are part of its
 implementation.

 Implementation means the act of changing data, therefore it means the 
 code
 and not the data itself.


 code is nothing w/o data to manipulate; what is an algorithm w/o data to
 manipulate; it simply would not exist.

I disagree. The dictionary definition of implementation is an activity or 
process. The fact that an implementation works with data does not make that 
data part of that implementation. Data is free standing and can be 
maniplated by several different implementations, and an implementation can 
work with with any set of data. So implementation, or the activity/process, 
means nothing more than the code, with the data being separate and 
independent.

 snip

  it is also about client code not being able to  view and manipulate the
  implementation.
  if client code can access data that the implementation (as you define 
  it
  [not consisting of data])
  uses, or relys upon, then the outcome of the implementation can be
  altered by client code.

 Then surely if a programmer fucks things up in such a fashion it would
 become apparent during unit testing? Then the culprit can be soundly
 whipped until he learns NOT to fuck up.

 or better yet; protect the  implementation so he wouldnt have to be 
 whipped
 in the first place.

A bad programmer will ALWAYS find new and obscure ways to fuck up. Isn't it 
the abuse of inheritance which spawned the idea of object composition as a 
replacement for inheritace?

 that is a violation of encapsulation,

 I disagree.Encapsulation is the act of placing the data, and the
 operations
 which act upon that data, in the same object. A violation of 
 encapsulation
 is therefore to put the data and its operations in more than one object.
 Encapsulation has absolutely nothing to do with how those objects are 
 used
 (or abused).

  The fundamental concepts of OOP consist of nothing more than
  encapsulation, inheritance and polymorphism. Data hiding, interfaces
  and all that other fancy stuff are irrelevant.
 
  youre missing out on like the last decade or so of oop.

 I am sticking to the fundamentals and deliberately ignoring all the crap
 which has been added on by everybody and his dog.

 hmm; the rest of the oop community seems to be flocking to the crap.

The fact that others flock like mindless sheep to the latest fad or fancy 
just shows how gullible they are.

  im not going to take the
  time to try and explain the power of the interface construct.  imho,
  you have a long way to
  go before you can grasp the power of the mechanism.
 
  I have never seen any gain from using interfaces in PHP, only pain,
  therefore I refuse to use them. Yet what functinality I am losing? 
  None
  whatsoever.
 
  not every system will benefit from interfaces.
  it sounds like you dont fully understand the use of them; and i wont 
  say
  its immediately obvious.

 If it is not obvious in the way that interfaces can provide benefits then
 they are useless as far as I am concerned. I have never seen ANY
 documentation which shows ANY benefits from using interfaces, so I simply
 do not see the point in using them.

  as i said they offer an additional polymorphic mechanism
  one that php4 doesnt supply.

 I can achieve all the polymorphism I need WITHOUT using interfaces, so I
 do not see the point in using them.


 like i said not every system will benefit.

 if you want a great example of how they are used and when extension is 
 not
  desirable (because the behavior is passed along) read the first chapter
  of heads first design patterns.

 I refuse to read any more books on design patterns. In my opinion they 
 are
 abused, over-used and over-rated. Just because one or two design patterns
 use interfaces does not mean that interfaces are the best thing since
 sliced
 bread.


 it would be nice if you saw just one example why they are sometimes better
 than inheritance and therefore useful.

I have bought and read several books on design patterns without being 
impressed. I have seen countless examples of how particular design patterns 
can be implemented, and I am even more unimpressed. Unless you can explain, 
simply and with simple examples, of things that can ONLY be achieved through 
the use of interfaces then I will continue to say tha they

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

2007-10-09 Thread Andrew Ballard

On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:
 $sucker = new TryToViolateEncapsulation();
 $sucker = (array)$sucker;

 $keys = array_keys( $sucker );
 $sucker[reset( $keys )] = 500;

 $sucker = serialize( (object)$sucker );
 $sucker = 'O:25:TryToViolateEncapsulation'.substr( $sucker, 14 );
 $sucker = unserialize( $sucker );

 print_r( $sucker );

 :::

 Maybe next time you'll have a challenge for me ;) And don't whine about
 how I achieved what I did.


That's a bit disturbing. Ok, while we're bending things a bit, I'll
make it a *little* tougher. :-)

class TryToViolateEncapsulation {
private $someInt = 0;

const MAX_INT = 100;
const MIN_INT = 0;

public function getSomeInt() {
   return $this-someInt;
}

public function setSomeInt($someInt) {
$success = false;  // assume failure
$someInt = (int) $someInt;
if($this-isValid($someInt)) {
  $this-someInt = $someInt;
  $success = true;
} else {
throw new InvalidArgumentException('Invalid value passed to
setSomeInt');
}

return $success;
}

private function isValid($someInt) {
   $isValid = true;
   if($someInt  TryToViolateEncapsulation::MIN_INT  || $someInt 
TryToViolateEncapsulation::MAX_INT) {
  $isValid = false;
   }
   return $isValid;
   }

   public function __wakeup() {
$this-setSomeInt($this-someInt);
   }
}

Of course, my gripe with __wakeup is that it is essentially a PHP
implementation function that, IMO, should be private. However, it must
be declared public for it to work, and that means that anyone outside
the class can call it whenever they want.

While I'm not totally sold on OOP for web pages, I still like PHP5
because of the OO enhancements over PHP4. Can you code without them?
Sure. I can cut my grass with a push mower, too -- but I tend to like
my lawn tractor much better.

However, thank you for demonstrating that I need to be MUCH more
careful when building objects to validate member values each time they
are used, and not just when they are set.

Andrew

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Tue, 2007-10-09 at 11:49 -0400, Nathan Nobbe wrote:
 On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:
 
  Maybe next time you'll have a challenge for me ;)
 
 
 bravo!  i expected you would come up w/ something.
 
 And don't whine about
  how I achieved what I did.
 
 
 fair enough.
 
 
 maybe for your next trick youll build an interface in php4;

Why would I use an interface? :)

 or address the problem outlined in the code igniter comment.

What's the problem that's outlined? I'm too lazy to go and look :|

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:

 Why would I use an interface? :)


because inheritance is not always optimal.

What's the problem that's outlined? I'm too lazy to go and look :|


/**
 * CI_BASE - For PHP 4
 *
 * This file is used only when CodeIgniter is being run under PHP 4.
 *
 * In order to allow CI to work under PHP 4 we had to make the Loader class
 * the parent of the Controller Base class.  It's the only way we can
 * enable functions like $this-load-library('email') to instantiate
 * classes that can then be used within controllers as $this-email-send()
 *
 * PHP 4 also has trouble referencing the CI super object within application
 * constructors since objects do not exist until the class is fully
 * instantiated.  Basically PHP 4 sucks...
 *
 * Since PHP 5 doesn't suffer from this problem so we load one of
 * two files based on the version of PHP being run.
 *
 * @packageCodeIgniter
 * @subpackagecodeigniter
 * @categoryfront-controller
 * @authorRick Ellis
 * @linkhttp://www.codeigniter.com/user_guide/
 */

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Tue, 2007-10-09 at 12:40 -0400, Andrew Ballard wrote:
 On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:
  $sucker = new TryToViolateEncapsulation();
  $sucker = (array)$sucker;
 
  $keys = array_keys( $sucker );
  $sucker[reset( $keys )] = 500;
 
  $sucker = serialize( (object)$sucker );
  $sucker = 'O:25:TryToViolateEncapsulation'.substr( $sucker, 14 );
  $sucker = unserialize( $sucker );
 
  print_r( $sucker );
 
  :::
 
  Maybe next time you'll have a challenge for me ;) And don't whine about
  how I achieved what I did.
 
 
 That's a bit disturbing. Ok, while we're bending things a bit, I'll
 make it a *little* tougher. :-)
 
 class TryToViolateEncapsulation {
 private $someInt = 0;
 
 const MAX_INT = 100;
 const MIN_INT = 0;
 
 public function getSomeInt() {
return $this-someInt;
 }
 
 public function setSomeInt($someInt) {
 $success = false;  // assume failure
 $someInt = (int) $someInt;
 if($this-isValid($someInt)) {
   $this-someInt = $someInt;
   $success = true;
 } else {
   throw new InvalidArgumentException('Invalid value passed to
 setSomeInt');
 }
 
 return $success;
 }
 
 private function isValid($someInt) {
$isValid = true;
if($someInt  TryToViolateEncapsulation::MIN_INT  || $someInt 
 TryToViolateEncapsulation::MAX_INT) {
   $isValid = false;
}
return $isValid;
}
 
public function __wakeup() {
   $this-setSomeInt($this-someInt);
}
 }

class Tricky extends TryToViolateEncapsulation
{
function __wakeup()
{
}

function bleh( TryToViolateEncapsulation $obj )
{
echo 'Gotta love it!!'.\n; 
}
}
 
function objectCast( $object, $class )
{
$newObject =
'O:'.strlen( $class ).':'.$class.''
   .substr( serialize( (object)(array)$object ), 14 );

$newObject = unserialize( $newObject );

$object = $newObject;
}
 
function arraySetPrivateField( $objectArray, $className, $fieldName, $value )
{
$objectArray[\x00$className\x00$fieldName] = $value;
}
 
 
$sucker = new TryToViolateEncapsulation();
$sucker = (array)$sucker;

arraySetPrivateField( $sucker, 'TryToViolateEncapsulation', 'someInt', 300 );
objectCast( $sucker, 'Tricky' );


print_r( $sucker );
$sucker-bleh( $sucker );



Certainly you'll notice I've extended the original class,
overriden the __wakeup() call and basically used inheritance
and polymorphism to my advantage. The object is now of a
different class but will serve in all contexts that one
expects the parent class unless an explicit class type check
is made. I think it's sufficient though since I've still
modified the private member variable of the parent ;)

 Of course, my gripe with __wakeup is that it is essentially a PHP
 implementation function that, IMO, should be private. However, it must
 be declared public for it to work, and that means that anyone outside
 the class can call it whenever they want.
 
 While I'm not totally sold on OOP for web pages, I still like PHP5
 because of the OO enhancements over PHP4. Can you code without them?
 Sure. I can cut my grass with a push mower, too -- but I tend to like
 my lawn tractor much better.
 
 However, thank you for demonstrating that I need to be MUCH more
 careful when building objects to validate member values each time they
 are used, and not just when they are set.

I would argue that this kind of tampering isn't worth checking for on
every unserialize.

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Tue, 2007-10-09 at 13:15 -0400, Nathan Nobbe wrote:
 On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:
 
  Why would I use an interface? :)
 
 
 because inheritance is not always optimal.
 
 What's the problem that's outlined? I'm too lazy to go and look :|
 
 
 /**
  * CI_BASE - For PHP 4
  *
  * This file is used only when CodeIgniter is being run under PHP 4.
  *
  * In order to allow CI to work under PHP 4 we had to make the Loader class
  * the parent of the Controller Base class.  It's the only way we can
  * enable functions like $this-load-library('email') to instantiate
  * classes that can then be used within controllers as $this-email-send()
  *
  * PHP 4 also has trouble referencing the CI super object within application
  * constructors since objects do not exist until the class is fully
  * instantiated.  Basically PHP 4 sucks...
  *
  * Since PHP 5 doesn't suffer from this problem so we load one of
  * two files based on the version of PHP being run.
  *
  * @packageCodeIgniter
  * @subpackagecodeigniter
  * @categoryfront-controller
  * @authorRick Ellis
  * @linkhttp://www.codeigniter.com/user_guide/
  */

Having read the comment it sounds like they have a solution in place.

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4


Nathan Nobbe [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:

 Why would I use an interface? :)

 because inheritance is not always optimal.

I have never found a prolem when using an interface was the only solution, 
or even ANY kind of solution. The fact that your designs need it speaks 
volumes of the problems with your designs.

 What's the problem that's outlined? I'm too lazy to go and look :|

 /**
 * CI_BASE - For PHP 4
 *
 * This file is used only when CodeIgniter is being run under PHP 4.
 *
 * In order to allow CI to work under PHP 4 we had to make the Loader class
 * the parent of the Controller Base class.  It's the only way we can
 * enable functions like $this-load-library('email') to instantiate
 * classes that can then be used within controllers as $this-email-send()
 *
 * PHP 4 also has trouble referencing the CI super object within 
 application
 * constructors since objects do not exist until the class is fully
 * instantiated.  Basically PHP 4 sucks...
 *
 * Since PHP 5 doesn't suffer from this problem so we load one of
 * two files based on the version of PHP being run.
 *
 * @packageCodeIgniter
 * @subpackagecodeigniter
 * @categoryfront-controller
 * @authorRick Ellis
 * @linkhttp://www.codeigniter.com/user_guide/
 */

 -nathan


There's your problem, then. You are wasting your time trying to implement 
fancy design patterns just because design patterns are supposed to be 
cool.  Loader class, Controller Base class, Front Controller - I have none 
of that crap in my code, so I don't encounter the problems you have. When I 
see code like $this-load-library('email')  I just thank my lucky stars 
that I don't have to maintain it. I think some serious refactoring is long 
overdue.

Perhaps you are trying to implement something from another language and 
expecting PHP to be just like that other language, which is always a stupid 
mistake. PHP is different, therefore the solution will be different. I 
suggest you learn how PHP works and design accordingly, and stop trying to 
force it into emulating another language.

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

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:

Nathan Nobbe [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:

Why would I use an interface? :)

because inheritance is not always optimal.

I have never found a prolem when using an interface was the only solution,
or even ANY kind of solution. The fact that your designs need it speaks
volumes of the problems with your designs.

im not the one whose been defending my designs in this conversation; you
are.
there are plenty of situations where the interface is the more elegant
approach,
thats why its here; and thats why it was added in php5.

There's your problem, then. You are wasting your time trying to implement
fancy design patterns just because design patterns are supposed to be
cool.

i dont recall reading any suggestions to use design patterns because they
are cool.
infact the advice ive read is to only use them when they make sense.

Loader class, Controller Base class, Front Controller - I have none
of that crap in my code, so I don't encounter the problems you have. When
I
see code like $this-load-library('email') I just thank my lucky stars
that I don't have to maintain it. I think some serious refactoring is long
overdue.

id have to say code igniter is quite a bit more popular than radicore.
maybe youre the one who has some refactoring to do.

Perhaps you are trying to implement something from another language and
expecting PHP to be just like that other language, which is always a
stupid
mistake. PHP is different, therefore the solution will be different. I
suggest you learn how PHP works and design accordingly, and stop trying to
force it into emulating another language.

well php has certainly gotten its influence from a number of other
languages.
where do you think the additional features in php5 got their inspiration
from?

btw;
heres the definition of implement from dictionary.com

im·ple·ment
https://secure.reference.com/premium/login.html?rd=2u=http%3A%2F%2Fdictionary.reference.com%2Fbrowse%2Fimplementation
/n. ˈɪmpləmənt; v. ˈɪmpləˌmɛnt, -mənt/ Pronunciation Key - Show Spelled
Pronunciation[n. *im*-pl*uh*-m*uh*nt; v. *im*-pl*uh*-ment, -m*uh*nt]
Pronunciation
Key - Show IPA Pronunciation –noun 1.any article used in some activity, esp.
an instrument, tool, or utensil: agricultural implements.
notice the use of article; ie data; ie; you are wrong about member variables
not being part of a classes implementation.
if a variable local to a function can be considered part of its
implementation; then a variable local to a class can be
considered part of its implementation; its that simple.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

2007-10-09 Thread Andrew Ballard

On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:
 Certainly you'll notice I've extended the original class,
 overriden the __wakeup() call and basically used inheritance
 and polymorphism to my advantage.

Noticed. :-) I said a *little* more difficult. Of course, I could
declare the class final, but then that ends any chance at inheritance.

 I would argue that this kind of tampering isn't worth checking for on
 every unserialize.

I haven't done much with PHP objects (other than built-in objects),
and can't recall a case where I've used serialize/unserialize for
anything other than to inspect variables before functions like
var_dump during development. In that case, your example concerns me
more with what other developers might try to do to circumvent
protections built into an object. It's a good argument for not storing
objects in anything persistent, like session variables, though, since
those are serialized/unserialized on every page and often stored in
the physical file system.

Honestly, it all seems a bit extreme. At some point, you have to trust
the people you work with not to go to such lengths to violate an
objects contract -- which I guess goes back to Tony's point whether
the language enforces private members/functions or whether they are
simply regarded that way by the developers using them. I would prefer
both, honestly. :)


Andrew

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/9/07, Andrew Ballard [EMAIL PROTECTED] wrote:

 Honestly, it all seems a bit extreme. At some point, you have to trust
 the people you work with not to go to such lengths to violate an
 objects contract -- which I guess goes back to Tony's point whether
 the language enforces private members/functions or whether they are
 simply regarded that way by the developers using them. I would prefer
 both, honestly. :)



indeed.

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Tue, 2007-10-09 at 14:11 -0400, Andrew Ballard wrote:
 On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:
  Certainly you'll notice I've extended the original class,
  overriden the __wakeup() call and basically used inheritance
  and polymorphism to my advantage.
 
 Noticed. :-) I said a *little* more difficult. Of course, I could
 declare the class final, but then that ends any chance at inheritance.
 
  I would argue that this kind of tampering isn't worth checking for on
  every unserialize.
 
 I haven't done much with PHP objects (other than built-in objects),
 and can't recall a case where I've used serialize/unserialize for
 anything other than to inspect variables before functions like
 var_dump during development. In that case, your example concerns me
 more with what other developers might try to do to circumvent
 protections built into an object. It's a good argument for not storing
 objects in anything persistent, like session variables, though, since
 those are serialized/unserialized on every page and often stored in
 the physical file system.
 
 Honestly, it all seems a bit extreme. At some point, you have to trust
 the people you work with not to go to such lengths to violate an
 objects contract -- which I guess goes back to Tony's point whether
 the language enforces private members/functions or whether they are
 simply regarded that way by the developers using them. I would prefer
 both, honestly. :)

If you're really worried about tampering of serialized data, store the
SHA1 code for the serialized data and validate before unserializing.

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On Tue, 2007-10-09 at 16:18 -0400, Robert Cummings wrote:
 On Tue, 2007-10-09 at 14:11 -0400, Andrew Ballard wrote:
  On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:
   Certainly you'll notice I've extended the original class,
   overriden the __wakeup() call and basically used inheritance
   and polymorphism to my advantage.
  
  Noticed. :-) I said a *little* more difficult. Of course, I could
  declare the class final, but then that ends any chance at inheritance.
  
   I would argue that this kind of tampering isn't worth checking for on
   every unserialize.
  
  I haven't done much with PHP objects (other than built-in objects),
  and can't recall a case where I've used serialize/unserialize for
  anything other than to inspect variables before functions like
  var_dump during development. In that case, your example concerns me
  more with what other developers might try to do to circumvent
  protections built into an object. It's a good argument for not storing
  objects in anything persistent, like session variables, though, since
  those are serialized/unserialized on every page and often stored in
  the physical file system.
  
  Honestly, it all seems a bit extreme. At some point, you have to trust
  the people you work with not to go to such lengths to violate an
  objects contract -- which I guess goes back to Tony's point whether
  the language enforces private members/functions or whether they are
  simply regarded that way by the developers using them. I would prefer
  both, honestly. :)
 
 If you're really worried about tampering of serialized data, store the
 SHA1 code for the serialized data and validate before unserializing.

In retrospect that doesn't really help if someone has access to both :)

Cheers,
Rob.
-- 
...
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:

 There's your problem, then. You are wasting your time trying to implement
 fancy design patterns just because design patterns are supposed to be
 cool.  Loader class, Controller Base class, Front Controller - I have
 none
 of that crap in my code, so I don't encounter the problems you have.


your site talks about the use of mvc in radicore so we can assume youre
using
at least one design pattern; and if radicore has a single point of entry you
are
using a front controller.

might want to knock the dust off the old design pattern books just to jog
your memory:)

-nathan

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

Nathan Nobbe [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On 10/9/07, Tony Marston [EMAIL PROTECTED] wrote:

Nathan Nobbe [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On 10/9/07, Robert Cummings [EMAIL PROTECTED] wrote:

Why would I use an interface? :)

because inheritance is not always optimal.

I have never found a prolem when using an interface was the only
solution,
or even ANY kind of solution. The fact that your designs need it speaks
volumes of the problems with your designs.

im not the one whose been defending my designs in this conversation; you
are.

But you are the one who keeps saying that your approach, where all member
variables are hidden, is far superior. I'm just saying that I do share that
opinion.

there are plenty of situations where the interface is the more elegant
approach, thats why its here; and thats why it was added in php5.

There's your problem, then. You are wasting your time trying to implement
fancy design patterns just because design patterns are supposed to be
cool.

i dont recall reading any suggestions to use design patterns because they
are cool.

But you are the one who pointed out that interfaces are used in design
patterns, therefore they *must* be OK. I am saying that I have never seen
any advantages from using interfaces, and I don't waste my time with design
patterns.

infact the advice ive read is to only use them when they make sense.

My point is that interfaces do not make anysense to me at all. I can access
all my class methods without them, so what benefit do they give?

Loader class, Controller Base class, Front Controller - I have none
of that crap in my code, so I don't encounter the problems you have. When
I
see code like $this-load-library('email') I just thank my lucky
stars
that I don't have to maintain it. I think some serious refactoring is
long
overdue.

id have to say code igniter is quite a bit more popular than radicore.
maybe youre the one who has some refactoring to do.

well php has certainly gotten its influence from a number of other
languages.
where do you think the additional features in php5 got their inspiration
from?

Some of those features were implemented just because some a*sholes who are
more familiar with other languages keep saying I can do so-and-so in
language X, and I want to do exactly the same thing in PHP. Language X has
interfaces, so PHP *must* have interfaces, Why? What purpose do they serve?
What benefits do they bring?

btw;
heres the definition of implement from dictionary.com

im·ple·ment
https://secure.reference.com/premium/login.html?rd=2u=http%3A%2F%2Fdictionary.reference.com%2Fbrowse%2Fimplementation
/n. '?mpl?m?nt; v. '?mpl??m?nt, -m?nt/ Pronunciation Key - Show Spelled
Pronunciation[n. *im*-pl*uh*-m*uh*nt; v. *im*-pl*uh*-ment, -m*uh*nt]
Pronunciation
Key - Show IPA Pronunciation -noun 1.any article used in some activity,
esp.
an instrument, tool, or utensil: agricultural implements.
notice the use of article; ie data; ie; you are wrong about member
variables
not being part of a classes implementation.
if a variable local to a function can be considered part of its
implementation; then a variable local to a class can be
considered part of its implementation; its that simple.

Implementation is still an activity or a procedure. A lawnmower is a tool
which implements lawnmowing, and it acts upon a lawn. However, the lawn is
not part of the implementation, it is the subject of the implementation. An
object may contain both variables and operations, but the data is not part
of those operations, it is the subject of those operations.

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

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Beginner Tutorials for using CLASSES in PHP4