Several months ago I started a thread with the title "What is/is not
considered to be good OO programming" which started a long and
interesting discussion.
I have condensed the arguments into a single article which can be
viewed at http://www.tonymarston.net/php-mysql/good-bad-oop.html
I fully expect this to be the start of another flame war, so sharpen
your knives and get stuck in!
Tony (you do it your way and I'll do it better) Marston http://www.tonymarston.net/ 52  6354 
Tony Marston wrote: Several months ago I started a thread with the title "What is/is not
considered to be good OO programming" which started a long and
interesting discussion.
I have condensed the arguments into a single article which can be
viewed at
http://www.tonymarston.net/php-mysql/good-bad-oop.html
I fully expect this to be the start of another flame war, so sharpen
your knives and get stuck in!
Tony (you do it your way and I'll do it better) Marston
http://www.tonymarston.net/
Hey that's a really well written (or put together) document. I'll be
saving that for good use.
Tony Marston: Several months ago I started a thread with the title "What is/is not
considered to be good OO programming" which started a long and
interesting discussion.
I have condensed the arguments into a single article which can be
viewed at
http://www.tonymarston.net/php-mysql/good-bad-oop.html
I fully expect this to be the start of another flame war, so sharpen
your knives and get stuck in!
Tony (you do it your way and I'll do it better) Marston
http://www.tonymarston.net/
I just think it's funny that you still don't understand object composition.
In your article you write: "How do you share code in OO systems? Through
inheritance.", not even mentioning object composition. Object composition
was also the crux of my argument, i.e.: where you see only inheritance, I
see inheritance and composition. From this we can only deduce that you in
fact did not properly understand my argument. That doesn't make the
discussion any easier.
But then again, most beginners in OOP face this particular problem, they
overuse inheritance because that's usually the first thing they learn, and
once they get the hang of it, they won't let go.
André nęss
André Nęss wrote: Tony Marston:
I have condensed the arguments into a single article which can be
viewed at
http://www.tonymarston.net/php-mysql/good-bad-oop.html
I just think it's funny that you still don't understand object
composition. In your article you write: "How do you share code in OO
systems? Through inheritance.", not even mentioning object
composition. Object composition was also the crux of my argument,
i.e.: where you see only inheritance, I see inheritance and
composition. From this we can only deduce that you in fact did not
properly understand my argument. That doesn't make the discussion any
easier.
I was thinking the same. I saw the article, looked for "composition",
couldn't find it, and went away.
--
Google Blogoscoped http://blog.outer-court.com
André Nęss <an*********************@ifi.uio.no> wrote in message news:<bq**********@maud.ifi.uio.no>... Tony Marston:
Several months ago I started a thread with the title "What is/is not
considered to be good OO programming" which started a long and
interesting discussion.
I have condensed the arguments into a single article which can be
viewed at
http://www.tonymarston.net/php-mysql/good-bad-oop.html
I fully expect this to be the start of another flame war, so sharpen
your knives and get stuck in!
Tony (you do it your way and I'll do it better) Marston
http://www.tonymarston.net/
I just think it's funny that you still don't understand object composition.
In your article you write: "How do you share code in OO systems? Through
inheritance.", not even mentioning object composition.
Because I have looked at definitions and examples of object
composition and deduced that it would serve no useful purpose in my
infrastructure.
To quote one reference: http://www.eagle-software.com/object.htm
"Object composition allows you to group components together, creating
a new component."
I do not see where I can use this technique, or what advantage it
would bring, therefore I am not going to waste any time on it.
To quote another reference:
http://brighton.ncsa.uiuc.edu/~prajlich/T/node14.html
"The disadvantage of object composition is that the behavior of the
system may be harder to understand just by looking at the source code.
A system using object composition may be very dynamic in nature so it
may require running the system to get a deeper understanding of how
the different objects cooperate."
As I do not like writing complicated software that is difficult to
understand this whole idea sounds like a no-no to me. I prefer to
follow the KISS principle.
From the same article:
"Most designers overuse inheritance, resulting in large inheritance
hierarchies that can become hard to deal with."
If you look at my code you will see that I do not have a large
inheritance hierarchy. I have just one superclass and one layer of
subclass, therefore you cannot say that I am overusing inheritance.
Object composition
was also the crux of my argument, i.e.: where you see only inheritance, I
see inheritance and composition. From this we can only deduce that you in
fact did not properly understand my argument.
You argument is irrelevant as it serves no useful purpose when
discussing a single abstract class.
Tony Marston
http://www.tonymarston.net/
That doesn't make the discussion any easier. But then again, most beginners
in OOP face this particular problem, they overuse inheritance because that's
usually the first thing they learn, and once they get the hang of it, they
won't let go.
André nęss
"Philipp Lenssen" <in**@outer-court.com> wrote in message news:<bq*************@ID-203055.news.uni-berlin.de>... André Nęss wrote:
Tony Marston:
I have condensed the arguments into a single article which can be
viewed at
http://www.tonymarston.net/php-mysql/good-bad-oop.html
I just think it's funny that you still don't understand object
composition. In your article you write: "How do you share code in OO
systems? Through inheritance.", not even mentioning object
composition. Object composition was also the crux of my argument,
i.e.: where you see only inheritance, I see inheritance and
composition. From this we can only deduce that you in fact did not
properly understand my argument. That doesn't make the discussion any
easier.
I was thinking the same. I saw the article, looked for "composition",
couldn't find it, and went away.
Just for you I have added a section on object composition. I hope you like it. http://www.tonymarston.net/php-mysql...tml#2003-12-05
Kiss, kiss
Tony Marston http://www.tonymarston.net/
Tony Marston: Object composition
was also the crux of my argument, i.e.: where you see only inheritance, I
see inheritance and composition. From this we can only deduce that you in
fact did not properly understand my argument.
You argument is irrelevant as it serves no useful purpose when
discussing a single abstract class.
I wasn't discussing a single abstract class. I was discussing a solution to
a problem. The single abstract class and proliferation of new classes is
*your* solution. I tried to argue that a different, and IMO better approach
was possible. You didn't bother to learn about object composition until
*now*, yet you disagreed with my idea of using it in your case. In other
words, you had decided that your solution *is* the best even before you
started the discussion, despite the fact that you did not know much about
OO.
André Nęss
"Tony Marston" <to**@marston-home.demon.co.uk> wrote in message
news:75**************************@posting.google.c om... "Philipp Lenssen" <in**@outer-court.com> wrote in message
news:<bq*************@ID-203055.news.uni-berlin.de>... André Nęss wrote:
Tony Marston:
>
> I have condensed the arguments into a single article which can be
> viewed at
> http://www.tonymarston.net/php-mysql/good-bad-oop.html
>
I just think it's funny that you still don't understand object
composition. In your article you write: "How do you share code in OO
systems? Through inheritance.", not even mentioning object
composition. Object composition was also the crux of my argument,
i.e.: where you see only inheritance, I see inheritance and
composition. From this we can only deduce that you in fact did not
properly understand my argument. That doesn't make the discussion any
easier.
I was thinking the same. I saw the article, looked for "composition",
couldn't find it, and went away.
Just for you I have added a section on object composition. I hope you like
it.
http://www.tonymarston.net/php-mysql...tml#2003-12-05
Kiss, kiss
Tony Marston
http://www.tonymarston.net/
Tony,
A trifle defensive <grin>, but wholly correct. As another 25+ programmer, I
can state without too much fear of contradiction that the customer pays me
to solve his problem, not to write code which meets the approval of the
paradigm police.
More power to you, you rabid radical you!
Cheers,
Doug Hutcheson
Doug Hutcheson wrote: "Tony Marston" <to**@marston-home.demon.co.uk> wrote in message
news:75**************************@posting.google.c om...
<snip>
http://www.tonymarston.net/php-mysql...tml#2003-12-05
<snip>
Tony,
A trifle defensive <grin>, but wholly correct. As another 25+ programmer,
I can state without too much fear of contradiction that the customer pays
me to solve his problem, not to write code which meets the approval of the
paradigm police.
More power to you, you rabid radical you!
Cheers,
Doug Hutcheson
Wow, it's come back to life again!
Asbestos manufacturers everywhere must be looking forwards
to this one!
;p
Matt
Matty wrote: Wow, it's come back to life again!
Asbestos manufacturers everywhere must be looking forwards
to this one!
;p
Matt
FWIW, I still think it's better to have 12 different instances,
rather than 12 different classes <duck />... Not read it all yet,
just a quick search! I'll have a good read through tomorrow, but
I do think there aren't sufficient differences between tables in a
database to justify having a separate class to handle each table,
when a separate instance of a suitably generic class would handle it
OK.
I am definitely a TMTOWTDI kind of person, though, and I do agree
that fundamentally, if the software works, then it's good.
Matt
>> "Tony Marston" <to**@marston-home.demon.co.uk> wrote in message news:75**************************@posting.google.c om...
<snip>
http://www.tonymarston.net/php-mysql...tml#2003-12-05
(Yet Another Follow Up...)
Can't help wondering what the object composition argument was, and how
on earth you could do it in a logical manner.
A table "has a" page of records?
A page of records "has a" table (what would it do if it didn't?)
Personally, yeah, I think composition isn't the way to do it...
/me thinks How about a table "has a" table perhaps???
;p
Matt
André Nęss <an*********************@ifi.uio.no> wrote in message news:<bq**********@maud.ifi.uio.no>... Tony Marston:
Object composition
was also the crux of my argument, i.e.: where you see only inheritance, I
see inheritance and composition. From this we can only deduce that you in
fact did not properly understand my argument.
You argument is irrelevant as it serves no useful purpose when
discussing a single abstract class.
I wasn't discussing a single abstract class. I was discussing a solution to
a problem. The single abstract class and proliferation of new classes is
*your* solution. I tried to argue that a different, and IMO better approach
was possible.
It may seem better in your opinion, but to my mind it is different
without any obvious benefits, so there is no point in changing.
You didn't bother to learn about object composition until
*now*, yet you disagreed with my idea of using it in your case.
Object composition is not listed among the principles of OOP, so I
ignored it. When I did read about it the first thing that I saw was
that it was considered as an alternative method of dealing with
complex hierarchies. As I do not have a complex hierarchy (just two
levels) there seems no point in investigating it any further.
In other
words, you had decided that your solution *is* the best even before you
started the discussion,
I never said it was the best, I merely said that it is simple and it
works. As a follower of the KISS principle this is VERY important. Why
waste time on a complex solution if a simple one works?
despite the fact that you did not know much about OO.
André Nęss
It is true that I have not been taught any OO, but that means that I
have not been taught the wrong things. What I have read about OO tells
me that objects are not that much different to components, and as I
have been working with a component-based development language for the
last 10 years all I did was to take my component-based design and
convert it to object-based. Simple and effective.
The fact that I do not do OOP in the way that you do it is irrelevant.
I can achieve rapid results my way, so my way is good for me (and a
few others according to the emails I have received).
Tony Marston http://www.tonymarston.net/
Tony Marston wrote: "Philipp Lenssen" <in**@outer-court.com> wrote in message
news:<bq*************@ID-203055.news.uni-berlin.de>... André Nęss wrote:
I was thinking the same. I saw the article, looked for
"composition", couldn't find it, and went away.
Just for you I have added a section on object composition. I hope you
like it.
http://www.tonymarston.net/php-mysql...tml#2003-12-05
You should differentiate between "has a" and "is a". I believe I
recently posted this here and the idea is neither mine nor new.
Inheritance examples in books often go by the examples of employees.
And employee "is a type of" person. So it would not make sense to use
object composition. (Not if person and employee are intended to be the
same anyway.) Because an employee shares attributes of a person but
includes his own.
Now let's say I have a class "webpage". Now this "webpage" has a
complex module "binary_image" which will render images. You would use
simple object composition by creating a new instance of "binary_image"
within "webpage".
Why is it composited and not inherited?
Because the webpage "has a" binary image. However, it's wrong to say
binary_image "is a type of" webpage. 'Cause it's not.
This was just an example. Usually I don't use global instances of
objects either in a class. Usually they just go right into the
function. E.g. using the file-system object from within a class on a
Windows server. Or handling XML.
And object composition structures the code and can make it more
readable. It's often more natural. But whatever approach suits you.
Don't forget however that if you're working in a team you can't just
say "my approach is better 'cause I like it and everyone should code
the way they want", because code must be managed by others. You
wouldn't expect your code to be rewritting from scratch or highly
refactored if you were sick for a week and someone else had to go
through it. So you should write code in ways accepted and used in your
team, and to find the best solution you must argue beyond personal
taste. Sometimes, you may even need to compromise.
"Doug Hutcheson" <do*******************@nrm.qld.gov.au> wrote in message news:<B%******************@news.optus.net.au>... "Tony Marston" <to**@marston-home.demon.co.uk> wrote in message
news:75**************************@posting.google.c om... "Philipp Lenssen" <in**@outer-court.com> wrote in message
news:<bq*************@ID-203055.news.uni-berlin.de>... André Nęss wrote:
> Tony Marston:
> >
> > I have condensed the arguments into a single article which can be
> > viewed at
> > http://www.tonymarston.net/php-mysql/good-bad-oop.html
> >
> I just think it's funny that you still don't understand object
> composition. In your article you write: "How do you share code in OO
> systems? Through inheritance.", not even mentioning object
> composition. Object composition was also the crux of my argument,
> i.e.: where you see only inheritance, I see inheritance and
> composition. From this we can only deduce that you in fact did not
> properly understand my argument. That doesn't make the discussion any
> easier.
>
I was thinking the same. I saw the article, looked for "composition",
couldn't find it, and went away.
Just for you I have added a section on object composition. I hope you like
it.
http://www.tonymarston.net/php-mysql...tml#2003-12-05
Kiss, kiss
Tony Marston
http://www.tonymarston.net/
Tony,
A trifle defensive <grin>, but wholly correct. As another 25+ programmer, I
can state without too much fear of contradiction that the customer pays me
to solve his problem, not to write code which meets the approval of the
paradigm police.
More power to you, you rabid radical you!
Cheers,
Doug Hutcheson
People tend to describe me more as revolting than rebelling. Is there
a difference? :)
Tony Marston http://www.tonymarston.net/
Matty <ma*******@askmenoquestions.co.uk> wrote in message news:<cG********************@wards.force9.net>... Matty wrote:
Wow, it's come back to life again!
Asbestos manufacturers everywhere must be looking forwards
to this one!
;p
Matt
FWIW, I still think it's better to have 12 different instances,
rather than 12 different classes <duck />...
According to the principles of OO you are not supposed to instantiate
an abstract class then feed it the implementation details, you are
supposed to put the implementation details in a subclass. If I were to
use the keyword 'abstract' in the class definition (as PHP 5 will
allow) you will find it impossible to instantiate an abstract class
directly, in which case you MUST use a subclass.
So, if I have 12 database tables each with a totally different set of
implementation details, then (according to the above-mentioned
principle) I must create 12 subclasses. I am right and you are wrong,
so score 1-0 to me :)
Not read it all yet,
just a quick search! I'll have a good read through tomorrow, but
I do think there aren't sufficient differences between tables in a
database to justify having a separate class to handle each table,
when a separate instance of a suitably generic class would handle it
OK.
I am definitely a TMTOWTDI kind of person, though, and I do agree
that fundamentally, if the software works, then it's good.
Matt
If it works then it is not wrong. But if method A is easier to
implement than method B, then (all other things being equal) method A
is better.
Tony Marston http://www.tonymarston.net/
Matty <ma*******@askmenoquestions.co.uk> wrote in message news:<YN********************@wards.force9.net>... "Tony Marston" <to**@marston-home.demon.co.uk> wrote in message
news:75**************************@posting.google.c om...
<snip>
http://www.tonymarston.net/php-mysql...tml#2003-12-05
(Yet Another Follow Up...)
Can't help wondering what the object composition argument was, and how
on earth you could do it in a logical manner.
A table "has a" page of records?
A page of records "has a" table (what would it do if it didn't?)
Personally, yeah, I think composition isn't the way to do it...
/me thinks How about a table "has a" table perhaps???
;p
Matt
A table has 4 legs and a set of drawers. Now, if I were to drop the
drawers and spread the legs..... :)
Tony Marston http://www.tonymarston.net/
Tony Marston wrote:
FWIW, I still think it's better to have 12 different instances,
rather than 12 different classes <duck />...
According to the principles of OO you are not supposed to instantiate
an abstract class then feed it the implementation details, you are
supposed to put the implementation details in a subclass. If I were to
use the keyword 'abstract' in the class definition (as PHP 5 will
allow) you will find it impossible to instantiate an abstract class
directly, in which case you MUST use a subclass.
Depends on what you're doing with the "Table" class - if it's just a
question of iterating through the records, then one generic table class
would cover the vast majority of applications, without subclassing.
$parts = new Table ('partslist', 'partid', array('partid'=>'Part ID number',
'pdesc'=>'Description', 'stockcount'=>'Number in stock'));
$customers = new Table ('customers', 'custid', arrya('custid'=>'Customer #',
'tel'=>'Contact Phone', 'sic'=>'SIC Industry Code'));
should work fine.
The other comment I'd make on this, is that "abstract" != "abstraction".
Just because describing a table as
tablename
primarykey
fieldlist
is an abstraction, doesn't mean you need an abstract class for this - a "concrete"
class is fine for this model.
Personally, if I were writing a DB class lib, I'd have something along the lines of
Dataset
Table is-a Dataset
Query is-a Table, has-a SQL query
etc, etc
with Dataset being abstract, but that's just my take on it.
So, if I have 12 database tables each with a totally different set of
implementation details, then (according to the above-mentioned
principle) I must create 12 subclasses. I am right and you are wrong,
so score 1-0 to me :)
Yes and no, I would say. Yes, 12 tables requiring totally different handling
code would require 12 different classes. But the original tutorial, as I
remember it, showed 12 analogous tables (treated as a list of fields, etc)
that could all be handled by the same class as different instances, easily.
1-1 perhaps ;p
If it works then it is not wrong. But if method A is easier to
implement than method B, then (all other things being equal) method A
is better.
Couldn't agree more. I just think that your original base class was nearly there
for something that would handle any table, just given a list of fields to use!
Wonder how many months the total lifetime of this thread can be...
Matt
"Tony Marston" <to**@marston-home.demon.co.uk> wrote in message
news:75*************************@posting.google.co m... "Doug Hutcheson" <do*******************@nrm.qld.gov.au> wrote in message
news:<B%******************@news.optus.net.au>... "Tony Marston" <to**@marston-home.demon.co.uk> wrote in message
news:75**************************@posting.google.c om... "Philipp Lenssen" <in**@outer-court.com> wrote in message
news:<bq*************@ID-203055.news.uni-berlin.de>... > André Nęss wrote:
>
> > Tony Marston:
> >
> > >
> > > I have condensed the arguments into a single article which can
be > > > viewed at
> > > http://www.tonymarston.net/php-mysql/good-bad-oop.html
> > >
> >
> > I just think it's funny that you still don't understand object
> > composition. In your article you write: "How do you share code in
OO > > systems? Through inheritance.", not even mentioning object
> > composition. Object composition was also the crux of my argument,
> > i.e.: where you see only inheritance, I see inheritance and
> > composition. From this we can only deduce that you in fact did not
> > properly understand my argument. That doesn't make the discussion
any > > easier.
> >
>
> I was thinking the same. I saw the article, looked for
"composition", > couldn't find it, and went away.
Just for you I have added a section on object composition. I hope you
like it.
http://www.tonymarston.net/php-mysql...tml#2003-12-05
Kiss, kiss
Tony Marston
http://www.tonymarston.net/
Tony,
A trifle defensive <grin>, but wholly correct. As another 25+
programmer, I can state without too much fear of contradiction that the customer pays
me to solve his problem, not to write code which meets the approval of the
paradigm police.
More power to you, you rabid radical you!
Cheers,
Doug Hutcheson
People tend to describe me more as revolting than rebelling. Is there
a difference? :)
Tony Marston
http://www.tonymarston.net/
"Rebellent", perhaps?
<g,d&r>
"8-)
"Tony Marston" <to**@marston-home.demon.co.uk> wrote in message
news:75*************************@posting.google.co m... Matty <ma*******@askmenoquestions.co.uk> wrote in message
news:<YN********************@wards.force9.net>... > "Tony Marston" <to**@marston-home.demon.co.uk> wrote in message
> news:75**************************@posting.google.c om...
<snip>
>>
>> http://www.tonymarston.net/php-mysql...tml#2003-12-05
>>
(Yet Another Follow Up...)
Can't help wondering what the object composition argument was, and how
on earth you could do it in a logical manner.
A table "has a" page of records?
A page of records "has a" table (what would it do if it didn't?)
Personally, yeah, I think composition isn't the way to do it...
/me thinks How about a table "has a" table perhaps???
;p
Matt
A table has 4 legs and a set of drawers. Now, if I were to drop the
drawers and spread the legs..... :)
Tony Marston
http://www.tonymarston.net/
Ah - a rebellent furniture fetish!
Strange fruit, Tony, strange fruit indeed.
"8-)
Matty <ma*******@askmenoquestions.co.uk> wrote in message news:<_a********************@wards.force9.net>... Tony Marston wrote:
FWIW, I still think it's better to have 12 different instances,
rather than 12 different classes <duck />...
According to the principles of OO you are not supposed to instantiate
an abstract class then feed it the implementation details, you are
supposed to put the implementation details in a subclass. If I were to
use the keyword 'abstract' in the class definition (as PHP 5 will
allow) you will find it impossible to instantiate an abstract class
directly, in which case you MUST use a subclass.
Depends on what you're doing with the "Table" class - if it's just a
question of iterating through the records, then one generic table class
would cover the vast majority of applications, without subclassing.
$parts = new Table ('partslist', 'partid', array('partid'=>'Part ID number',
'pdesc'=>'Description', 'stockcount'=>'Number in stock'));
$customers = new Table ('customers', 'custid', arrya('custid'=>'Customer #',
'tel'=>'Contact Phone', 'sic'=>'SIC Industry Code'));
should work fine.
The other comment I'd make on this, is that "abstract" != "abstraction".
My class is abstract because it cannot be used without implementation
details, and these details are different for each database table.
Rather than have the implementation details for each table held in
separate script which is then fed into an instance of the abstract
class I feel it is more efficient to hold these details in a subclass.
<snip>
So, if I have 12 database tables each with a totally different set of
implementation details, then (according to the above-mentioned
principle) I must create 12 subclasses. I am right and you are wrong,
so score 1-0 to me :)
Yes and no, I would say. Yes, 12 tables requiring totally different handling
code would require 12 different classes. But the original tutorial, as I
remember it, showed 12 analogous tables (treated as a list of fields, etc)
that could all be handled by the same class as different instances, easily.
1-1 perhaps ;p
If it works then it is not wrong. But if method A is easier to
implement than method B, then (all other things being equal) method A
is better.
Couldn't agree more. I just think that your original base class was nearly there
for something that would handle any table, just given a list of fields to use!
You have missed a subtle point. Each table class is not limited to
those actions required to communicate with a single table - it also
contains all the business rules for the entity that is associated with
that table. This may mean obtaining fields from other sources,
performing calculations, validating against other tables, whatever.
All this *extra* processing is inserted into abstract methods which
are defined as empty stubs in the abstract class.
Perhaps I should have called it an abstract *entity* class instead of
an abstract *table* class.
Wonder how many months the total lifetime of this thread can be...
Matt
How long is a piece of string?
Tony Marston http://www.tonymarston.net/
Matty: Wonder how many months the total lifetime of this thread can be...
Well it's gonna last quite a while if you decide to go through everything
all over again, which is what you've started doing. May I suggest that you
just read the thread and save yourself the trouble? :)
André Nęss
Oh what the hell. Here's my two cents...
I agree with Tony Marston, if I read him right after skimming this
thread. Brit programmers have common sense, unlike most of my American
compatriots I have to interact with in the workplace.
OOP is way overblown. If you use it right, it's great. If you use it
wrong, and many pseudo-senior devs I've seen use it unnecessarily, it
can do nothing but introduce unecessary complexity and even slow the
app down.
For that matter, the same argument can be made for using XSLT to
abstract your presentation layer. XSLT is overblown and introduces
nothing but delays, I find.
The same arguments going on here in PHP are being argued like mad on
the .NET platform too.
Take for example a simple web-based checkbook app for a series of
users. You login, see your checkbook, and can make entries to it.
Here's what a series of developers might think:
psuedo-senior dev 1: Let's make a User object, Checkbook object, Login
object, Logout object, and an Entry object! Let's do objects for
anything we can think of!
psuedo-senior dev 2: Let's make the business layer push out nothing
but XML, then use XSLT to style this output for the end user.
psuedo-senior dev 3: I think we should make the data layer emit
nothing but XML.
psuedo-senior dev 4: I think we should make everything in stored
procedures and make it receive and emit XML. The presentation code can
be written in PHP to read the XML and style it with XSLT.
No. Not me on any of this, even if it were something as complex as a
Near Earth Object Tracking System, and I've been programming since
1979 and am 36 years old. My title says "Senior Developer". My take on
objects, XML, and XSLT would be:
1. I'd use an associate array (better known as a hash table by us old
f*cks), not an object, for the checkbook entry record.
2. Thinking about code-reuse for future projects, I'd bundle my
frequently used functions in a web class, strings class, db class, and
a settings class. That way, when I call a function (er, "method") like
Redirect, I can understand where this method came from, and so can
others who read my code, because I would have it listed in my code as
$web->Redirect('page.php'). If Redirect breaks, you instantly know
it's in the "_web.php" page (if you saw my Requires statement).
3. If an object isn't necessary, I avoid it like the plague. Not by
inexperience, but by /experience/.
4. When I have to work in teams, we decide on a set of pages and a
very small set of objects that we're going to assign to each team
member, and then we iron these out individually for a bit with test
harnesses. Eventually, we start sharing and interacting with each
others stuff when these start to stabilize.
5. I like XML, but I dislike XSLT. XSLT is way, way too difficult of
an implementation of a superbly fantastic idea. I'll wait until
something better comes out to replace XSLT. For now, you'll see me
doing and <% {code} %> and <%= $var %> in my code, although I try as
much as possible to reduce interruptions in the HTML because of the
speed hit. That's why you see me doing most of my code in the top of
the page before the HTML tags.
6. I like XML, but I don't want to make every thing a particular OO
layer run through it, such as making the business layer receive XML
and emit XML. I mean, I'm always on tight project schedules. Many a
stakeholder (end user) on a project will be intolerant of excuses
like, "I'm having problems with the XML." They want me to get in
there, fix the code, and it works. Right now I use XML for storage and
retrieval from text files, or for sending stuff over sockets, or for
interacting with another vendor's stuff. But that's all I've seen a
need for it.
7. I love the encapsulation/abstraction of objects when it makes sense
to implement that. And if OOP is tied in with a GUI, such as a window
or widget, it's cool too, such as the ability to use someone else's
widgets and make my own, or the ability to instantiate a window and
then subclass it. But I always ask myself, is this overblown for this
kind of solution? I like the situation forcing me into using OOP,
rather than starting with it in the first place.
8. If I'm going to make a loadable C++ module for PHP, hell yeah, I'd
use objects to be consistent with how third-party or intrinsic APIs
work in anything from PHP to VB to Java to other languages. But for
business app use, I let the situation dictate the need for objects,
not me project that into the situation.
9. Some portal products that your business app might "snap-in" to
might dictate that you implement your stuff in XML/XSLT, so I think it
makes sense there, just as long as someone proves to me that the
solution is fast enough and scalable enough.
Tony Marston wrote: You have missed a subtle point. Each table class is not limited to
those actions required to communicate with a single table - it also
contains all the business rules for the entity that is associated with
that table. This may mean obtaining fields from other sources,
performing calculations, validating against other tables, whatever.
All this *extra* processing is inserted into abstract methods which
are defined as empty stubs in the abstract class.
Perhaps I should have called it an abstract *entity* class instead of
an abstract *table* class.
Fair enough! Personally, I'd use a concrete table class, and subclass
the entities from there, but that's just how I'd do it.
Wonder how many months the total lifetime of this thread can be...
Matt
How long is a piece of string?
Depends if it's Good String or Bad String.
Maybe String::Good could have an elasticity member var...
André Nęss <an*********************@ifi.uio.no> wrote in message news:<br**********@maud.ifi.uio.no>... Matty:
Wonder how many months the total lifetime of this thread can be...
Well it's gonna last quite a while if you decide to go through everything
all over again, which is what you've started doing. May I suggest that you
just read the thread and save yourself the trouble? :)
André Nęss
I refuse to kowtow to the paradigm police. All the while you keep
spouting rubbish I will keep on telling you that you are spouting
rubbish.
Tony Marston http://www.tonymarston.net/ go********@hotpop.com (Google Mike) wrote in message news:<25**************************@posting.google. com>... Oh what the hell. Here's my two cents...
I agree with Tony Marston, if I read him right after skimming this
thread. Brit programmers have common sense, unlike most of my American
compatriots I have to interact with in the workplace.
OOP is way overblown. If you use it right, it's great. If you use it
wrong, and many pseudo-senior devs I've seen use it unnecessarily, it
can do nothing but introduce unecessary complexity and even slow the
app down.
For that matter, the same argument can be made for using XSLT to
abstract your presentation layer. XSLT is overblown and introduces
nothing but delays, I find.
Then your guys haven't learnt how to use XSL properly. It is a
scripting language just like PHP, and as such you can make use of
standard reusable modules. For example, in my sample application
(which you can try online at
http://www.tonymarston.net/sample/index.html) I have a family of 6
components for each entity/table list, insert, update, enquire,
delete, search for which I need only 2 (two) XSL stylesheets. Within
each of these stylesheets I make use of the <xsl:include> and
<xsl-call-template> functions to invoke common code. When I want to
paint a data field on a form all I use is the following:
<xsl:call-template name="datafield">
<xsl:with-param name="item" select="tree_type_desc"/>
</xsl:call-template>
This template/subroutine then decides how to paint the field
(display-only, single-line textbox, multi-line textbox, dropdown list,
radiogroup, checkbox, whatever) using information supplied either in
the XML file or as a parameter supplied at runtime to the XSL
transformation process.
I use similar template calls to build my action buttons, navigation
buttons, column headings, etc. They are documented at
http://www.tonymarston.net/xml-xsl/xml-and-xsl.html.
Using this technique, coupled with my own method of using
classes/objects which so many of you find objectionable, I can define
a database table and build the 6 components to maintain/display its
contents in 60 minutes. That is an average of 10 (ten) minutes per
component. How's about THEM apples!!
The same arguments going on here in PHP are being argued like mad on
the .NET platform too.
Take for example a simple web-based checkbook app for a series of
users. You login, see your checkbook, and can make entries to it.
Here's what a series of developers might think:
psuedo-senior dev 1: Let's make a User object, Checkbook object, Login
object, Logout object, and an Entry object! Let's do objects for
anything we can think of!
psuedo-senior dev 2: Let's make the business layer push out nothing
but XML, then use XSLT to style this output for the end user.
psuedo-senior dev 3: I think we should make the data layer emit
nothing but XML.
psuedo-senior dev 4: I think we should make everything in stored
procedures and make it receive and emit XML. The presentation code can
be written in PHP to read the XML and style it with XSLT.
The simplest way to deal with people like that is to lock them in a
room and see who can produces results the fastest. The winner gets to
keep his job. THAT tends to sort out the men from the monkeys.
No. Not me on any of this, even if it were something as complex as a
Near Earth Object Tracking System, and I've been programming since
1979 and am 36 years old. My title says "Senior Developer". My take on
objects, XML, and XSLT would be:
1. I'd use an associate array (better known as a hash table by us old
f*cks), not an object, for the checkbook entry record.
2. Thinking about code-reuse for future projects, I'd bundle my
frequently used functions in a web class, strings class, db class, and
a settings class. That way, when I call a function (er, "method") like
Redirect, I can understand where this method came from, and so can
others who read my code, because I would have it listed in my code as
$web->Redirect('page.php'). If Redirect breaks, you instantly know
it's in the "_web.php" page (if you saw my Requires statement).
3. If an object isn't necessary, I avoid it like the plague. Not by
inexperience, but by /experience/.
That goes for a whole host of different "thingies". I have seen
programmers try to use every "thingy" in the book just to prove they
know how to use it, which is not the same as using it effectively.
4. When I have to work in teams, we decide on a set of pages and a
very small set of objects that we're going to assign to each team
member, and then we iron these out individually for a bit with test
harnesses. Eventually, we start sharing and interacting with each
others stuff when these start to stabilize.
5. I like XML, but I dislike XSLT. XSLT is way, way too difficult of
an implementation of a superbly fantastic idea. I'll wait until
something better comes out to replace XSLT.
I suggest you learn to use XSLT effectively because it is here to
stay. Version 2.0 is in the pipeline, and the recently-released
standard for XFORMS (see http://www.w3.org/MarkUp/Forms/) which will
do away with all that non-standard javascript, is based quite heavily
on XML and XSL.
For now, you'll see me
doing and <% {code} %> and <%= $var %> in my code, although I try as
much as possible to reduce interruptions in the HTML because of the
speed hit. That's why you see me doing most of my code in the top of
the page before the HTML tags.
6. I like XML, but I don't want to make every thing a particular OO
layer run through it, such as making the business layer receive XML
and emit XML.
My PHP development environment manages to mix a lot of different ideas
procedural scripts, included' scripts, objects, 3-tier architecture
(with separate presentation, business and data access layers), XML and
XSL transformations, and I like to think that I use each technique to
its best advantage. If an old fart like me can do it, then why can't
the rest of you?
Tony Marston http://www.tonymarston.net/
Tony Marston: For that matter, the same argument can be made for using XSLT to
abstract your presentation layer. XSLT is overblown and introduces
nothing but delays, I find.
Then your guys haven't learnt how to use XSL properly. It is a
scripting language just like PHP, and as such you can make use of
standard reusable modules. For example, in my sample application
(which you can try online at
It's not like PHP at all. It's functional, for one, and that's actually
great. But the implementation is terrible, the syntax is a chore, and you
constantly find yourself having to go outside the language because it's so
constrained.
http://www.tonymarston.net/sample/index.html) I have a family of 6
components for each entity/table list, insert, update, enquire,
delete, search for which I need only 2 (two) XSL stylesheets. Within
each of these stylesheets I make use of the <xsl:include> and
<xsl-call-template> functions to invoke common code. When I want to
paint a data field on a form all I use is the following:
<xsl:call-template name="datafield">
<xsl:with-param name="item" select="tree_type_desc"/>
</xsl:call-template>
This template/subroutine then decides how to paint the field
(display-only, single-line textbox, multi-line textbox, dropdown list,
radiogroup, checkbox, whatever) using information supplied either in
the XML file or as a parameter supplied at runtime to the XSL
transformation process.
I've always found your love for XML and XSLT rather interesting considering
your other practices. How do you apply your beloved KISS principle in this
case? After all, what you propose is to do:
Data->Transformation to XML (presumably in PHP->XML->Transformation in
XSLT->Output
When you could do:
Data->Transformation in PHP->Output
Not only is the former much more tedious to actually implement, it's also
slower, and more prone to bugs because the pipeline is longer, meaning more
code, meaning more chances of bugs.
I'm not saying this is the case for you, but for anyone who are starting
out, who don't have your collection of modules and components, wouldn't you
agree that the XML/XSLT solution looks much more complex?
In short, I understand that you like it. But you can't really say "Now that
I've built a huge library of boilerplate code I can write my apps really
fast", and expect us to take this as an argument in favour of XML/XSLT. It
is an argument in favour of writing reusable code, but from this it is not
clear that XML/XSLT actually makes it easier to do so. So I think you
should explain why:
A) XML/XSLT using two transformations is better than simply doing a single
transformation.
B) XML/XSLT makes it easier to write reusable components.
I suggest you learn to use XSLT effectively because it is here to
stay. Version 2.0 is in the pipeline, and the recently-released
standard for XFORMS (see http://www.w3.org/MarkUp/Forms/) which will
do away with all that non-standard javascript, is based quite heavily
on XML and XSL.
Well, I'd be surprised to see browser support for XFORMS get to an
acceptable level within the next 4 years :P As long as MS dominates they
have no incentive to improve their browser, and they will continue to
dominate :/
André Nęss
Tony Marston: > Wonder how many months the total lifetime of this thread can be...
Well it's gonna last quite a while if you decide to go through everything
all over again, which is what you've started doing. May I suggest that
you just read the thread and save yourself the trouble? :)
André Nęss
I refuse to kowtow to the paradigm police. All the while you keep
spouting rubbish I will keep on telling you that you are spouting
rubbish.
Uh? What did I do now? Are you saying that you *want* to repeat the entire
discussion? I merely pointed out that Matty started making the same claims
that others had made before him, and I see no point in that. But of course,
if you want to repeat the entire discussion once more with Matty, then you
are free to do so. It just seems rather pointless.
André Nęss
André Nęss <an*********************@ifi.uio.no> wrote in message news:<br**********@maud.ifi.uio.no>... Tony Marston:
For that matter, the same argument can be made for using XSLT to
abstract your presentation layer. XSLT is overblown and introduces
nothing but delays, I find.
Then your guys haven't learnt how to use XSL properly. It is a
scripting language just like PHP, and as such you can make use of
standard reusable modules. For example, in my sample application
(which you can try online at
It's not like PHP at all. It's functional, for one, and that's actually
great. But the implementation is terrible, the syntax is a chore, and you
constantly find yourself having to go outside the language because it's so
constrained.
I don't have a problem with XSL. When I was building my library of
reusable code I sometimes found that my first approach failed, but by
attacking it from a different angle a solution would materialize. I
have found that anything I can do in PHP code to generate HTML I can
also do in XSL.
<snip>
I've always found your love for XML and XSLT rather interesting considering
your other practices. How do you apply your beloved KISS principle in this
case? After all, what you propose is to do:
Data->Transformation to XML (presumably in PHP->XML->Transformation in
XSLT->Output
When you could do:
Data->Transformation in PHP->Output
Not only is the former much more tedious to actually implement, it's also
slower, and more prone to bugs because the pipeline is longer, meaning more
code, meaning more chances of bugs.
On the contrary, I have found it easy to implement. All my objects in
the business layer return data in the form of associative arrays, and
I have written a single standard function which outputs this array to
an XML file. This is followed by another single standard function to
perform the actual transformation.
These two standard functions are called from within a standard set of
include files, so I don't have to bother recoding and retesting for
each new component.
My library of XSL templates also means less recoding and less
retesting because if a template works in one stylesheet it will work
in all stylesheets.
Other people use different template engines to turn their data into
HTML, but I have chosen to use XML/XSL because (a) it was built for
the job, (b) it does it very well, (c) it is a W3C standard, therefore
more HTML developers will be familiar with it than anything built
around PHP.
I'm not saying this is the case for you, but for anyone who are starting
out, who don't have your collection of modules and components, wouldn't you
agree that the XML/XSLT solution looks much more complex?
Anything can look complex to begin with, but my long experience has
taught me to take a complex problem and divide it into lots of simple
problems. Then, by solving each simple problem one at a time the
complex problem eventually just disappears.
In short, I understand that you like it. But you can't really say "Now that
I've built a huge library of boilerplate code I can write my apps really
fast", and expect us to take this as an argument in favour of XML/XSLT. It
is an argument in favour of writing reusable code, but from this it is not
clear that XML/XSLT actually makes it easier to do so.
The only way to succeed as a programmer in any language is to build up
a library of reusable components so that you can create working
components faster than the next guy. This takes time, practice and
skill, but is an investment that pays off in the end.
When I first starting teaching myself PHP I generated all HTML code
from within the PHP script, but I did not want to waste time
generating hand-crafted code for each individual page. As I was
already familiar with XML and XSL, and because access to these two
technologies was available in PHP, I chose to use these to generate my
HTML output rather than learn *another* templating language or waste
time writing one of my own. It may seem an odd mix, but it means that
I have totally separated my presentation logic from my business logic,
so I can make changes in one without mucking up the other.
It works for me, so I will continue using it. If you want to use a
different method then go ahead.
So I think you
should explain why:
A) XML/XSLT using two transformations is better than simply doing a single
transformation.
I only use one XSL transformation per web page. It is true that I have
to transform my SQL data into XML, but this is done automatically
within standard modules so I don't have to think about it.
B) XML/XSLT makes it easier to write reusable components.
I am not saying that it is easier to write reusable components in XSL,
but I am saying that it is *just* as easy to write reusable components
in XSL as it is in PHP. You just have to know how. If you want to see
a working collection of reusable XSL components then download the
sample application from my website. Once you see how easy it is you
will be able to generate reusable components of your own. I suggest you learn to use XSLT effectively because it is here to
stay. Version 2.0 is in the pipeline, and the recently-released
standard for XFORMS (see http://www.w3.org/MarkUp/Forms/) which will
do away with all that non-standard javascript, is based quite heavily
on XML and XSL.
Well, I'd be surprised to see browser support for XFORMS get to an
acceptable level within the next 4 years :P As long as MS dominates they
have no incentive to improve their browser, and they will continue to
dominate :/
André Nęss
You can already download and install a free XForms plugin for IE6 SP1
- checkout http://www.formsplayer.com/ The demand for
XForms-compatible browsers is so great that if Microsoft don't get
their ass into gear then customers will switch to other browsers.
Tony Marston http://www.tonymarston.net/ to**@marston-home.demon.co.uk (Tony Marston) wrote in message news:<75**************************@posting.google. com>... André Nęss <an*********************@ifi.uio.no> wrote in message news:<br**********@maud.ifi.uio.no>... Matty:
Wonder how many months the total lifetime of this thread can be...
Well it's gonna last quite a while if you decide to go through everything
all over again, which is what you've started doing. May I suggest that you
just read the thread and save yourself the trouble? :)
André Nęss
I refuse to kowtow to the paradigm police. All the while you keep
spouting rubbish I will keep on telling you that you are spouting
rubbish.
A person starts a thread, asking comments about his OO tutorial.
Many real programmers here refuse to accept his code as good OO. He
then went to Zend (<http://www.zend.com/zend/tut/tutorial-wong4.php>)
and starts another thread there badly criticizing the author (Benson
Wong). Then, he again came back to comp.lang.php and starts the
"argument" which is not of course a "discussion". Now, who is
rubbish??
I really appreciate André Nęss for his patience. I don't think
anyone will respect a person who stupidly mess with a regular
contributor.
--
"There are two kinds of people, those who do the work and those who
take the credit. Try to be in the first group; there is less
competition there." -- Indira Gandhi
Email: rrjanbiah-at-Y!com
R. Rajesh Jeba Anbiah wrote:
A person starts a thread, asking comments about his OO tutorial.
Many real programmers here refuse to accept his code as good OO. He
Many other real programmers found the code acceptable, still more found
his code good OO to some qualified extent. I can't help wondering, what
you think a "real programmer" is.
then went to Zend (<http://www.zend.com/zend/tut/tutorial-wong4.php>)
and starts another thread there badly criticizing the author (Benson
I didn't see the criticism he levelled at Wong (was it in here, or on Zend.com?),
so I can't comment on it in particular; I would say, however, that many different
philosophies of software development exist, and just because one is different to
another doesn't necessarily make either of them wrong. Personally, I would never
use most of the code examples given in the various online tutorials I have
seen, as most of them don't live up to my idea of what consitutes robust,
clean code.
Wong). Then, he again came back to comp.lang.php and starts the
I'm not aware of the precise timescale, but I do know that 1 - Tony started the
thread, which lasted a long time; 2 - I revived it with some general comments
on OO and software design goals in general. I don't think this counts as
"coming back", and I'm also curious as to what this represents in the bigger
scheme of things, as far as reprehensible behaviour is concerned.
"argument" which is not of course a "discussion". Now, who is
I think you'll find it was a bit of both. Yes, there were barbed comments
flying in all directions as attacks on techniques and ideas turned into
attacks on the holders of the ideas (ad hominem). On the flip side,
there was a good deal of healthy debate on the pros and cons of OO design
patterns, on PHP OO, and on the use of OO in general. I would imagine that
many people benefitted from reading a wide variety of viewpoints and opinions,
allowing them to form their own, rather than just parroting the words of others.
I think that is a healthy thing, even if it did mean some bad blood.
rubbish??
OK, that was just childish. Isn't this the kind of language you are deprecating
in your post?
I really appreciate André Nęss for his patience. I don't think
I don't think that Andre, Tony, I or any of the many people who contributed to
the threads involved exemplified patience. I for one have rapidly put fingers
to keyboard in a fit of rage, digust or just plain confusion at what
$SOME_OTHER_PERSON has written, and I suspect the others are the same. The main
reason Andre contributed so heavily to the threads in question, is that he disagreed
strongly with Tony's views, just as Tony disagreed with his.
anyone will respect a person who stupidly mess with a regular
contributor.
OK. How long have you been reading this group? Just to recap, the original thread
was started by Tony, who stated that he had posted a basic, beginner-oriented
tutorial on creating classes in PHP. The "messing" then followed, mostly in
the form of criticism of Tony's design decisions. So that would indicate that
Andre was messing with Tony. It's also interesting to note, that the chief original
critiscm of the tutorial, was that adding methods to handle paged output of data
records (through mysql's "limit" clause) was "bad OO" (I don't really agree with
this), rather than on how helpful the tutorial was for beginners to PHP OO.
Andre and Tony are (were at least) regular contributors to this group. I also used
to be, and I have noticed that the names seem to have changed lately. Nonetheless,
regular contributions to a newsgroup/discussion list/chatroom do not make someone
an expert on all things, to be respected blindly with adoration. Anyone who has read
CSS-Discuss will be aware of one particular poster, whose comments generally tend towards
the limit case "Your fonts are too small".
You should respect someone because what they say is interesting, thought-provoking, or
simply plain helpful. Virtually all of the contributors to this thread (in its various
incarnations) qualify by this criterion. Personally, I respect both Tony's and Andre's
views and expertise. I have different views to both of them, and I'm pretty sure I code
differently to the way they use (I know this for a fact in Tony's case, since I have seen
a large body of his code).
I do agree that maybe the rebuttal Tony posted was a little strongly worded at times, but
I do think he has a right to say the things he did, and many of them I find valid. I disagree
with some of them, but that's because I see things differently. I'm a different person
after all, with the ability to form my own opinions and ways of working.
I enjoy dicussing matters with others who hold different opinions to mine; and this is how
people grow and develop new ideas. I would hate to think that a lively discussion on software
design could be stopped just because someone has made newcomers frightened of offending
Matty <ma*******@askmenoquestions.co.uk> wrote in message news:<pj********************@wards.force9.net>... R. Rajesh Jeba Anbiah wrote:
A person starts a thread, asking comments about his OO tutorial.
Many real programmers here refuse to accept his code as good OO. He
Many other real programmers found the code acceptable, still more found
his code good OO to some qualified extent. I can't help wondering, what
you think a "real programmer" is.
then went to Zend (<http://www.zend.com/zend/tut/tutorial-wong4.php>)
and starts another thread there badly criticizing the author (Benson
I didn't see the criticism he levelled at Wong (was it in here, or on Zend.com?),
Try this URL: http://www.zend.com/zend/comments/sh...4&mode=&kind=t
<snip>
Tony Marston http://www.tonymarston.net/
Hi...Matty wrote: Can't help wondering what the object composition argument was, and how
on earth you could do it in a logical manner.
A table "has a" page of records? [snip]
There are a whole load of ways of skinning this particular cat. Here's
one...
A row has a data list.
A row has a field list.
A result set has rows.
A result set has a table.
A table has a name.
A table has a field list.
A field list has fields.
With these arrangements I could completely describe the most commonly
used database mappings with the following classes: Row, Field, Table,
Query, Connection. By using factory methods to assemble these
appropriately, I need no subclasses at all. This is actually a perfectly
valid way of solving the problem. Anything you can do with inheritance
you can do with composition, although the code may be less clear because
everything happens at run time.
Having one class per table and placing extra domain code in these
classes is known as the "Table Gateway" pattern, or is sometimes called
a DAO in Java circles (which is actually usually slightly different as
they usually have dumb tables and smart rows). It is an effective
solution if the application presents mostly tabular data and
relationships between the data are not too complex. This approach gets
really nasty once you get away from this. Choosing this is usually a
sign that the system was designed from the data viewpoint, rather than
the object viewpoint. It should be efficient from the point of view of
writing least code because of it's simplicity, but is a poor performer
when it comes to responding to change. Changing the app. means changing
the table structure as well as all the code above, because of the
isomorphic relationship cutting accross the layers. You can get away
with it for a long time using views and table filters, so it isn't a bad
approach by any means. It's just that it applies to only a small part of
the enterprise problem space. One where the OO language is slave to the
DB rather than the other way around.
;p
Matt
Did that answer help?
yours, Marcus
--
Marcus Baker, ma****@lastcraft.com, no***@appo.demon.co.uk
Hi...
Philipp Lenssen wrote: And employee "is a type of" person. So it would not make sense to use
object composition. (Not if person and employee are intended to be the
same anyway.) Because an employee shares attributes of a person but
includes his own.
I do agree with you, but cannot resist picking up on this. I know you
chose it as an off hand example, and it's so easy to criticise...;)
Making employee a descendent of person is nearly always a bad idea.
Employment has a different lifetime than a person. Employment is a
relationship rather than an inate property. I would have...
Person<>--->Employment<---<>Company
That is...
class Party { ... }
class Person extends Party { ... }
class Company extends Party { ... }
class Employment {
function Employment($employer, $employee, $date) {...}
function terminate($date) {...}
function getEmployee() {...}
function getEmployer() {...}
}
That way your job applicant can become your employee and then retire,
all without having to be deleted and recreated as something else each time.
yours, Marcus
--
Marcus Baker, ma****@lastcraft.com, no***@appo.demon.co.uk
Matty: OK. How long have you been reading this group? Just to recap, the
original thread was started by Tony, who stated that he had posted a
basic, beginner-oriented
tutorial on creating classes in PHP. The "messing" then followed, mostly
in
the form of criticism of Tony's design decisions. So that would indicate
that
Andre was messing with Tony. It's also interesting to note, that the
chief original critiscm of the tutorial, was that adding methods to handle
paged output of data records (through mysql's "limit" clause) was "bad OO"
(I don't really agree with this), rather than on how helpful the tutorial
was for beginners to PHP OO.
Actually that's not entirely correct. Tony's original post said that he had
tried to get the code accepted into some sort of class repository, but the
code was rejected because it wasn't OO enough, according to the person in
charge. He then turned to this group because he wanted an explanation of
why (if) this was the case. People, me included, tried to give one. We
didn't start "messing" with him.
As I stated a couple of times in my posts, I understand that Tony's approach
works, and I understand that he prefers it. But the background for the
discussion was whether other people could reuse his code easily through
such a class repository, not whether Tony can use his own code.
André Nęss
André Nęss wrote: Actually that's not entirely correct. Tony's original post said that he
had tried to get the code accepted into some sort of class repository, but
the code was rejected because it wasn't OO enough, according to the person
I stand corrected! As I remembered it, the initial posting was a "Look
at my tutorial" thing, then followed with "There's no way you'd get this
into a repository". I would agree with the "insufficient OO" case, at least
as far as having a subcalss for every table goes anyway.
in charge. He then turned to this group because he wanted an explanation
of why (if) this was the case. People, me included, tried to give one. We
didn't start "messing" with him.
Maybe I shoudl have stated my (intended) irony a little more strongly... I
don't really feel that anyone was actually "messing" with anyone - that was
the point of my reply to Anbiah. Mainly, I was taking issue with the OP's
comment, which essentially came down to "How dare you mess with Andre Naess?
The man is a *god*!" I feel this kind of unquestioning hero-worship can
block healthy debate, since newcomers will be too frightened to disagree
with what someone else has said.
As I stated a couple of times in my posts, I understand that Tony's
approach works, and I understand that he prefers it. But the background
for the discussion was whether other people could reuse his code easily
through such a class repository, not whether Tony can use his own code.
Some of it was, yes, but it's also worth noting that the inclusion (or
otherwise) of the recordset paging code is a question of design philosophy/
methodology, and has nothing to do with the question of Object Orientation...
Marcus Baker wrote: Hi...Matty wrote: Can't help wondering what the object composition argument was, and how
on earth you could do it in a logical manner.
A table "has a" page of records? [snip]
There are a whole load of ways of skinning this particular cat. Here's
one...
A row has a data list.
A row has a field list.
<snip>
Yes, thanks, I am aware of the method. My point, was that originally Tony
presented a table handling class, which was essentially designed to iterate
through the data (or maybe return a chunk as several assoc arrays, I can't
remember exactly). When Tony added a method to return a subset of the data
a-la "Display 1-10, 11-20, 21-30, etc", some people complained that this was
bad OO, that he was confusing presentation with application/business logic.
One suggestion advanced was that paging the data should be handled through
composition/aggregation - that was the reason for the sarcasm in my post,
since doing something like this confuses the interface for interacting with
the table, which already returns records itself.
Having one class per table and placing extra domain code in these
classes is known as the "Table Gateway" pattern, or is sometimes called
<...>
approach by any means. It's just that it applies to only a small part of
the enterprise problem space. One where the OO language is slave to the
DB rather than the other way around.
Yes, I'm aware of this approach, having written class libraries that do exactly
this kind of thing (generally in an extensible, predictable fashion ;p), and
used them too. Thankyou for the heads-up. I think it's safe to assume, that
if people are discussing OO design, they have some experience of the issues
involved.
Matt
Hi...
Matty wrote: Marcus Baker wrote:
Yes, thanks, I am aware of the method.
Sorry, I didn't mean to be condescending. The question was a rather open
one and so I started with the broadest answer.
When Tony added a method to return a subset of the data
a-la "Display 1-10, 11-20, 21-30, etc", some people complained that this was
bad OO, that he was confusing presentation with application/business logic.
Java developers don't have this problem as the data is cached between
page requests. In Java I would definitely either load the whole set or
place holders for later (lazy) loading. It's easier to do paging in this
case as the data fetch is totally separated from use of the data.
If we do that in PHP we end up pulling loads of data only to see it all
disappear at the end of the script. This makes paging a performance
issue. Optimisation tends to break the purity of paradigms pretty
quickly, but you can usually rework things to keep code maintainable.
One suggestion advanced was that paging the data should be handled through
composition/aggregation - that was the reason for the sarcasm in my post,
since doing something like this confuses the interface for interacting with
the table, which already returns records itself.
I don't think sarcasm is a good idea in any post, but I digress. These
would be one possible set of guidelines:
Write the cleanest version first (no paging). Create a class (called a
Pager I guess), but don't add functionality to it. Now write some code
that passes in the Pager to whatever does the fetch. I'll call that a
Finder for the moment. Connecting them, together should yield some
possible points of contact. If the Finder uses a raw SQL query or
(preferably) some kind of Query class, then the Finder can even apply
the limit clause directly.
It's better if the pager will communicate with the query object
directly. You could then add a method to the Finder called addSelector()
or something. The Finder doesn't need to know it's a Pager at all, just
some kind of search modifier.
If you decide to write finder code, place it in a separate method. Now
if you want, you can create a subclass of the Finder called PagingFinder
and move all Pager related stuff into it. With either strategy, you have
gained a lot of flexibility as you can plug in the paging as required.
The Pager is part of the data layer here. Your app requests one as a
service of that layer.
I am sure you can come up with other strategies.
Thankyou for the heads-up. I think it's safe to assume, that
if people are discussing OO design, they have some experience of the issues
involved.
Well, my apologies again. I did not mean to insult your intelligence.
What exactly are you asking?
Matt
yours, Marcus
--
Marcus Baker, ma****@lastcraft.com, no***@appo.demon.co.uk
Marcus Baker <ma****@lastcraft.com> wrote in message news:<3F**************@lastcraft.com>... Hi...Matty wrote: Can't help wondering what the object composition argument was, and how
on earth you could do it in a logical manner.
A table "has a" page of records? [snip]
There are a whole load of ways of skinning this particular cat. Here's
one...
A row has a data list.
A row has a field list.
A result set has rows.
A result set has a table.
A table has a name.
A table has a field list.
A field list has fields.
With these arrangements I could completely describe the most commonly
used database mappings with the following classes: Row, Field, Table,
Query, Connection. By using factory methods to assemble these
appropriately, I need no subclasses at all. This is actually a perfectly
valid way of solving the problem. Anything you can do with inheritance
you can do with composition, although the code may be less clear because
everything happens at run time.
Having one class per table and placing extra domain code in these
classes is known as the "Table Gateway" pattern, or is sometimes called
a DAO in Java circles (which is actually usually slightly different as
they usually have dumb tables and smart rows). It is an effective
solution if the application presents mostly tabular data and
relationships between the data are not too complex. This approach gets
really nasty once you get away from this. Choosing this is usually a
sign that the system was designed from the data viewpoint, rather than
the object viewpoint.
That is correct. Database design has primary importance as it directly
relates to the performance of the system. I therefore design my
database first, then build objects to access the data.
It should be efficient from the point of view of
writing least code because of it's simplicity, but is a poor performer
when it comes to responding to change.
I disagree. I have been building and maintaining systems for 25+
years, so I have some experience of what makes them easy or difficult
to update over a period of time. For me the most useful design
philosphy is the 3 Tier Architecture where the presentation, business
and data access layers are built from totally separate components.
Thus any layer can be changed without affecting the others. Using
Object-based programming is not that much different from
Component-based programming - the correct technique (IMHO) is to use
it as efficiently and effectively as possible.
Changing the app. means changing
the table structure as well as all the code above, because of the
isomorphic relationship cutting accross the layers. You can get away
with it for a long time using views and table filters, so it isn't a bad
approach by any means. It's just that it applies to only a small part of
the enterprise problem space. One where the OO language is slave to the
DB rather than the other way around.
The data is ALWAYS more important than the language used to access it.
Tony Marston http://www.tonymarston.net/
Marcus Baker <ma****@lastcraft.com> wrote in message news:<3F**************@lastcraft.com>... Hi...
Matty wrote: Marcus Baker wrote:
Yes, thanks, I am aware of the method.
Sorry, I didn't mean to be condescending. The question was a rather open
one and so I started with the broadest answer.
> When Tony added a method to return a subset of the data
a-la "Display 1-10, 11-20, 21-30, etc", some people complained that this was
bad OO, that he was confusing presentation with application/business logic.
Java developers don't have this problem as the data is cached between
page requests. In Java I would definitely either load the whole set or
place holders for later (lazy) loading. It's easier to do paging in this
case as the data fetch is totally separated from use of the data.
If we do that in PHP we end up pulling loads of data only to see it all
disappear at the end of the script. This makes paging a performance
issue. Optimisation tends to break the purity of paradigms pretty
quickly, but you can usually rework things to keep code maintainable.
How you do things in Java (or any other language for that matter) is
irrelevant as this is a PHP newsgroup talking about techniques that
PHP programmers use. When retrieving subsets of data (i.e. 'paging')
with PHP/MySQL the recommended approach is to use the LIMIT clause on
the sql SELECT statement. Retrieving all available data and holding it
in memory sounds like a stupid idea to me.
<snip>
Tony Marston http://www.tonymarston.net/
Hi...
Tony Marston wrote: Marcus Baker <ma****@lastcraft.com> wrote in message news:<3F**************@lastcraft.com>...
How you do things in Java (or any other language for that matter) is
irrelevant...
When responding to a post, at least try to understand the post first. It
makes the thread so much more useful. In particular...
1) I was pointing out the *difference* between the Java approaches and
PHP and hinting at why some opinions of this thread may reflect
different backgrounds. This is grist to your mill too. I look forward to
your apology.
2) How things are done in other languages is entirely relevant. I mean
relevant, not copied without thinking (to pre-emt another lame post).
You can learn a lot about designs by seeing how the same tradoffs are
managed in different environments. If I were a classical composer, I
would listen to world music. If I were a French chef, I would visit
Indian resturants. It's about learning.
Tony Marston
yours, Marcus
--
Marcus Baker, ma****@lastcraft.com, no***@appo.demon.co.uk
Hi...
Tony Marston wrote:
That is correct. Database design has primary importance as it directly
relates to the performance of the system. I therefore design my
database first, then build objects to access the data.
This only works for established, and pretty much solved, problems. Less
defined and rapidly changing systems need a different approach. There
are a host of studies in this area, now. See references by Rebecca
Wirfs-Brock, Scott Ambler and others. Basically it leads to "god"
classes in big systems which then get atrophied. There is a heavy onus
on upfront design there and weaker encapsulation.
Even the corporate DBAs are starting to see the light. There is at last
talk of "refactoring" databases.
It should be efficient from the point of view of
writing least code because of it's simplicity, but is a poor performer
when it comes to responding to change.
I disagree. I have been building and maintaining systems for 25+
years, so I have some experience of what makes them easy or difficult
to update over a period of time.
So do plenty of other people. Guess what? They disagree with you. I do
too. It's sad that you think that quoting a number of years in a field
gives you some kind of right to "win" a discussion. What shows through
all of your posts is your lack of experience within OO and a hostile
attitude to help. Isaac Newton did not have to rediscover for himself a
thousand years of Science. He stood on the shoulders of giants.
Using
Object-based programming is not that much different from
Component-based programming - the correct technique (IMHO) is to use
it as efficiently and effectively as possible.
If you are just creating a few big classes that match each part of the
system, then you are right. All you have done is used the flexibility of
OO to recreate a paradigm you are familiar with. You could just as
easily have written it in Modula 2 or used structs and pointers in C.
There is little wrong with this approach (we all go through it). It is
not the only solution available, though. You should at least try out
some other patterns to see what works and what does not. Any idiot can
get a twelve business class project working in almost any environment.
Some approaches scale better than others. Some have better performance.
Some can be produced quickly. Some can be produced with less skill. Some
with more flexibility. You have only one design so far.
The data is ALWAYS more important than the language used to access it.
I'll be more precise. This style of coding only applies to situations
where the business model is isomorphic with a single (unencapsulated)
data model. If only we had this luxury.
You picked up on the word "language" and so missed the point.
Tony Marston
You boasted in a previous post that it took 60 mins to add six tables
and classes. That is actually pretty dismal for what is pretty routine
coding. I just completely rewrote our charging and billing system.
That's about 15 tables, 15 DAOs and 4 business classes (now 3). That
took an hour and a half. We generate the data mappers and SQL, so that
was just an XML edit. The bulk of the time was thus writing the
automated tests and documentation. All whilst gently chatting to the
business development guy that I was working with. We like to take things
easy you see.
Unlike Andre I do not have the patience of saints. You sure as hell
better have an argument that advances the discussion for me to bother to
reply to any more of your posts.
yours, Marcus
--
Marcus Baker, ma****@lastcraft.com, no***@appo.demon.co.uk
Marcus Baker <ma****@lastcraft.com> wrote in message news:<3F**************@lastcraft.com>... Hi...
Tony Marston wrote: Marcus Baker <ma****@lastcraft.com> wrote in message news:<3F**************@lastcraft.com>...
How you do things in Java (or any other language for that matter) is
irrelevant...
When responding to a post, at least try to understand the post first. It
makes the thread so much more useful. In particular...
1) I was pointing out the *difference* between the Java approaches and
PHP and hinting at why some opinions of this thread may reflect
different backgrounds. This is grist to your mill too. I look forward to
your apology.
I am not interested in how things can be done in Java, I am only
interested in how things can be done in PHP.
2) How things are done in other languages is entirely relevant.
Then all my experience in other languages is relevant, then?
I mean
relevant, not copied without thinking (to pre-emt another lame post).
You can learn a lot about designs by seeing how the same tradoffs are
managed in different environments.
I have seen too many development environments created by other people
where they get so tied up in their rules they lose sight of the fact
that the aim of the software developer is to produce software as
quickly as possible. A method which takes weeks to produce each
component is rubbish when compared to one that takes days, which in
turn is rubbish when compared with one that takes hours.
If I were a classical composer, I
would listen to world music. If I were a French chef, I would visit
Indian resturants. It's about learning.
I have been learning about software development for the past 25+
years, I am still learning today, and I expect to keep on learning in
the future. But most of what people are trying to teach me are methods
that I have already encountered in the past and discarded. Come up
with an idea that is better and I will listen, but if all you can do
is regurgitate the same worn-out crap as others then you are wasting
your breath.
Tony Marston
Marcus Baker <ma****@lastcraft.com> wrote in message news:<3F**************@lastcraft.com>... Hi...
<snip>
It should be efficient from the point of view of
writing least code because of it's simplicity, but is a poor performer
when it comes to responding to change.
I disagree. I have been building and maintaining systems for 25+
years, so I have some experience of what makes them easy or difficult
to update over a period of time.
So do plenty of other people. Guess what? They disagree with you. I do
too.
Some people liked my approach while others didn't. That's life. Other
people may choose a different solution, but if it works for them then
that's cool. It just goes to show that there is no single solution, no
single methodology. Each approach has its own set of advantages and
disadvantages, and may work better in some situations than others. I
am not saying that everybody *must* use my approach, which is why I
object when others try to tell mne that I *must* use their approach.
It's sad that you think that quoting a number of years in a field
gives you some kind of right to "win" a discussion. What shows through
all of your posts is your lack of experience within OO and a hostile
attitude to help.
Nobody has tried to offer *help* in any shape or form. They have
simply objected to my approach because it is different from theirs,
because it breaks their set of rules.
Isaac Newton did not have to rediscover for himself a
thousand years of Science. He stood on the shoulders of giants.
He had giants, I have pygmies.
> Using
Object-based programming is not that much different from
Component-based programming - the correct technique (IMHO) is to use
it as efficiently and effectively as possible.
If you are just creating a few big classes that match each part of the
system, then you are right. All you have done is used the flexibility of
OO to recreate a paradigm you are familiar with. You could just as
easily have written it in Modula 2 or used structs and pointers in C.
Probably, but I chose to write it in PHP.
There is little wrong with this approach (we all go through it). It is
not the only solution available, though. You should at least try out
some other patterns to see what works and what does not.
I have seen examples of other people's methods and I have not been
impressed.
Any idiot can
get a twelve business class project working in almost any environment.
Some approaches scale better than others. Some have better performance.
Some can be produced quickly. Some can be produced with less skill. Some
with more flexibility. You have only one design so far.
But at least it is a design that works, and more efficiently than
others I have seen.
The data is ALWAYS more important than the language used to access it.
I'll be more precise. This style of coding only applies to situations
where the business model is isomorphic with a single (unencapsulated)
data model. If only we had this luxury.
You picked up on the word "language" and so missed the point.
Tony Marston
You boasted in a previous post that it took 60 mins to add six tables
and classes.
No. One table, one class, 6 components.
That is actually pretty dismal for what is pretty routine
coding. I just completely rewrote our charging and billing system.
That's about 15 tables, 15 DAOs and 4 business classes (now 3). That
took an hour and a half.
Congratulations, you have an efficient development environment. But
how many of those wierd ideas that people have tried to stuff down my
throat do you actually employ yourself?
We generate the data mappers and SQL, so that
was just an XML edit. The bulk of the time was thus writing the
automated tests and documentation. All whilst gently chatting to the
business development guy that I was working with. We like to take things
easy you see.
I like to take things easy as well, which is why I create development
environments which enable me to create working components in hours or
minutes instead of days or even weeks.
Unlike Andre I do not have the patience of saints. You sure as hell
better have an argument that advances the discussion for me to bother to
reply to any more of your posts.
yours, Marcus
Unless you have something constructive to say then don't bother.
Tony Marston http://www.tonymarston.net/
Tony Marston: I have seen too many development environments created by other people
where they get so tied up in their rules they lose sight of the fact
that the aim of the software developer is to produce software as
quickly as possible. A method which takes weeks to produce each
component is rubbish when compared to one that takes days, which in
turn is rubbish when compared with one that takes hours.
I must respectfully disagree.
The software lifecycle is generally dominated by it's live time (the time it
is in actual use) rather than it's development time. This means that for
most software the amount of time spent maintaining it dwarfs the amount of
time it takes to develop it. The prime goal of the software developer is
thus to reduce the time actually spent on a piece of software, including
both development and maintenance.
What this means in practice is that if you by have this piece of software
which takes 1 week to develop, and 3 weeks to maintain, you're better off
if you can spend 2 weeks developing and only 1 week maintaining. Building
scalable and maintainable software is indeed a difficult challenge, and the
solution which seems fastest at first may not be the most efficient over
the entire lifespan of the software.
What constitutes a scalable and maintainable software system is a rather
more involved discussion, however.
André Nęss
Tony Marston: Nobody has tried to offer *help* in any shape or form. They have
simply objected to my approach because it is different from theirs,
because it breaks their set of rules.
I don't know what you mean by help in this context, but I did propose a
different solution. You objected to it, I suppose, because it was different
from yours. I guess we are even.
André Nęss
Marcus Baker <ma****@lastcraft.com> wrote in message news:<3F**************@lastcraft.com>... Hi...
<snip>
You boasted in a previous post that it took 60 mins to add six tables
and classes. That is actually pretty dismal for what is pretty routine
coding. I just completely rewrote our charging and billing system.
That's about 15 tables, 15 DAOs and 4 business classes (now 3). That
took an hour and a half.
Was that using a development environment that you constructed
yourself, or did someone create it for you?
You say "rewrote", so does that mean you reused existing components
rather than writing them from scratch?
Minor points, but it makes a difference.
Tony Marston http://www.tonymarston.net/
Tony Marston wrote: Isaac Newton did not have to rediscover for himself a
thousand years of Science. He stood on the shoulders of giants. He had giants, I have pygmies.
....he said, offhandedly dismissing 40 years of advancement in software
development...
If you are just creating a few big classes that match each part of the
system, then you are right. All you have done is used the flexibility of
OO to recreate a paradigm you are familiar with. You could just as
easily have written it in Modula 2 or used structs and pointers in C.
Probably, but I chose to write it in PHP.
Whatever language you use: Using classes and objects doesn't make a
program object oriented.
I like to take things easy as well, which is why I create development
environments which enable me to create working components in hours or
minutes instead of days or even weeks.
Anyone can create "working" components very quickly. That says nothing
about wether they can be easily maintained and adapted to changing
requirements, which is what most development time is spent doing.
If you have to rewrite half your system for every change, I'd rather
spend more time on the initial creation. Shortcuts make long delays...
Jochen
Hi...
Tony Marston wrote: Was that using a development environment that you constructed
yourself, or did someone create it for you?
We did write it ourselves. At the time there were no persistence
libraries around except for Binary Cloud. The persistence mechanism in
that was an early version and not very nice to use.
Over the last couple of years our layer has gradually evolved to what it
is now. I would love to open source it, but it is very much proprietry
right now.
It started as a straight forward ActiveRecord layer, but with a lot of
commonality in the Persistent and PersistenceBroker superclasses. The
SQL schema was generated by the PHP, but required some magic when
creating subclasses by hand. We moved the schema to XML and code
generated (XSLT) both the persistence subclasses and the SQL.
This was a big advance in itself, but the final dose of sugar was adding
one-to-many and many-to-one relationships straight into the XML schema.
With this taken care of automatically, schema changes are a doddle. The
days of horrendous data porting scripts are finally gone. It also
completely hides the primary keys from the client code.
The system can be used as either ActiveRecord generator or DataMapper
generator. I am an ActiveRecord fan, but our Java influenced developer
prefers DataMapper and he is currently winning the argument.
You say "rewrote", so does that mean you reused existing components
rather than writing them from scratch?
A quick look at CVS...we wrote one new class, edited two and dumped two.
Looks like about 25 lines of code in all. All the others are code
generated. Three test cases had to be heavily edited (drudge) and that
looks like another 25 lines. We also changed a few names here and there
to fit the new model better so that might be inflating the LOC.
We have a one click roll-out without schema changes, but a two click and
one script one with changes. We still had the whole thing live on main
test machine at the end of the session. We should be able to roll out to
the main servers at the end of this iteration.
Minor points, but it makes a difference.
Fair dues, but I am a big believer in the "value stream mapping" system
in lean development. Time from idea to roll-out - nothing else matters.
Tony Marston
http://www.tonymarston.net/
yours, Marcus
--
Marcus Baker, ma****@lastcraft.com, no***@appo.demon.co.uk
André Nęss <an*********************@ifi.uio.no> wrote in message news:<br**********@maud.ifi.uio.no>... Tony Marston:
I have seen too many development environments created by other people
where they get so tied up in their rules they lose sight of the fact
that the aim of the software developer is to produce software as
quickly as possible. A method which takes weeks to produce each
component is rubbish when compared to one that takes days, which in
turn is rubbish when compared with one that takes hours.
I must respectfully disagree.
The software lifecycle is generally dominated by it's live time (the time it
is in actual use) rather than it's development time. This means that for
most software the amount of time spent maintaining it dwarfs the amount of
time it takes to develop it. The prime goal of the software developer is
thus to reduce the time actually spent on a piece of software, including
both development and maintenance.
Initial development time is vitally important when the client has a
tight deadline and a tight budget. I once worked on a large project
for a government department where the project plan expected components
development times to be measured in days. After the development
infrastructure was designed and built by a team of so-called experts
(6 people for 6 months) they discovered that it was actually taking
weeks to build each component. After recalculating the costs the
client decided that going 2 million GBP over budget and being 6 months
late was not acceptable, so he cancelled the whole project.
I showed them my own infrastructure where the same components could be
built in under an hour each, but the system architects rejected it
because it did not abide by their rules.
What this means in practice is that if you by have this piece of software
which takes 1 week to develop, and 3 weeks to maintain, you're better off
if you can spend 2 weeks developing and only 1 week maintaining.
If you can write something from scratch in 1 week but take 3 weeks to
maintain it then you are doing something wrong. If the scale of
changes were that huge I would scrap the original program and rewrite
it.
Building
scalable and maintainable software is indeed a difficult challenge, and the
solution which seems fastest at first may not be the most efficient over
the entire lifespan of the software.
I have spent a great deal of time in maintaining software that I have
written, so I am aware of the problems of writing sofware that is
difficult to maintain. That is why maintainability is high on my list
of priorities.
What constitutes a scalable and maintainable software system is a rather
more involved discussion, however.
How very true.
Tony Marston This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: darwinist |
last post by:
What PHP Represents
There is no shortage of complaints one could make about php as a
language, and although the list does shrink with each release, some of
them are inherent to the origins and...
|
by: perseus |
last post by:
I think that everyone who told me that my question is irrelevant,
in particular Mr. David White,
is being absolutely ridiculous. Obviously, most of you up here
behave like the owners of the C++...
|
by: Sarah Tanembaum |
last post by:
Beside its an opensource and supported by community, what's the fundamental
differences between PostgreSQL and those high-price commercial database (and
some are bloated such as Oracle) from...
|
by: Hermawih |
last post by:
Hello ,
I want your opinion about this .
In order to say it clearly , I think I have to describe it in long sentences .
I could consider myself as Intermediate/Advance Access Developer ;...
|
by: Vishal Naidu |
last post by:
i m new to the C world...
i ve been told by my instructors not to use goto stmt..
but no one could give me a satisfactory answer as to why it is so..
plz help me out of this dilemma, coz i use...
| | |
by: Xah Lee |
last post by:
in March, i posted a essay āWhat is Expressiveness in a Computer
Languageā, archived at:
http://xahlee.org/perl-python/what_is_expresiveness.html
I was informed then that there is a academic...
|
by: TB |
last post by:
Hi Everyone on comp.lang.c++:
I am thinking about learning a programming language and I want to
decide whether it is worthwhile spending my time learning the C++
programming language.
I am a...
|
by: clintonG |
last post by:
Every single time neophytes or converts ask about naming and style
conventions what are they told by the majority consensus? The answer is "do
what you prefer but do so consistently" right? Yes,...
|
by: Mason |
last post by:
I've been working to become competent at making websites. My learning path
has been:
html -css- paintshop pro -javascript -php/mysql
I'm getting somewhat proficient at php/mysql (although I...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development projectplanning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
