Classes vs functions

[vrillusions]

I've been using functions since I first started using php, but I've been
hearing more and more about classes, which I never really looked at that
much. I understand the whole OO programming aspect, but are there any
advantages to having classes as opposed to just functions? I've heard that
the classes are better because they only load the functions they need to,
where with an include file of functions, the whole page gets loaded, even
if you only use a couple functions on a certain page. I've searched around
and can't find any "official" mention of this though. So, is that true and
should I start migrating to using classes instead of functions?

--
VR

[André Næss]

Re: Classes vs functions

vrillusions:
[color=blue]
> I've been using functions since I first started using php, but I've been
> hearing more and more about classes, which I never really looked at that
> much. I understand the whole OO programming aspect, but are there any
> advantages to having classes as opposed to just functions? I've heard
> that the classes are better because they only load the functions they need
> to, where with an include file of functions, the whole page gets loaded,
> even
> if you only use a couple functions on a certain page. I've searched
> around
> and can't find any "official" mention of this though. So, is that true
> and should I start migrating to using classes instead of functions?[/color]

No. That sounds rather confused to me. PHP obviously isn't omniscient and
thus has to parse all the source files it reads in.

André Næss

[Tim Van Wassenhove]

Re: Classes vs functions

On 2003-12-11, vrillusions <vrillusions@no t_this.neo.rr.c om.invalid> wrote:[color=blue]
> I've been using functions since I first started using php, but I've been
> hearing more and more about classes, which I never really looked at that
> much. I understand the whole OO programming aspect, but are there any
> advantages to having classes as opposed to just functions?[/color]


If you do understand OOP, you should see the _possible_ advantages if used
right... (But if you see them, why did you choose for PHP anyway?
Doesn't J2EE seem more appropriate?)
[color=blue]
> I've heard that
> the classes are better because they only load the functions they need to,
> where with an include file of functions, the whole page gets loaded, even
> if you only use a couple functions on a certain page. I've searched around
> and can't find any "official" mention of this though. So, is that true and
> should I start migrating to using classes instead of functions?[/color]

One could make a really big class with all functions in it. This would
be as dumb as not making groups of functions, in separate files.

--
verum ipsum factum

[Bruno Desthuilliers]

Re: Classes vs functions

vrillusions wrote:[color=blue]
> I've been using functions since I first started using php, but I've been
> hearing more and more about classes, which I never really looked at that
> much. I understand the whole OO programming aspect, but are there any
> advantages to having classes as opposed to just functions?[/color]

I think so... But in PHP, you can probably do the same thing without OO.

What I personnaly like w/ OO (in general) is that it allows to have
different substitutable implementations of a same concept, with a
uniform representation.

Note that you clearly don't need classes to have ADTs in PHP, but this
won't give you polymorphism (or not as easily). Now whether you need
this or not depends on your application and coding style. Having mostly
used (more or less) OO languages since I began programming, I'm may be a
bit biased !-)

Another point that is more PHP-specific is that PHP not having any
module concept, classes can also be used to emulate modules, thus
uncluttering the global namespace.
[color=blue]
> I've heard that
> the classes are better because they only load the functions they need to,
> where with an include file of functions, the whole page gets loaded, even
> if you only use a couple functions on a certain page. I've searched around
> and can't find any "official" mention of this though. So, is that true[/color]

I've never heard of such a thing, and really doubt it's even possible in
PHP.
[color=blue]
> and
> should I start migrating to using classes instead of functions?[/color]

That's another problem, and this one is up to you... But you probably
shouldn't care if you don't have a need for it.

My 2 <euro>cents,
Bruno

[Henk Verhoeven]

Re: Classes vs functions

>(But if you see them, why did you choose for PHP anyway?[color=blue]
>Doesn't J2EE seem more appropriate?)[/color]

Certainly not! Java's strong typing in combination with it's primitive
datatypes is a pain in the ass. So is it's obligation to either handle
exceptions or declare to be throwing them. It is allso a matter of
mentality: Java's developers tend to make everything unnecessary
complicated. For example this absurd idea of EJB (Enterprise Java Beans, a
part of J2EE) that everything is distributed. This means that looping
through a thousend objects and retrieving a value form each will require a
thousend remote method invocations (these are at least a hundred times
slower then local method calls, but if these objects happen to reside on the
other end of the world each method call takes half a second or more). (in
the end they had te reintroduce
local objects kind of through a back door).

The more generic (= reusable) your code gets, the more you
run into the inflexibilities and bad designs of Java. I'm not alone here,
look at the Lightwieght Languages workshop (http://ll1.ai.mit.edu/) and its
discussion archive
(http://www.ai.mit.edu/~gregs/ll1-dis...l/threads.html - takes
a few minutes to download)

But let's talk about the advantages of OO. It comes down to:
- delegation + polymorphism
- encapsulation
- inheritance

Delegation means that you want something done but you do not do it yourself
but have an object do it for you. This is done by using a service, wich is
dispatched tp a function on an object. Now what is the difference between
calling a normal function and using a service? Polymorphism! The class of
which the object is intstantiated is decisive for which function is actually
executed. For example if i am building an ecommerce website i could have a
class "DeliveryServic e" with a subclass "ExpessDelivery " and another
subclass "Standard Delivery". Somehwere in the order intake i ask the
customer to select a delivery service. On the basis of his selection i
instantiate the corresponding class and tell the object te delivery adress.
Then i can ask the object for the dilivery price and maybe how long the
delivery will take. If the object is an instance of ExpessDelivery it will
ececute the functions of ExpessDelivery to calculate the price, which will
probably be higher then for a StandardDeliver y.

So far you could reach the same result with some case swithches in normal
functions. But here comes the trick: When the owner of the ecommerce website
asks me to add another delivery service, let's say "Collect On Delivery",
where his customer can pay on delivery to the guy that delivers the order, i
can simply add another class CollectOnDelive ry and implement it's functions.
With case swithches i would have to add a case to each case switch. In order
to do that i would first have to find all these case switches hidden in
whatever function where i have (or worse, someone else has) once written
them. This makes well-designed OO software more flexible and easier to
maintain.

You can see it like this: in OOP we put our functions into a large
multilayered
case switch, called the class hierarchy, while in conventional
programming you have to replicate many case switches throughout you code.
So, if you have little case switches (including if-elseif-etc) you will
probably not
need OOP. If your case switches are becoming a headache you should obviously
have used OO right from the start.

OK, this is more then enough, i suggest someone else explains encapsualtion
and
inheritance and their advantages.

Greetings,

Henk Verhoeven,

https://www.metaclass.nl

[Phil Roberts]

Re: Classes vs functions

With total disregard for any kind of safety measures vrillusions
<vrillusions@no t_this.neo.rr.c om.invalid> leapt forth and uttered:
[color=blue]
> I've been using functions since I first started using php, but
> I've been hearing more and more about classes, which I never
> really looked at that much. I understand the whole OO
> programming aspect, but are there any advantages to having
> classes as opposed to just functions? I've heard that the
> classes are better because they only load the functions they
> need to, where with an include file of functions, the whole page
> gets loaded, even if you only use a couple functions on a
> certain page. I've searched around and can't find any
> "official" mention of this though. So, is that true and should
> I start migrating to using classes instead of functions?
>[/color]

I usually point people towards this post at Sitepoint whenever
this question is raised: http://sitepointforums.com/showpost....8&postcount=14

Happy reading. :-)

--
There is no signature.....

[Tim Van Wassenhove]

Re: Classes vs functions

On 2003-12-11, Henk Verhoeven <news@metaclass REMOVE-THIS.nl> wrote:[color=blue][color=green]
>>(But if you see them, why did you choose for PHP anyway?
>>Doesn't J2EE seem more appropriate?)[/color][/color]

[long snipped on advantages of OOP]

I agree that OOP has it's advantages...

But my point was: If the OP really wanted to make use of these advantages,
why did he choose for PHP in the first place? (Assuming his project is
is not using OOP, as PHP never had really support for OOP).

--
verum ipsum factum

[Bruno Desthuilliers]

Re: [TROLL] Classes vs functions

Tim Van Wassenhove wrote:[color=blue]
> On 2003-12-11, Henk Verhoeven <news@metaclass REMOVE-THIS.nl> wrote:
>[color=green][color=darkred]
>>>(But if you see them, why did you choose for PHP anyway?
>>>Doesn't J2EE seem more appropriate?)[/color][/color]
>
>
> [long snipped on advantages of OOP]
>
> I agree that OOP has it's advantages...
>
> But my point was: If the OP really wanted to make use of these advantages,
> why did he choose for PHP in the first place?[/color]

<troll>
Because Java sucks ?
</troll>
[color=blue]
>(Assuming his project is
> is not using OOP, as PHP never had really support for OOP).
>[/color]

Too big. Won't work.

[Henk Verhoeven]

Re: Classes vs functions

Tim,
[color=blue]
> PHP never had really support for OOP[/color]

How do you mean? What OOP support do you miss in, let's say php4 ?

Greetings,

Henk Verhoeven.

[Tim Van Wassenhove]

Re: Classes vs functions

On 2003-12-12, Henk Verhoeven <news@metaclass REMOVE-THIS.nl> wrote:[color=blue]
> Tim,
>[color=green]
>> PHP never had really support for OOP[/color]
>
> How do you mean? What OOP support do you miss in, let's say php4 ?[/color]

A way to "hide" data in a class, never found a way to declare a
variable/method as private.

--
verum ipsum factum

[Phil Roberts]

Re: Classes vs functions

With total disregard for any kind of safety measures Tim Van
Wassenhove <euki@pi.be> leapt forth and uttered:
[color=blue]
> On 2003-12-12, Henk Verhoeven <news@metaclass REMOVE-THIS.nl>
> wrote:[color=green]
>> Tim,
>>[color=darkred]
>>> PHP never had really support for OOP[/color]
>>
>> How do you mean? What OOP support do you miss in, let's say
>> php4 ?[/color]
>
> A way to "hide" data in a class, never found a way to declare a
> variable/method as private.
>[/color]

How has this inability ever prevented an application from working?

I describe an important lack as something that actively stands in
the way of an application being developed. Hardly the case with
private/protected methods...

--
There is no signature.....

[Jochen Buennagel]

Re: Classes vs functions

Tim Van Wassenhove wrote:[color=blue]
> A way to "hide" data in a class, never found a way to declare a
> variable/method as private.[/color]

Prepend an underscore before the variable/method name and use some
discipline and common sense to treat that as private. Worked for me
every time...

Jochen

[Zurab Davitiani]

Re: Classes vs functions

Phil Roberts wrote on Friday 12 December 2003 16:02:
[color=blue][color=green][color=darkred]
>>> How do you mean? What OOP support do you miss in, let's say
>>> php4 ?[/color]
>>
>> A way to "hide" data in a class, never found a way to declare a
>> variable/method as private.
>>[/color]
>
> How has this inability ever prevented an application from working?
>
> I describe an important lack as something that actively stands in
> the way of an application being developed. Hardly the case with
> private/protected methods...[/color]

That's easy for PHP4. I can list some off the top of my head:

- interfaces and/or multiple inheritance;
- packages;
- ability to destroy objects (and free associated memory);
- abstract classes.

I'm sure there are few others as well. PHP5 takes care of good deal of this
type of OO functionality but you asked about PHP4 ;)

--
Business Web Solutions
ActiveLink, LLC

https://www.active-link.com/intranet/

[Henk Verhoeven]

Re: Classes vs functions

Phil,

I agree with Tim that there is more to building applications then getting
them to work. For example modularization does make large applications easier
to maintain, and is even more important when you use third party components.
But i do not like his solution: private fields & functions (assuming he uses
it in the C++/Java meaning) because:
- a class is too small as a module. It is good desing to make objects
cooprerate closely. It is logical to see those objects together as a module,
and it may help maintenance to declare some parts of the module as only to
be called from inside the module.
- the polymorphism often requires that methods are overridden in subclasses.
If the field or method called by the overridden method are private it can be
hard or impossible to build the overriding method. So if i where to choose
between having "private" or "protected" added to php, i would certainly
choose "protected" .
- persistency frameworks need access to fields. If they are private or
protected there must be a workaround, otherwise, like in java, one will have
to make all persistent fields public. The only language i know of that has
such a workaround is Smalltalk, where all fields are protected.

Smalltalk has an interesting concept of private methods: Nothing stops you
from calling them, but with the default settings of the IDE they are
invisible unless you explicitely choose to see them. Becuase the
"privitenes s" of methods is not enforced, one can give "private" one's own
meaning. In the Smalltalk class library however, it means that such a method
is not part of the api, so if you call it you do so on your own risk: no
effort is made that the same method will be present in next release.
Effectively this kind of private is very large scale: the entire Smalltalk
class library is one method and "private" defines what should not be used
from outside the module.

In fact there is little that stops one from defining one's own meaning of
"private" and put comments accordingly ito his code, but i must admit, this
will not be half as effective without a development environment that
supports it.

Greetings,

Henk Verhoeven,

https://www.metaclass.nl

"Phil Roberts" <philrob@HOLYfl atnetSHIT.net> wrote in message
news:Xns9450716 A386philroberts @206.127.4.22.. .[color=blue]
> With total disregard for any kind of safety measures Tim Van
> Wassenhove <euki@pi.be> leapt forth and uttered:
>[color=green]
> > On 2003-12-12, Henk Verhoeven <news@metaclass REMOVE-THIS.nl>
> > wrote:[color=darkred]
> >> Tim,
> >>
> >>> PHP never had really support for OOP
> >>
> >> How do you mean? What OOP support do you miss in, let's say
> >> php4 ?[/color]
> >
> > A way to "hide" data in a class, never found a way to declare a
> > variable/method as private.
> >[/color]
>
> How has this inability ever prevented an application from working?
>
> I describe an important lack as something that actively stands in
> the way of an application being developed. Hardly the case with
> private/protected methods...
>
> --
> There is no signature.....[/color]

[Henk Verhoeven]

Re: Classes vs functions

> - interfaces
How would a "real" interface differ from a class that is clearly
recognizable as an interface and a comment in every class that "implements "
the interface that it does so? IOW, what's an interface without strong
typing?

What i missed in Java was the ability to use a class as an interface. I
mean: the ability to declare that my class implements all public methods
defined by an other class. There is no reason why that would not run so i
think the compiler should compile it.
[color=blue]
> and/or multiple inheritance;[/color]
Would'nt multiple inheritance be a little over the top for "the basic of the
internet"?
[color=blue]
> - packages;[/color]
It is already possible (and advisable) to put classes together into a
package-like directory. I agree it would be nice (but more
resource-consuming) to be able to include an entire package. But is is
entirely possible to write a function that does so. For some reason i never
needed it enough to write it...

Most interesting is the namespaceing effect of packages in Java, making
abbreviated class names unique outside their package if they are unique
inside. If you follow PEAR's class name convention you have the same effect,
but miss the ability to 'leave out" the package name if you have imported
the package. The result is a lot of extra typing and harder to read code.
Personally i prefer to have the same prefix for all classes of the same app,
and one other prefix for all classes of our reusable framework.
[color=blue]
> - ability to destroy objects (and free associated memory);[/color]
Interesting, did you ever run into memory limitations within a single http
request? I would rather like to have a way NOT to have objects destroyed at
the end of a http request (i do not count serialization in the session as
very usefull in this respect). But i admit that this would cause all kinds
of multi-user-multi-threading problems if you do not adhere quite strictly
to a thread safe programming style, so it would make programming php so much
more complex that most apps should not use it.
[color=blue]
> - abstract classes.[/color]
What's wrong with an @abstract comment? Why would anyone want to instantiate
an abstract class if it is clearly incomplete? And why NOT instantiate an
"abstract" class if it's clearly complete for the function it going to be is
used for?
[color=blue]
>
> I'm sure there are few others as well. PHP5 takes care of good deal of[/color]
this[color=blue]
> type of OO functionality but you asked about PHP4 ;)[/color]

Does php 5 add all this? I did not notice (my fault). I like php 4 very much
because of it's simplicity (remember the eXtreme Programming motto: the
simpelest thing that could possibly work?). But php4 has very irritating
limitations for OOP, which surpisingly no-one here mentioned:
- the habit op php4 to recursively copy anything that is not passed by
reference. This got even worse when passing by reference by the caller
started to cause warnings. It renders functions like array_slice virtually
useless with (potentially) large arrays of objects
- references to variables instead of references to objects. (It took me a
while to find the workaround: create a temporary variable in a function, put
an object into it, then have the funcion return a refernce to the temporary
variable. As no one else can have a reference to the temporary variable
unless you pass them one, it pritty much behaves like a referene to the
object itself).
- no stack trace and no try-catch for exception handling. If you heavily
reuse code and that code triggers an error you end up with a useless line
nuber of the trigger_error in the generic code, left guessing which one of
the many places from which the reused code was called caused the error.
All of these are solved by PHP5. I really look forward to it, but as we use
low cost hosting providers (one still runs php4.1) it may take a while
before it becomes mainstream...

Greetings,

Henk Verhoeven,
www.metaclass.nl.

"Zurab Davitiani" <agt@mindless.c om> wrote in message
news:JHBCb.7084 5$Ht1.23564@new ssvr25.news.pro digy.com...[color=blue]
> Phil Roberts wrote on Friday 12 December 2003 16:02:
>[color=green][color=darkred]
> >>> How do you mean? What OOP support do you miss in, let's say
> >>> php4 ?
> >>
> >> A way to "hide" data in a class, never found a way to declare a
> >> variable/method as private.
> >>[/color]
> >
> > How has this inability ever prevented an application from working?
> >
> > I describe an important lack as something that actively stands in
> > the way of an application being developed. Hardly the case with
> > private/protected methods...[/color]
>
> That's easy for PHP4. I can list some off the top of my head:
>
> - interfaces and/or multiple inheritance;
> - packages;
> - ability to destroy objects (and free associated memory);
> - abstract classes.
>
> I'm sure there are few others as well. PHP5 takes care of good deal of[/color]
this[color=blue]
> type of OO functionality but you asked about PHP4 ;)
>
> --
> Business Web Solutions
> ActiveLink, LLC
> www.active-link.com/intranet/[/color]