PHP puts most of its functions into a big flat global namespace.
That leads to short function names - but creates a namespace
minefield for programmers.
Lots of the functions are legacies from the days before PHP
got object-oriented features.
For instance we currently have:
strstr(haystack, needle)
....instead of something like:
haystack -> find(needle);
To clean up the existing mess, many new functions need to
be created as member function of the appropriate objects -
and most of the old functions in the global namespace need
deprecating.
Does anyone think the existing mess will ever get cleaned up?
Or is PHP's function namespace too shafted at this stage to
ever be repaired?
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply. 88  5041 
"Tim Tyler" wrote: PHP puts most of its functions into a big flat global namespace.
That leads to short function names - but creates a namespace
minefield for programmers.
Lots of the functions are legacies from the days before PHP
got object-oriented features.
For instance we currently have:
strstr(haystack, needle)
....instead of something like:
haystack -> find(needle);
To clean up the existing mess, many new functions need to
be created as member function of the appropriate objects -
and most of the old functions in the global namespace need
deprecating.
Does anyone think the existing mess will ever get cleaned up?
Or is PHP’s function namespace too shafted at this stage to
ever be repaired?
I think you have a valid point. However, the old functions cannot
easily be retired due enormous legacy code base out there. So the
question then becomes, can we have two sets of functions.
-- http://www.dbForumz.com/ This article was posted by author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.dbForumz.com/PHP-global-n...ict145545.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbForumz.com/eform.php?p=487021
*** steve escribió/wrote (1 Sep 2004 16:02:51 -0400): I think you have a valid point. However, the old functions cannot
easily be retired due enormous legacy code base out there. So the
question then becomes, can we have two sets of functions.
I'm not sure of what the original poster meant. Should we replace...
$a=trim($b);
.... with...
$aux=new StringFunctions();
$a=$aux->trim($b);
:-?
--
--
-+ Álvaro G. Vicario - Burgos, Spain - ICQ 46788716
+- http://www.demogracia.com (la web de humor para mayores de 100 años)
++ «Sonríe, que te vamos a hacer una foto para la esquela»
--
I think you're talking crap. Just because other languages have namespaces
does not mean that PHP *must* have them as well. I have programmed for
several decades in a variety of languages that did not have namespaces, so I
have learned how to work without them. I suggest you do the same.
If you really *must* have a language that incorporates namespaces then go
and use one, but leave PHP alone.
I get pretty cheesed off when some geek says "I'm trying to learn PHP after
using language X, but I am finding it difficult because PHP does things
differently. Why can't it be more like X?"
I have groundbreaking news for all you geeks - PHP is not the same as
language X because IT IS DIFFERENT. If it was the same then there would be
no point. Different languages are different, so get used to the differences
and STOP COMPLAINING.
--
Tony Marston http://www.tonymarston.net
"Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... PHP puts most of its functions into a big flat global namespace.
That leads to short function names - but creates a namespace
minefield for programmers.
Lots of the functions are legacies from the days before PHP
got object-oriented features.
For instance we currently have:
strstr(haystack, needle)
...instead of something like:
haystack -> find(needle);
To clean up the existing mess, many new functions need to
be created as member function of the appropriate objects -
and most of the old functions in the global namespace need
deprecating.
Does anyone think the existing mess will ever get cleaned up?
Or is PHP's function namespace too shafted at this stage to
ever be repaired?
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
.oO(Tim Tyler) Lots of the functions are legacies from the days before PHP
got object-oriented features.
OOP is only an add-on, not a replacement for "legacy" functions.
For instance we currently have:
strstr(haystack, needle)
...instead of something like:
haystack -> find(needle);
Why to use OOP if it's not really necessary?
To clean up the existing mess,
What mess?
many new functions need to
be created as member function of the appropriate objects -
and most of the old functions in the global namespace need
deprecating.
Why? If you want to have objects all over use Java. PHP allows you to
write code with OOP or without, whatever you like.
Does anyone think the existing mess will ever get cleaned up?
Or is PHP's function namespace too shafted at this stage to
ever be repaired?
I have no problem with it (only little problem I have are the different
styles in function names, fooBar() vs. foo_bar()).
Micha
.oO(Alvaro G. Vicario) I'm not sure of what the original poster meant. Should we replace...
$a=trim($b);
... with...
$aux=new StringFunctions();
$a=$aux->trim($b);
Pfff ...
$aux = TypeHandlerFactory::createInstance('string');
$a->setValue($aux->trim($b->getValue()));
This is pretty simple and much more readable ...
SCNR
Micha
On Wed, 1 Sep 2004 18:54:04 GMT, Tim Tyler <ti*@tt1lock.org> wrote: PHP puts most of its functions into a big flat global namespace.
Lots of the functions are legacies from the days before PHP
got object-oriented features.
For instance we currently have:
strstr(haystack, needle)
...instead of something like:
haystack -> find(needle);
To clean up the existing mess, many new functions need to
be created as member function of the appropriate objects -
and most of the old functions in the global namespace need
deprecating.
Does anyone think the existing mess will ever get cleaned up?
Or is PHP's function namespace too shafted at this stage to
ever be repaired?
I agree that some form of namespacing would have really helped -
personally it's my biggest disappointment with php 5.
However, deprecating everything would shaft all the current non-OO
scripts. This would be a total disaster. I like the hybrid nature of
PHP as it stands.
I'd like to see *new* functions appear namespaced somehow, though, at
the moment you have no assurance of backwards compatibility at all,
since if I've named a function xml_do_something(), next release might
add a new extension with an identically named function.
I'm just hacked off that packages are about the only Java feature that
*didn't* make it in.
Michael Fesser <ne*****@gmx.net> wrote or quoted: .oO(Tim Tyler)
Lots of the functions are legacies from the days before PHP
got object-oriented features.
OOP is only an add-on, not a replacement for "legacy" functions.
For instance we currently have:
strstr(haystack, needle)
...instead of something like:
haystack -> find(needle);
Why to use OOP if it's not really necessary?
OOP is essential sometimes.
Why provide OOP features - and then fail to use the in your library
and instead litter it with procedural function calls?
No good reason. PHP is the way is is due to historical legacy -
not due to intelligent design.
To clean up the existing mess,
What mess?
As I originally described it, the existing approach
"creates a namespace minefield for programmers".
Functions should be classified into a heirarchcal tree, with
the braches of the tree represented by components in the fuction
names.
Creating a function taxonomy where everything comes directly off
the root creates a classification disaster - where nobody can find
anything - functions are not logically grouped - any anyone writing
their own function has to watch where they are stepping.
Consider what happens when a new version of PHP comes out with a
whole bunch of new fuctions - if they are in a big global namespace
and are free to clash with everyone else's fuctions.
many new functions need to be created as member function of the
appropriate objects - and most of the old functions in the global
namespace need deprecating.
Why? If you want to have objects all over use Java.
But Java is proprietary code - under a commerical license, and has
less server-side penetration that PHP, limiting the customer base.
PHP allows you to write code with OOP or without, whatever you like.
/With/, please - and /without/ the standard library dragging
everything into the procedural gutter, please. Does anyone think the existing mess will ever get cleaned up?
Or is PHP's function namespace too shafted at this stage to
ever be repaired?
I have no problem with it (only little problem I have are the different
styles in function names, fooBar() vs. foo_bar()).
Yes - an even more embarassing mess ;-)
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: I think you're talking crap. Just because other languages have namespaces
does not mean that PHP *must* have them as well.
PHP *already* has objects - which are good enough as namespaces for many
purposes.
What it doesn't have is a standard library that takes proper advantage
of its OO features.
I get pretty cheesed off when some geek says "I'm trying to learn PHP after
using language X, but I am finding it difficult because PHP does things
differently. Why can't it be more like X?"
I have groundbreaking news for all you geeks - PHP is not the same as
language X because IT IS DIFFERENT. If it was the same then there would be
no point. Different languages are different, so get used to the differences
and STOP COMPLAINING.
I'm pointing out a serious problem with PHP.
PHP should *benefit* from people pointing out its deficiencies.
If nobody complains, the designers get no feedback about where they
have screwed up the worst. They lack the information they need to
improve their product - and future architects wind up copying the
mistakes of existing systems, for the sake of factors like familiarity.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Alvaro G. Vicario <kA*****************@terra.es> wrote or quoted: I'm not sure of what the original poster meant. Should we replace...
$a=trim($b);
... with...
$aux=new StringFunctions();
$a=$aux->trim($b);
:-?
The conventional approach would be:
$a = $b -> trim();
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
steve <Us************@dbforumz.com> wrote or quoted: "Tim Tyler" wrote:
> PHP puts most of its functions into a big flat global namespace.
>
> That leads to short function names - but creates a namespace
> minefield for programmers.
[...]
> To clean up the existing mess, many new functions need to
> be created as member function of the appropriate objects -
> and most of the old functions in the global namespace need
> deprecating.
[...]
I think you have a valid point. However, the old functions cannot
easily be retired due enormous legacy code base out there. So the
question then becomes, can we have two sets of functions.
Presumably if it happens at all, it will happen because a libray
is built that does things sensibly, it gains a user base - and
eventually winds up getting bundled with PHP.
However, even then, the existing functions will no doubt stick
around for a /very/ long time, due to the legacy code issue.
PHP's designers are responsible. They released a system without
proper OO support, and then tried to "evolve" it.
As a result they got to the market in time to have a popular system -
but as a consequence, it's not a terribly pretty sight at the moment :-|
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Michael Fesser wrote: .oO(Alvaro G. Vicario)
I'm not sure of what the original poster meant. Should we replace...
$a=trim($b);
... with...
$aux=new StringFunctions();
$a=$aux->trim($b);
Pfff ...
$aux = TypeHandlerFactory::createInstance('string');
$a->setValue($aux->trim($b->getValue()));
This is pretty simple and much more readable ...
SCNR
Micha
yeah, I like how you needed a TypeFactory so you could access trim()
from the $aux type instance, you just infered that there were member
functions for $a and $b because they were already recognised types.
in which case you would be able to do
$a = $b->trim();
because $a = ... is the same as $a->setValue(...)
and
$a = "..."; is the same as
$a = new String("...");
And why wouldn't String has the trim() method?
So we're back to the one-liner :)
Anyway, to the original poster, this is all silly because you can't have
your cake and eat it too. The language neccesarily has to force strong
typing in order for it to make the above assumptions (about what type
variables are based on the operator being used - ie. the double quote).
Strong typing is boring :(
if you like strong typing, go use Java, C#, C++ or something like that.
See you when you get back from that little excursion ;)
------------ And now a word from our sponsor ----------------------
For a quality mail server, try SurgeMail, easy to install,
fast, efficient and reliable. Run a million users on a standard
PC running NT or Unix without running out of power, use the best!
---- See http://netwinsite.com/sponsor/sponsor_surgemail.htm ----
Tony Marston wrote: I think you're talking crap. Just because other languages have namespaces
does not mean that PHP *must* have them as well. I have programmed for
several decades in a variety of languages that did not have namespaces, so I
have learned how to work without them. I suggest you do the same.
If you really *must* have a language that incorporates namespaces then go
and use one, but leave PHP alone.
I get pretty cheesed off when some geek says "I'm trying to learn PHP after
using language X, but I am finding it difficult because PHP does things
differently. Why can't it be more like X?"
I have groundbreaking news for all you geeks - PHP is not the same as
language X because IT IS DIFFERENT. If it was the same then there would be
no point. Different languages are different, so get used to the differences
and STOP COMPLAINING.
Damn... I guess he's be told - well and trully <LOL> :D
Tim, I reckon it is a bit of a mess, but this is unavoidable. None the
less, I think you have a valid question. My response is, it is
unavoidable becuase the [so called] weakness in PHP's lack of typing/OO
is also it's major strength. The same laxity makes PHP increadibly
powerful and elgant in other situations. You don't have to write reams
of code to produce immediate results. You don't get "bogged down" on the
infrastructure of the language (which seems more like it was designed to
be generated from some high-level code-factory tool - not human beings
who want to craft productive code).
The clogging up of the global namespace is a small price to pay for a
language where you can do code like
$mixed = $this->$callBackFunction(new $objToBeHandled);
if($mixed === false)
die("doh!");
elseif(is_numeric($mixed))
return $mixed;
elseif(is_string($mixed))
$this->$mixed(new $objToBeHandled,$procCount++);
else
die($callBackFunction." returned an unsupported value.");
i'm sure there are better examples and lots of them.
Anyway, sometimes it's good to "de-normalise" the structure a bit - this
applies to everything including programming languages.
Adding a parallel set would in fact clutter things up even more.
PHP is an ugly beast but it is a powerful one. PHP is like the guy who
you call in to "get the job done" when you are under pressure and don't
have time to fuxk around :) (like the "cleaner" dude in Pulp Fiction).
------------ And now a word from our sponsor ------------------
Do your users want the best web-email gateway? Don't let your
customers drift off to free webmail services install your own
web gateway!
-- See http://netwinsite.com/sponsor/sponsor_webmail.htm ----
.oO(Terence) And why wouldn't String has the trim() method?
To trim it ... something like
<http://www.umluex.de/arschiv/umluex443/getStringFromObj.jpg> :-D
So we're back to the one-liner :)
A one-liner is unprofessional, it should be at least a four-liner with 2
class methods and 6 instances involved. Anything below is amateurish. ;)
Anyway, to the original poster, this is all silly because you can't have
your cake and eat it too. The language neccesarily has to force strong
typing in order for it to make the above assumptions (about what type
variables are based on the operator being used - ie. the double quote).
Strong typing is boring :(
Depends. I really appreciate it in other languages like Pascal/Delphi,
but don't want it in a scripting languages like PHP.
if you like strong typing, go use Java, C#, C++ or something like that.
See you when you get back from that little excursion ;)
Strong typing is necessary and very helpful in these languages. You
don't have that high level of abstraction like in a scripting language
and have to take care of much more things (memory issues for example).
Micha
"Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... Tony Marston <to**@nospam.demon.co.uk> wrote or quoted:
I think you're talking crap. Just because other languages have namespaces
does not mean that PHP *must* have them as well.
PHP *already* has objects - which are good enough as namespaces for many
purposes.
What it doesn't have is a standard library that takes proper advantage
of its OO features.
Define "standard library".What OO features are missing or unavailable? I get pretty cheesed off when some geek says "I'm trying to learn PHP
after
using language X, but I am finding it difficult because PHP does things
differently. Why can't it be more like X?"
I have groundbreaking news for all you geeks - PHP is not the same as
language X because IT IS DIFFERENT. If it was the same then there would
be
no point. Different languages are different, so get used to the
differences
and STOP COMPLAINING.
I'm pointing out a serious problem with PHP.
If PHP had serious problems it would not be the popular language it is
today. If any problems exist at all they are in your head.
--
Tony Marston http://www.tonymarston.net
"Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... steve <Us************@dbforumz.com> wrote or quoted: "Tim Tyler" wrote:
<snip>
PHP's designers are responsible. They released a system without
proper OO support, and then tried to "evolve" it.
As a result they got to the market in time to have a popular system -
but as a consequence, it's not a terribly pretty sight at the moment :-|
Well *I* like it. The fact that it is not a clone of Java.or C++ or whatever
is one of its strengths. If you are happier with the way that Java does
things then for God's sake stick to Java. If you don't like the way that PHP
does things then don't use it.
--
Tony Marston http://www.tonymarston.net
.oO(Tim Tyler) Michael Fesser <ne*****@gmx.net> wrote or quoted:
Why to use OOP if it's not really necessary?
OOP is essential sometimes.
True, _sometimes_. But sometimes != always. OOP is not always the
answer, it's more a question. The answer is: Depends.
While OOP really has its big advantages, OTOH it'll always cause an
overhead in loading the class definitions, instantiating them, calling
methods etc. The developer should be free to decide when OOP makes sense
and when not.
Why provide OOP features
Nice to have for people who want and know how to use them, but not a
necessity.
and then fail to use the in your library
and instead litter it with procedural function calls?
No good reason. PHP is the way is is due to historical legacy -
not due to intelligent design.
NACK. PHP is a scripting language, not a strongly typed language like
Delphi, C ...
What mess?
As I originally described it, the existing approach
"creates a namespace minefield for programmers".
Not for me. Actually, I don't see a real problem.
Functions should be classified into a heirarchcal tree, with
the braches of the tree represented by components in the fuction
names.
They are in a certain kind. Many "more advanced" functions contain the
name of the extension they're defined in, preg_*, simplexml_* etc.
Creating a function taxonomy where everything comes directly off
the root creates a classification disaster - where nobody can find
anything - functions are not logically grouped
Huh? They are. And I know where to look if I need a special function.
- any anyone writing
their own function has to watch where they are stepping.
This also happens in other languages, not every language has namespaces.
But you're free to develop your own code completely encapsulated in
classes to avoid name clashes.
Consider what happens when a new version of PHP comes out with a
whole bunch of new fuctions - if they are in a big global namespace
and are free to clash with everyone else's fuctions.
If it's a new extension 'foo' they will probably be named something like
foo_*. PHP allows you to write code with OOP or without, whatever you like.
/With/, please - and /without/ the standard library dragging
everything into the procedural gutter, please.
Why do you wanna force everyone to use OOP in a _scripting_ language?
I really like the current situation - I can write small and fast
procedural scripts or more complex applications with OOP if I like. It's
my choice (and the reason why I don't really like Java for example).
Micha
Tony Marston <to**@nospam.demon.co.uk> wrote: I have groundbreaking news for all you geeks - PHP is not the same as
language X because IT IS DIFFERENT. If it was the same then there would
be
no point. Different languages are different, so get used to the
differences
and STOP COMPLAINING.
I'm pointing out a serious problem with PHP.
If PHP had serious problems it would not be the popular language it is
today. If any problems exist at all they are in your head.
While PHP doens't need a namespace, its functions are a _mess_
Examples:
-str_split() vs parse_str()
The latter obviously should be str_parse()
-str* vs. str_*
Lets make up our minds an use uniform function names please.
-strchr() is an alias for strstr(), strrchr() is not an alias for
strrstr() (which doesn't even exist).
-string strchr(string haystack, string needle)
shouldn't that be char needle?
-strpos vs strrpos
int strpos(string haystack, string needel [,int offset]):
this function can take a full string as the needle parameter and the
entire string will be used.
int strrpos ( string haystack, string needle [, int offset]):
If a string is passed as the needle, then only the first character
of that string will be used
So strrpos not only works differently, it's prototype should be
int strrpos ( string haystack, char needle [, int offset])
All exmaples above use the haystack-needle form, others use
needle-haystack order (like array_key_exists).
It appears you are blind to these faults or are just used to it! Maybe
you are using some piece of software to correct there errors for you?
--
Daniel Tryba
Tim Tyler <ti*@tt1lock.org> wrote in message
news:<I3********@bath.ac.uk>...
PHP puts most of its functions into a big flat global namespace.
That leads to short function names - but creates a namespace
minefield for programmers.
Lots of the functions are legacies from the days before PHP
got object-oriented features.
Personally, I think of object-oriented features in PHP as a necessary
evil. They are by no means required for writing quality software; the
only purpose they serve is to provide interfaces to technologies that
are too self-absorbed and unaware of the outside world to accept
procedure calls (COM and Java would be prime examples).
For instance we currently have:
strstr(haystack, needle)
...instead of something like:
haystack -> find(needle);
To clean up the existing mess,
I believe that what you are proposing is a much bigger mess.
In strstr($haystack, $needle), $haystack is a string. In
$haystack->find($needle), $haystack is an object that needs
to be instantiated and populated. Extra lines of code, extra
memory allocation, extra processor ticks... Why even bother?
Your proposal is eerily reminiscent of the hoax interview
with Bjorne Stroustrup, who, according to that hoax interview,
invented C++ so that programmers' performance could go down
the toilet, so that employers hire more programmers to make
the deadlines.
many new functions need to be created as member function
of the appropriate objects
The only appropriate objects in PHP are the ones that provide
interfaces to COM, Java, etc. The rest (including database
abstraction layers) are, in my opinion, inappropriate, because
they provide no additional functionality while adversely
impacting performance.
Or is PHP's function namespace too shafted at this stage to
ever be repaired?
Why even attempt to repair what appears to be working?
Cheers,
NC
Tim Oliver <ti*@xi.co.nz> wrote or quoted: I'm just hacked off that packages are about the only Java feature that
*didn't* make it in.
Packages in Java ara a disaster as well. The problem is that you
can't nest them.
You might think java.lang.Object was in a package called lang inside
another package called "java" - but it isn't.
There's only a single global pacakge namespace - and that's a package
called "java.lang" in it :-(
It's the same problem as PHP has - in other words - just two levels
further up - where it doesn't matter anything like as much.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: "Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... Tony Marston <to**@nospam.demon.co.uk> wrote or quoted:
I think you're talking crap. Just because other languages have namespaces
does not mean that PHP *must* have them as well.
PHP *already* has objects - which are good enough as namespaces for many
purposes.
What it doesn't have is a standard library that takes proper advantage
of its OO features.
Define "standard library".
I mean the library of functions that comes with PHP.
What OO features are missing or unavailable?
That's not what I said.
The standard library fails on the encapsulation front - by making
all its methods public, and in the global namespace.
It also consequently fails to take advantage of inheritance and
polymorphism - but that's not what I was mostly complaining about.
I'm pointing out a serious problem with PHP.
If PHP had serious problems it would not be the popular language it is
today. [...]
Do you have the same view about Microsoft Windows?
If any problems exist at all they are in your head.
Thanks for the remote diganosis over the internet, Dr Tony.
How much do I owe you for that one? ;-)
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Terence <tk******@fastmail.fm> wrote or quoted: Tim, I reckon it is a bit of a mess, but this is unavoidable.
Surely not so!
None the less, I think you have a valid question. My response is, it is
unavoidable becuase the [so called] weakness in PHP's lack of typing/OO
is also it's major strength.
It is not clear what you are talking about.
The issue of pollution of a global namespace has nothing to do with
dynamic typing.
The clogging up of the global namespace is a small price to pay for a
language where you can do code like
$mixed = $this->$callBackFunction(new $objToBeHandled);
if($mixed === false)
die("doh!");
elseif(is_numeric($mixed))
return $mixed;
elseif(is_string($mixed))
$this->$mixed(new $objToBeHandled,$procCount++);
else
die($callBackFunction." returned an unsupported value.");
You appear to have got my argument muddled up somehow. I'm *not* arguing
that dynamic typing is bad. I'm arguing that stuffing all the functions
into a global namespace is a problem that badly needs addressing.
That issue is orthogonal to whether a language is statically or
dynamically typed.
Anyway, sometimes it's good to "de-normalise" the structure a bit - this
applies to everything including programming languages.
Adding a parallel set would in fact clutter things up even more.
Indeed - but it's about the only way to evolve out of the current
mess - without discarding it and starting again.
If PHP doesn't do it, it's eventually likely to be replaced by
something which isn't in quite such a mess.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
"Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: "Tim Tyler" <ti*@tt1lock.org> wrote in message
news:I3********@bath.ac.uk... > Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: >> I think you're talking crap. Just because other languages have
>> namespaces
>> does not mean that PHP *must* have them as well.
>
> PHP *already* has objects - which are good enough as namespaces for
> many
> purposes.
>
> What it doesn't have is a standard library that takes proper advantage
> of its OO features.
Define "standard library".
I mean the library of functions that comes with PHP.
What's wrong with http://www.php.net/manual/en/funcref.php ?
What OO features are missing or unavailable?
That's not what I said.
OK then. EWhy should all the functions be OO? What's the advantage?
The standard library fails on the encapsulation front - by making
all its methods public, and in the global namespace.
So what's wrong with that? If the function names aren't public how are you
supposed to access them?
It also consequently fails to take advantage of inheritance and
polymorphism - but that's not what I was mostly complaining about.
The standard PHP functions do not have to take advantage of inheritance and
polymorphism to work, therefore your argument has no merit. > I'm pointing out a serious problem with PHP.
If PHP had serious problems it would not be the popular language it is
today. [...]
Do you have the same view about Microsoft Windows?
Yes. It meets all the criteria of a virus. If any problems exist at all they are in your head.
Thanks for the remote diganosis over the internet, Dr Tony.
How much do I owe you for that one? ;-)
You can have that one for free. Just stop saying that PHP has serious flaws
because it is not totally OO. It is possible to write perfectly good
programs without using OO, and it is possible to use OO and write crap. The
functions in PHP work perfectly well as they are, and making them all OO
would not give any improvement.
--
Tony Marston http://www.tonymarston.net
"Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... Terence <tk******@fastmail.fm> wrote or quoted:
Tim, I reckon it is a bit of a mess, but this is unavoidable.
Surely not so!
None the less, I think you have a valid question. My response is, it is
unavoidable becuase the [so called] weakness in PHP's lack of typing/OO
is also it's major strength.
It is not clear what you are talking about.
The issue of pollution of a global namespace has nothing to do with
dynamic typing.
The clogging up of the global namespace is a small price to pay for a
language where you can do code like
$mixed = $this->$callBackFunction(new $objToBeHandled);
if($mixed === false)
die("doh!");
elseif(is_numeric($mixed))
return $mixed;
elseif(is_string($mixed))
$this->$mixed(new $objToBeHandled,$procCount++);
else
die($callBackFunction." returned an unsupported value.");
You appear to have got my argument muddled up somehow. I'm *not* arguing
that dynamic typing is bad. I'm arguing that stuffing all the functions
into a global namespace is a problem that badly needs addressing.
It is not a problem at all, except in your head. There are zillions of PHP
scripts out there which work perfectly well with non-OO functions, but they
wouldn't work if the problem were real.
Tony Marston
That issue is orthogonal to whether a language is statically or
dynamically typed.
Anyway, sometimes it's good to "de-normalise" the structure a bit - this
applies to everything including programming languages.
Adding a parallel set would in fact clutter things up even more.
Indeed - but it's about the only way to evolve out of the current
mess - without discarding it and starting again.
If PHP doesn't do it, it's eventually likely to be replaced by
something which isn't in quite such a mess.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: "Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: "Tim Tyler" <ti*@tt1lock.org> wrote in message
news:I3********@bath.ac.uk...
> Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: >> I think you're talking crap. Just because other languages have
>> namespaces
>> does not mean that PHP *must* have them as well.
>
> PHP *already* has objects - which are good enough as namespaces for
> many
> purposes.
>
> What it doesn't have is a standard library that takes proper advantage
> of its OO features.
Define "standard library".
I mean the library of functions that comes with PHP.
What's wrong with http://www.php.net/manual/en/funcref.php ?
The particular page is not what I'm complaining about. It's
PHP's global functions that are the problem - and I've already
stated why I think a single big function namespace is a bad idea.
What OO features are missing or unavailable?
That's not what I said.
OK then. EWhy should all the functions be OO? What's the advantage?
The usual ones: abstraction; encapsulation; polymorphism; inheritance.
The standard library fails on the encapsulation front - by making
all its methods public, and in the global namespace.
So what's wrong with that? If the function names aren't public how are you
supposed to access them?
You're not. The problem is everything being in a big global namespace.
Surely that's in programmer's 101 as a bad move by now. Defending the
idea makes no sense to me at all. PHP is not some sort of Holy object -
which you need to sacrifice all existing common sense about language
design to protect. Single big global namespaces are well out fashion
these days - and if you think they are in vogue, you need to WAKE UP.
It also consequently fails to take advantage of inheritance and
polymorphism - but that's not what I was mostly complaining about.
The standard PHP functions do not have to take advantage of inheritance and
polymorphism to work, therefore your argument has no merit.
Noboby *needs* to write programs in high level languages either.
But what is /necessary/ and what is /desirable/ are not the same thing.
> I'm pointing out a serious problem with PHP.
If PHP had serious problems it would not be the popular language it is
today. [...]
Do you have the same view about Microsoft Windows?
Yes. It meets all the criteria of a virus.
So, to clarify: do you think it has serious problems?
Or are you arguing it can't possibly have any serious problems - because
it seems to be doing so well?
If any problems exist at all they are in your head.
Thanks for the remote diganosis over the internet, Dr Tony.
How much do I owe you for that one? ;-)
You can have that one for free. [...]
Very gracious ;-)
Just stop saying that PHP has serious flaws because it is not totally OO.
A bit of a paraphrase, there:
I'm not complaining about PHP the language.
My beef here is with PHP's library - and how out-of-date and backwards it
looks.
The functions in PHP work perfectly well as they are, and making them
all OO would not give any improvement.
We don't agree on that point - and I'm /very/ suprised to find people
defending the design as though it makes sense.
PHP's function library is a historical legacy - the product of days
gone by when PHP had no OO features at all - and that we now seem
to be rather stuck with.
Don't kid yourself into thinking any half-intelligent person would
actually *design* that sort of mess deliberately. It should be
obvious that only a fool would make such a mess /deliberately/.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Michael Fesser <ne*****@gmx.net> wrote or quoted: .oO(Tim Tyler)Michael Fesser <ne*****@gmx.net> wrote or quoted:
Why to use OOP if it's not really necessary?
OOP is essential sometimes.
True, _sometimes_. But sometimes != always. OOP is not always the
answer, it's more a question. The answer is: Depends.
While OOP really has its big advantages, OTOH it'll always cause an
overhead in loading the class definitions, instantiating them, calling
methods etc. [...]
Why? This is basically the fallacy that JIT compliers have pretty
conclusively disproved. There's no performance overhead to being OO -
since the runtime can analyse the program convert it into whatever
equivalent form it likes - and then cache the results if necessary.
and then fail to use the in your library
and instead litter it with procedural function calls?
No good reason. PHP is the way is is due to historical legacy -
not due to intelligent design.
NACK. PHP is a scripting language, not a strongly typed language like
Delphi, C ...
Why all these mention of strong typing? The issue at hand has nothing
to do with how the language is typed.
Functions should be classified into a heirarchcal tree, with
the braches of the tree represented by components in the fuction
names.
They are in a certain kind. Many "more advanced" functions contain the
name of the extension they're defined in, preg_*, simplexml_* etc.
You realise - I suppose - that that's a dreadful hack to get around the
lack of namespaces?
Ask youself whether you can have variables and methods which are visible
within "preg_*" and not outside it - and you should immediately see what
is wrong with this hack.
It fails to offer any encapsulation. In other words, it sucks.
Creating a function taxonomy where everything comes directly off
the root creates a classification disaster - where nobody can find
anything - functions are not logically grouped
Huh? They are.
Not syntactically, they aren't - and function naming conventions
to work around the problem are a crude hack - as I explain above.
This also happens in other languages, not every language has namespaces.
But you're free to develop your own code completely encapsulated in
classes to avoid name clashes.
Yes - and everyone should do this - and the authors of PHP should be
setting a good example - not illustrating to everyone how not to program. PHP allows you to write code with OOP or without, whatever you like.
/With/, please - and /without/ the standard library dragging
everything into the procedural gutter, please.
Why do you wanna force everyone to use OOP in a _scripting_ language?
Being a scripting language doesn't mean you have to suck.
Many other scripting languages manage to avoid the problem I'm describing
here - and are better off as a result.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Tim Tyler wrote: Many other scripting languages manage to avoid the problem I'm describing
here - and are better off as a result.
So why don't you go use those scripting languages instead if they suit your
needs better? I've always believed you should use the tools you think are
best for the job, and clearly you have major problems with PHP (both in
this thread and the one about error messages) so I don't see how you can
think PHP is the best tool for the job. Go use a language that better suits
what you want out of it.
Chris Hope <bl*******@electrictoolbox.com> wrote or quoted: Tim Tyler wrote:
Many other scripting languages manage to avoid the problem I'm describing
here - and are better off as a result.
So why don't you go use those scripting languages instead if they suit your
needs better?
Because your premise is wrong - they don't suit my needs better - and
I never suggested that they did. They do benefit from not having the
problem I'm talking about, though.
I've always believed you should use the tools you think are best for
the job, and clearly you have major problems with PHP (both in this
thread and the one about error messages) so I don't see how you can
think PHP is the best tool for the job.
Maybe the fact that you have no idea what my job is has something to
do with that.
I /like/ PHP - but I do wish it wasn't full of such godawful embarassing
hacks.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
On Thu, 02 Sep 2004 17:20:53 +0000, Tim Tyler wrote: Tim Oliver <ti*@xi.co.nz> wrote or quoted:
I'm just hacked off that packages are about the only Java feature that
*didn't* make it in.
Packages in Java ara a disaster as well. The problem is that you can't
nest them.
You might think java.lang.Object was in a package called lang inside
another package called "java" - but it isn't.
There's only a single global pacakge namespace - and that's a package
called "java.lang" in it :-(
It's the same problem as PHP has - in other words - just two levels
further up - where it doesn't matter anything like as much.
Quite true. I wish that PHP had the package concept used in Perl. There,
Math::Roman is a package named Roman within a package named Math within
the the global namespace ("main").
La'ie Techie
On Wed, 01 Sep 2004 23:05:37 +0200, Michael Fesser wrote: Why? If you want to have objects all over use Java. PHP allows you to
write code with OOP or without, whatever you like.
Nested namespaces don't have to be tied to OOP. Even the PEAR library
uses nested folders to avoid conflicts. We should take it to the next
logical step: packages.
La'ie Techie
Tim Tyler wrote: I like PHP - but I do wish it wasn't full of such godawful embarassing
hacks.
You do know that they rewrote the object model in PHP5, don't you? While
this doesn't address the issue of namespaces (which I wish they'd added) or
the unfortunate problem where there is little standardisation of function
naming or order of parameters, it does show that they have addressed some
of the issues with OOP.
The main problem with trying to fix PHP in respect to the issues you have
pointed out in your many posts, is that they need to maintain backward
compatibility. OK, so maybe they don't, but it makes it very hard to move
developers/hosting providers/etc onto a Brand New Version of PHP which
isn't backward compatible, even though it might address all the issues
brought about because of the way PHP has evolved. It'll take long enough
for everyone to move to v5, let alone to a new version which throws all the
existing function names and syntax out the window, and breaks all existing
legacy systems.
I like PHP because it is both procedural and object oriented. I like that it
gives me this flexibility and use a combination of both in my projects. It
would have been nice if there *were* namespaces, but I have no problem
prefixing my functions with eg foo_ to ensure they don't clash with other
function names.
--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/
Tim Tyler wrote: Terence <tk******@fastmail.fm> wrote or quoted:
Tim, I reckon it is a bit of a mess, but this is unavoidable.
Surely not so!
None the less, I think you have a valid question. My response is, it is
unavoidable becuase the [so called] weakness in PHP's lack of typing/OO
is also it's major strength.
It is not clear what you are talking about.
The issue of pollution of a global namespace has nothing to do with
dynamic typing.
You do if you want to organise your methods into classes so you can do
things like
$a = " some string ";
$b = $a->trim();
in order for this to work, $a will have to be automatically cast as a
string due to the " operator. You couldn't just start using numeric
methods on $a because then you're back to name collisions.
Tim Tyler wrote:
The conventional approach would be:
$a = $b -> trim();
I have to agree with you Daniel, I also think they are a mess even if we
ignored the existance of OO.
I do think there could have been more foresight from the beginning and I
think the evolution has been irrisponsible. This doesn't outweigh the
benefits of PHP for me but it is annoying. However, due to the huge
codebase out there, I don't know that this can be fixed without breaking
too much stuff and pissing of thousands of people. However, I do think
they should have fixed it with v5 (along with abandoning short open tags
so people can make XML based PHP templates).
Having said that, let me suggest what might have been a bette way to go.
modules stick to a strict designated prefix such as
sax_
str_
pg_
my_
fi_
rgx_
some modules already do this but it is not strictly adhered to.
Then I reckon the rest of the names should use the camel hump convention
like
fi_Open(); // as opposed to fopen()
fi_DirName(); // as opposed to just dirname()
arr_IsIn(); // as opposed to in_array()
I think this would help, and it is quite readable
On the face of it, some people might think that mixing the underscore
and the camel hump convention is appalling, but it's not worse than
having the exisitng PHP underscore convention mixed with camel hump when
trying to avoid said name collisions by implementing camel hump for
user-defined functions/methods. At least this way there is some method
to the madness.
In any case, if you go look at standards specs like the document object
model (DOM) at the W3C, the specify camel hump - so when you go back to
the PHP implementation, it's all broken (they fixed this in v5 I think).
Making everyone use OO conventions is not the answer. OO has always been
an "optional extra" with PHP and that's the way it ought to stay. It is
part of the reason why there is such a huge uptake people. It's more
accessible this way, and procedural programmers feel comfortable with it.
Daniel Tryba wrote: Tony Marston <to**@nospam.demon.co.uk> wrote:
I have groundbreaking news for all you geeks - PHP is not the same as
language X because IT IS DIFFERENT. If it was the same then there would
be
no point. Different languages are different, so get used to the
differences
and STOP COMPLAINING.
I'm pointing out a serious problem with PHP.
If PHP had serious problems it would not be the popular language it is
today. If any problems exist at all they are in your head.
While PHP doens't need a namespace, its functions are a _mess_
Examples:
-str_split() vs parse_str()
The latter obviously should be str_parse()
-str* vs. str_*
Lets make up our minds an use uniform function names please.
-strchr() is an alias for strstr(), strrchr() is not an alias for
strrstr() (which doesn't even exist).
-string strchr(string haystack, string needle)
shouldn't that be char needle?
-strpos vs strrpos
int strpos(string haystack, string needel [,int offset]):
this function can take a full string as the needle parameter and the
entire string will be used.
int strrpos ( string haystack, string needle [, int offset]):
If a string is passed as the needle, then only the first character
of that string will be used
So strrpos not only works differently, it's prototype should be
int strrpos ( string haystack, char needle [, int offset])
All exmaples above use the haystack-needle form, others use
needle-haystack order (like array_key_exists).
It appears you are blind to these faults or are just used to it! Maybe
you are using some piece of software to correct there errors for you?
Chris Hope <bl*******@electrictoolbox.com> wrote or quoted: Tim Tyler wrote:
The main problem with trying to fix PHP in respect to the issues you have
pointed out in your many posts, is that they need to maintain backward
compatibility. OK, so maybe they don't, but it makes it very hard to move
developers/hosting providers/etc onto a Brand New Version of PHP which
isn't backward compatible, even though it might address all the issues
brought about because of the way PHP has evolved. It'll take long enough
for everyone to move to v5, let alone to a new version which throws all the
existing function names and syntax out the window, and breaks all existing
legacy systems.
My proposal (in the first post of this thread) described what would be
needed to clean things up without breaking legacy systems:
``To clean up the existing mess, many new functions need to
be created as member function of the appropriate objects -
and most of the old functions in the global namespace need
deprecating.''
Deprecating functions doesn't break anything - since all the old
functions are still there and they still work just as before - the
only difference is that they generate deprecation warnings if you
set a flag when parsing the page.
This doesn't clean things up immediately - but it does allow a
clean-up to be performed in the future.
IMO, if a clean-up is attemped it is most likely to initially take
the form of third party libraries - intended for "real progammers",
who are not happy with the existing situation - and want a decent
set of library routines for PHP.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Tim Tyler wrote: Chris Hope <bl*******@electrictoolbox.com> wrote or quoted: Tim Tyler wrote:
The main problem with trying to fix PHP in respect to the issues you have
pointed out in your many posts, is that they need to maintain backward
compatibility. OK, so maybe they don't, but it makes it very hard to move
developers/hosting providers/etc onto a Brand New Version of PHP which
isn't backward compatible, even though it might address all the issues
brought about because of the way PHP has evolved. It'll take long enough
for everyone to move to v5, let alone to a new version which throws all
the existing function names and syntax out the window, and breaks all
existing legacy systems.
My proposal (in the first post of this thread) described what would be
needed to clean things up without breaking legacy systems:
``To clean up the existing mess, many new functions need to
be created as member function of the appropriate objects -
and most of the old functions in the global namespace need
deprecating.''
Deprecating functions doesn't break anything - since all the old
functions are still there and they still work just as before - the
only difference is that they generate deprecation warnings if you
set a flag when parsing the page.
This doesn't clean things up immediately - but it does allow a
clean-up to be performed in the future.
IMO, if a clean-up is attemped it is most likely to initially take
the form of third party libraries - intended for "real progammers",
who are not happy with the existing situation - and want a decent
set of library routines for PHP.
That would work quite nicely. It's pretty much what they've done with the
rework of OOP in v5, as most of the new stuff should still work in v4,
although I haven't looked too much into it yet. Waiting for another few
minor releases first before I think about starting to use it...
--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/
Terence <tk******@fastmail.fm> wrote or quoted: Tim Tyler wrote: Terence <tk******@fastmail.fm> wrote or quoted:
Tim, I reckon it is a bit of a mess, but this is unavoidable.
Surely not so!
None the less, I think you have a valid question. My response is, it is
unavoidable becuase the [so called] weakness in PHP's lack of typing/OO
is also it's major strength.
It is not clear what you are talking about.
The issue of pollution of a global namespace has nothing to do with
dynamic typing.
You do if you want to organise your methods into classes so you can do
things like
$a = " some string ";
$b = $a->trim();
in order for this to work, $a will have to be automatically cast as a
string due to the " operator. You couldn't just start using numeric
methods on $a because then you're back to name collisions.
Using numeric methods on strings is /usually/ a bad idea - and
while automatic type-casting saves you some keystrokes, it
loses you a /lot/ in terms of type safety - and is consequently
a source of many bugs.
I think:
$a = "98.6";
$b = $a->floor();
....should fail with an "unknown method" error - and would suggest using:
$a = "98.6";
$b = $a->number()->floor();
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Fri, 03 Sep 2004 13:13:01 +1200, na comp.lang.php, Chris Hope napisa³(a): I like PHP because it is both procedural and object oriented. I like that it
gives me this flexibility and use a combination of both in my projects. It
would have been nice if there *were* namespaces, but I have no problem
prefixing my functions with eg foo_ to ensure they don't clash with other
function names.
I agree with Tim, and I would like to add my 10 cents. The language
without namespaces and packages scales worse. It is a pity that php
developers looked at Java instead of much better, easier and elegant
designed Python. Python is also a dynamic language, but has many features
much powerfull than PHP5. Python has namespaces, packages, automatic
bytecode generation of imported modules, documentation string feature
builed in language etc. Copying some feature of Python to PHP would be more
usefull than choosen Java features.
--
JZ
"Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: "Tim Tyler" <ti*@tt1lock.org> wrote in message
news:I3********@bath.ac.uk... > Tony Marston <to**@nospam.demon.co.uk> wrote or quoted:
>> "Tim Tyler" <ti*@tt1lock.org> wrote in message
>> news:I3********@bath.ac.uk...
>> > Tony Marston <to**@nospam.demon.co.uk> wrote or quoted:
>
>> >> I think you're talking crap. Just because other languages have
>> >> namespaces
>> >> does not mean that PHP *must* have them as well.
>> >
>> > PHP *already* has objects - which are good enough as namespaces for
>> > many
>> > purposes.
>> >
>> > What it doesn't have is a standard library that takes proper
>> > advantage
>> > of its OO features.
>>
>> Define "standard library".
>
> I mean the library of functions that comes with PHP.
What's wrong with http://www.php.net/manual/en/funcref.php ?
The particular page is not what I'm complaining about. It's
PHP's global functions that are the problem - and I've already
stated why I think a single big function namespace is a bad idea.
Global fuctions are not a problem except for you.
>> What OO features are missing or unavailable?
>
> That's not what I said.
OK then. EWhy should all the functions be OO? What's the advantage?
The usual ones: abstraction; encapsulation; polymorphism; inheritance.
PHP functions do not need all that bloat to work, so again I say "it is not
a problem".
> The standard library fails on the encapsulation front - by making
> all its methods public, and in the global namespace.
So what's wrong with that? If the function names aren't public how are
you
supposed to access them?
You're not. The problem is everything being in a big global namespace.
Again I say "that is not a problem" - except to you.
Surely that's in programmer's 101 as a bad move by now.
Just because *some* programmers think it is bad does not mean that *all*
programmers think it is bad. What is chalk to some is cheese to others. If
you don't like PHP so much then stop using it.
Defending the
idea makes no sense to me at all. PHP is not some sort of Holy object -
which you need to sacrifice all existing common sense about language
design to protect. Single big global namespaces are well out fashion
these days - and if you think they are in vogue, you need to WAKE UP.
Being fashionable is not a good reason to change the way an entire language
works. many many developers are happy with the way PHP works and would be
very unhappy if it were change to suit your personal preferences.
> It also consequently fails to take advantage of inheritance and
> polymorphism - but that's not what I was mostly complaining about.
The standard PHP functions do not have to take advantage of inheritance
and
polymorphism to work, therefore your argument has no merit.
Noboby *needs* to write programs in high level languages either.
But what is /necessary/ and what is /desirable/ are not the same thing.
Exactly. It is not *necessary* for the standard PHP functions to be objected
oriented. There would be no performance improvement to outwiegh the cost, so
a cost/benefit analysis would shoot the whole idea down in flames.
>> > I'm pointing out a serious problem with PHP.
>>
>> If PHP had serious problems it would not be the popular language it is
>> today. [...]
>
> Do you have the same view about Microsoft Windows?
Yes. It meets all the criteria of a virus.
So, to clarify: do you think it has serious problems?
Ask the users whose PC's keep crashing. Ask the user's who find that the XP
SP2 upgrade doesn't install. Ask the users who have installed XP SP2 only to
find that some of their other applications no longer work.
Or are you arguing it can't possibly have any serious problems - because
it seems to be doing so well?
MS does so well because they have crushed all competition. If there was a
viable alternative to Windows then users would switch in droves. Look at how
many Linux servers are in use now. Why? Because they are cheaper and more
reliable than Windows.
>> If any problems exist at all they are in your head.
>
> Thanks for the remote diganosis over the internet, Dr Tony.
>
> How much do I owe you for that one? ;-)
You can have that one for free. [...]
Very gracious ;-)
Just stop saying that PHP has serious flaws because it is not totally OO.
A bit of a paraphrase, there:
I'm not complaining about PHP the language.
My beef here is with PHP's library - and how out-of-date and backwards it
looks.
No language can survive if it keeps changing every year or so just to be
fashionable. It has to be consistent and provide backwards compatibility
otherwise developers would not switch to later versions.
The functions in PHP work perfectly well as they are, and making them
all OO would not give any improvement.
We don't agree on that point - and I'm /very/ suprised to find people
defending the design as though it makes sense.
What improvement could I expect if PHP's functions were changed from
procedural to OO?
PHP's function library is a historical legacy - the product of days
gone by when PHP had no OO features at all - and that we now seem
to be rather stuck with.
All languages evolve. The fact that OOP was not in the original design does
not matter a jot. It made an apearance in PHP 4 and has been improved in PHP
5. I like the fact that I can use procedural code when I want to and OO code
when I want to. I am not forced into one or the other, so I can mix and
match to my heart's content. How many other languages give you that option?
Don't kid yourself into thinking any half-intelligent person would
actually *design* that sort of mess deliberately. It should be
obvious that only a fool would make such a mess /deliberately/.
Nobody can get it right first time. Every language evolves. Additions have
been made to PHP nbecause they have been requested by the user community and
have been perceived to be of benefit. The changes that you propose would be
costly to implement, would give no benefit, and would alienate the vast
majority of the current user base.
You are entitled to your opinion, but IMHO your opinion sucks.
--
Tony Marston http://www.tonymarston.net
Terence wrote: I do think there could have been more foresight from the beginning
and I think the evolution has been irrisponsible. This doesn't
outweigh the benefits of PHP for me but it is annoying. However, due
to the huge codebase out there, I don't know that this can be fixed
without breaking too much stuff and pissing of thousands of people.
However, I do think they should have fixed it with v5 (along with
abandoning short open tags so people can make XML based PHP
templates).
I am actually re-writing a huge application which I evolved from a very
small one. If you ever did that you know how many inconsistencies arise when
a small thing grows bigger. You have two choices: either you go on with the
inconsistencies and put your focus on backwards compatibility, or you
abandon backwards compatibility and make things consistent.
It is absolutely impossible to change any function from function(string
needle, string haystack) to function(string haystack, string needle) without
totally abandoning backwards compatibility. What you could do of course was:
- write your own scripting language similar to PHP but with all the things
you don't like fixed, and distribute it as open source software (I don't
think that's worth the effort)
- create your own function library as a layer on PHP and rewrite the
functions you need often, such as
function newfunc_array_key_exists($haystack, $needle)
{
return array_key_exists($needle, $haystack);
}
From my point of view as an experienced PHP user (without great knowledge of
other languages) it is highly responsible to keep the focus on backwards
compatibility rather than on consistency or even similarity to other
languages.
--
Markus
.oO(JZ) I agree with Tim, and I would like to add my 10 cents. The language
without namespaces and packages scales worse.
There are more encapsulation mechanismns than just namespaces. Is a
language bad just because it doesn't support a certain feature of
another? If you can't live without namespaces then use a language that
provides them.
Python is also a dynamic language, but has many features
much powerfull than PHP5.
Who cares? Python != PHP.
Python has namespaces, packages, automatic
bytecode generation of imported modules, documentation string feature
builed in language etc. Copying some feature of Python to PHP would be more
usefull than choosen Java features.
Why to copy all features of another language? Just switching to that
language would be much easier.
Micha
.oO(Tim Tyler) Michael Fesser <ne*****@gmx.net> wrote or quoted:
While OOP really has its big advantages, OTOH it'll always cause an
overhead in loading the class definitions, instantiating them, calling
methods etc. [...]
Why? This is basically the fallacy that JIT compliers have pretty
conclusively disproved. There's no performance overhead to being OO -
since the runtime can analyse the program convert it into whatever
equivalent form it likes - and then cache the results if necessary.
JIT compiling also takes time. And if the compiler can't optimize it a
call of an object's method will be slower than a direct procedure call
in many cases (program has to look up the entry point in one or more
VMTs or something like that). The overhead may increase in interpreted
languages.
You realise - I suppose - that that's a dreadful hack to get around the
lack of namespaces?
Not really, I consider it just a naming convention, not a hack.
Ask youself whether you can have variables and methods which are visible
within "preg_*" and not outside it - and you should immediately see what
is wrong with this hack.
Until today I've _never_ really needed namespaces, maybe because I
always used languages that don't support them explicitly. Same goes for
C++ templates for example, nice to have IMHO, but I don't really need
them (and if I would I would simply use C++ instead of my preferred
language and not complain about a missing feature)
All these techniques and mechanismns are just tools, nothing more. A
language isn't bad per-se just because it doesn't support them all.
It fails to offer any encapsulation. In other words, it sucks.
Classes exist. And if it sucks - why do you use it? There are thousands
of other programming languages out there.
This also happens in other languages, not every language has namespaces.
But you're free to develop your own code completely encapsulated in
classes to avoid name clashes.
Yes - and everyone should do this - and the authors of PHP should be
setting a good example - not illustrating to everyone how not to program.
So when writing shell scripts I should include some namespaces, maybe
instantiate this or that class first instead of just writing what I
wanna do?
Why do you wanna force everyone to use OOP in a _scripting_ language?
Being a scripting language doesn't mean you have to suck.
PHP doesn't suck for me (at least not for this reason).
Many other scripting languages manage to avoid the problem I'm describing
here - and are better off as a result.
Then use them and stop complaining about PHP not beeing like them.
Micha
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote:
Being fashionable is not a good reason to change the way an entire language
works. many many developers are happy with the way PHP works and would be
very unhappy if it were change to suit your personal preferences.
I understand that you have your very strong biases, but your first
statement here is not entirely correct. "Fashionable" language constructs
evolve for a reason: increased expressiveness, better readability, fewer
mistakes, better upgrade path in the future, and so on.
Very often, "being fashionable" is an EXCELLENT reason to change the way an
entire language works. Fortran-90 doesn't look an awful lot like
Fortran-77. Sure, it made many developers unhappy, but the result was a
language that encouraged much more maintainable programs.
Many of the suggestions in this thread fall into this category. You don't
make changes just because you can make changes, but if a change makes it
easier to write programs with fewer bugs, then it's a change that is worth
a fair amount of consideration, even if it breaks a few legacy apps.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
"Tim Roberts" <ti**@probo.com> wrote in message
news:hv********************************@4ax.com... "Tony Marston" <to**@NOSPAM.demon.co.uk> wrote:
Being fashionable is not a good reason to change the way an entire
language
works. many many developers are happy with the way PHP works and would be
very unhappy if it were change to suit your personal preferences.
I understand that you have your very strong biases, but your first
statement here is not entirely correct. "Fashionable" language constructs
evolve for a reason: increased expressiveness, better readability, fewer
mistakes, better upgrade path in the future, and so on.
My "biases" as you call them are as a direct result of personal experience.
I have seen many programmers who screw up turn round and blame it on the
language instead of their own incompetence. If they screw up in language A
they are just as likely to screw up in language B or C. When they complain
"I can do it this way in Java/C++/ASP/whatever so why can't I do it the same
way in PHP?" they are broadcasting their ignorance of the fact that PHP is a
DIFFERENT language therefore it does things DIFFERENTLY. It is only by being
different that a language can be better, but every programmer must accept
those differences and learn to live with them and take advantage of them.
Those of you out there who prefer the way that things are done in
Java/C++/ASP/whatever should stick with those languages and STOP COMPLAINING
that PHP is different.
Very often, "being fashionable" is an EXCELLENT reason to change the way
an
entire language works. Fortran-90 doesn't look an awful lot like
Fortran-77. Sure, it made many developers unhappy, but the result was a
language that encouraged much more maintainable programs.
A language should never be cast in stone and unchangeable from day 1. It
should be upgraded and enhanced to provide newer and better features that
can only be identified in the light of experience. But breaking
backwards-compatibility is a big no-no. Without it you are likely to
alienate the existing user base who will find it too expensive to upgrade to
the new version. With B-C the users can upgrade without problems and
gradually upgrade their source code to take advantage of the new features at
a pace that suits them.
If the authors of PHP made version 5 totally incompatible with version 4
then nobody would upgrade irrespective of how "pure" and "clean" it was
simply because the expense of rewriting all that legacy code would be too
great. If you fail to take into consideration the cost of changing the
language then you will not win many friends in the real world where cost is
a big issue.
Many of the suggestions in this thread fall into this category. You don't
make changes just because you can make changes, but if a change makes it
easier to write programs with fewer bugs, then it's a change that is worth
a fair amount of consideration, even if it breaks a few legacy apps.
In theory I agree, but moving from procedural to OO does not guarantee that
writing programs becomes easier, the bugs become fewer, the timescales
become shorter and the costs become lower. It is not the language you use
but how you use it that counts. Some people have very peculiar ideas on how
to design and implement systems using OO techniques, as documented in my
article http://www.tonymarston.co.uk/php-mys...d-bad-oop.html.
Another factor that you should consider is that it is always more expensive
to retrain and rewrite in another language than it is to rewrite in the
current language.
--
Tony Marston http://www.tonymarston.net
Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: "Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... Tony Marston <to**@nospam.demon.co.uk> wrote or quoted:
What's wrong with http://www.php.net/manual/en/funcref.php ?
The particular page is not what I'm complaining about. It's
PHP's global functions that are the problem - and I've already
stated why I think a single big function namespace is a bad idea.
Global fuctions are not a problem except for you.
Ever heard of polluting global namespaces?
This is programmer's 101 here, surely:
``Namespace pollution -- Global names are available everywhere. You may
unknowingly end up using a global when you think you are using a local
(by misspelling or forgetting to declare the local) or vice versa.
Also, if you ever have to link together modules that have the same
global variable names, if you are lucky, you will get linking errors.
If you are unlucky, the linker will simply treat all uses of the same
name as the same object.''
- http://c2.com/cgi/wiki?GlobalVariablesAreBad
Many of the other points there apply to functions as well - see the
sections on non-locality, lack of access control or constraint checking,
and implicit coupling.
This is why most programming languages have namespaces - and use them. >> What OO features are missing or unavailable?
>
> That's not what I said.
OK then. EWhy should all the functions be OO? What's the advantage?
The usual ones: abstraction; encapsulation; polymorphism; inheritance.
PHP functions do not need all that bloat to work, so again I say "it is not
a problem".
It's not bloat - it's mostly a case of organising things into
heirarchical trees - rather than putting them into big lists. Defending the idea makes no sense to me at all. PHP is not some sort
of Holy object - which you need to sacrifice all existing common
sense about language design to protect. Single big global namespaces
are well out fashion these days - and if you think they are in vogue,
you need to WAKE UP.
Being fashionable is not a good reason to change the way an entire language
works. many many developers are happy with the way PHP works and would be
very unhappy if it were change to suit your personal preferences.
If PHP gets into a bad enough mess from being built on too-backwards
foundations, it will be wiped out by something better than it - and
then where will they be? > It also consequently fails to take advantage of inheritance and
> polymorphism - but that's not what I was mostly complaining about.
The standard PHP functions do not have to take advantage of inheritance
and
polymorphism to work, therefore your argument has no merit.
Noboby *needs* to write programs in high level languages either.
But what is /necessary/ and what is /desirable/ are not the same thing.
Exactly. It is not *necessary* for the standard PHP functions to be objected
oriented. There would be no performance improvement to outwiegh the cost, so
a cost/benefit analysis would shoot the whole idea down in flames.
I have no idea why you are mentioning performance improvements.
The benefits of OO design mainly show up when building large projects,
maintaining and managing code - rather than when optimising code for
speed. >> > I'm pointing out a serious problem with PHP.
>>
>> If PHP had serious problems it would not be the popular language it is
>> today. [...]
>
> Do you have the same view about Microsoft Windows?
Yes. It meets all the criteria of a virus.
So, to clarify: do you think it has serious problems?
Ask the users whose PC's keep crashing. Ask the user's who find that the XP
SP2 upgrade doesn't install. Ask the users who have installed XP SP2 only to
find that some of their other applications no longer work.
Though you don't answer the question directly, I think you say enough
here to undermine your original argument that things that are popular
can't have serious problems with them. Just stop saying that PHP has serious flaws because it is not totally OO.
A bit of a paraphrase, there:
I'm not complaining about PHP the language.
My beef here is with PHP's library - and how out-of-date and backwards it
looks.
No language can survive if it keeps changing every year or so just to be
fashionable. It has to be consistent and provide backwards compatibility
otherwise developers would not switch to later versions.
I've never suggested that PHP should change in a manner that breaks
existing code. The functions in PHP work perfectly well as they are, and making them
all OO would not give any improvement.
We don't agree on that point - and I'm /very/ suprised to find people
defending the design as though it makes sense.
What improvement could I expect if PHP's functions were changed from
procedural to OO?
PHP would scale to building large projects better - and its standard
library would be better organised, easier to extend, and easier to
maintain. PHP's function library is a historical legacy - the product of days
gone by when PHP had no OO features at all - and that we now seem
to be rather stuck with.
All languages evolve. The fact that OOP was not in the original design does
not matter a jot. It made an apearance in PHP 4 and has been improved in PHP
5. I like the fact that I can use procedural code when I want to and OO code
when I want to. I am not forced into one or the other, so I can mix and
match to my heart's content. How many other languages give you that option?
Most OO languages let you code in a procedural style if you want to.
Certainly this is true of languages such as C++, Perl and Java.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Dnia Fri, 03 Sep 2004 18:44:15 +0200, Michael Fesser napisa³(a): There are more encapsulation mechanismns than just namespaces.
Including any php file import *all* its classes and functions into one big,
and flat namespace. It is unecessary and redundant. If you have thousands
of files, it is easy for a conflict, it a mess for bigger projects. It is
also a waste of memory and processor time to parse all those files even if
you want to use only a few functions. This is the reason why PEAR is so
slow. It is the reason why so fine project like ezPublish is also very
slow. The language without namespaces is not full objected language.
Period. Python is also a dynamic language, but has many features
much powerfull than PHP5.
Who cares? Python != PHP.
Java != PHP as well. Perl != PHP, but many of those languages was imported
to PHP syntax. WHY? IMHO some of those features is totally unnecessary in
dynamic language (e.g. private and protected members which make sense for
static languages, but not for the dynamic ones) Python has namespaces, packages, automatic bytecode generation of
imported modules, documentation string feature builed in language etc.
Copying some feature of Python to PHP would be more usefull than
choosen Java features.
Why to copy all features of another language?
For the same reason why Java and Perl syntax was the basis for PHP and it
was a bad choice. But PHP can still be improved in many ways. Why not to
improve language, its syntax and features? Particularly if community may
want it. Something like http://www.python.org/peps/ could be very helpfull.
--
JZ
"Tim Tyler" <ti*@tt1lock.org> wrote in message news:I3********@bath.ac.uk... Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: "Tim Tyler" <ti*@tt1lock.org> wrote in message
news:I3********@bath.ac.uk... > Tony Marston <to**@nospam.demon.co.uk> wrote or quoted: >> What's wrong with http://www.php.net/manual/en/funcref.php ?
>
> The particular page is not what I'm complaining about. It's
> PHP's global functions that are the problem - and I've already
> stated why I think a single big function namespace is a bad idea.
Global fuctions are not a problem except for you.
Ever heard of polluting global namespaces?
No, never.
This is programmer's 101 here, surely:
``Namespace pollution -- Global names are available everywhere. You may
unknowingly end up using a global when you think you are using a local
(by misspelling or forgetting to declare the local) or vice versa.
That is difficult to do in PHP. Within a function every variable is local
unless you explicitly define global $varname; beforehand, or use
$GLOBALS['varname']. Only a bad programmer would confuse the two.
Also, if you ever have to link together modules that have the same
global variable names, if you are lucky, you will get linking errors.
If you are unlucky, the linker will simply treat all uses of the same
name as the same object.''
Firstly, PHP does not have linking. Secondly, different modules cannot
reference different sets of global variables, so if they all reference the
same global name they will all use the same object.
- http://c2.com/cgi/wiki?GlobalVariablesAreBad
That article was not written with PHP in mind, therefore some of its
arguments are totally irrelevant. Besides, it is just an opinion shared by a
small minority so I do not feel obliged to give it any credence.
Many of the other points there apply to functions as well - see the
sections on non-locality, lack of access control or constraint checking,
and implicit coupling.
This is why most programming languages have namespaces - and use them.
None of the languages I have used in the past 30 years have had namespaces.
I regularly program without them so I don't see what the big deal is. >> >> What OO features are missing or unavailable?
>> >
>> > That's not what I said.
>>
>> OK then. EWhy should all the functions be OO? What's the advantage?
>
> The usual ones: abstraction; encapsulation; polymorphism; inheritance.
PHP functions do not need all that bloat to work, so again I say "it is
not
a problem".
It's not bloat - it's mostly a case of organising things into
heirarchical trees - rather than putting them into big lists.
So what's wrong with having a simple single list of functions? All the
programming languages I have ever used have given me instant access to all
of the functions right from the start. I have never had to load in the
functions I want before I could use them. The very idea sounds totally
preposterous. > Defending the idea makes no sense to me at all. PHP is not some sort
> of Holy object - which you need to sacrifice all existing common
> sense about language design to protect. Single big global namespaces
> are well out fashion these days - and if you think they are in vogue,
> you need to WAKE UP.
Being fashionable is not a good reason to change the way an entire
language
works. many many developers are happy with the way PHP works and would be
very unhappy if it were change to suit your personal preferences.
If PHP gets into a bad enough mess from being built on too-backwards
foundations, it will be wiped out by something better than it - and
then where will they be?
That PHP is a mess is just your opinion. I do not share that opinion, nor do
the authors otherwise they would surely take steps to put it right. >> > It also consequently fails to take advantage of inheritance and
>> > polymorphism - but that's not what I was mostly complaining about.
>>
>> The standard PHP functions do not have to take advantage of
>> inheritance
>> and
>> polymorphism to work, therefore your argument has no merit.
>
> Noboby *needs* to write programs in high level languages either.
>
> But what is /necessary/ and what is /desirable/ are not the same thing.
Exactly. It is not *necessary* for the standard PHP functions to be
objected
oriented. There would be no performance improvement to outwiegh the cost,
so
a cost/benefit analysis would shoot the whole idea down in flames.
I have no idea why you are mentioning performance improvements.
The benefits of OO design mainly show up when building large projects,
maintaining and managing code - rather than when optimising code for
speed.
If there is no benefit in performance and there is no benefit is programmer
productivity then there is absolutely no point in changing the language. >> >> > I'm pointing out a serious problem with PHP.
>> >>
>> >> If PHP had serious problems it would not be the popular language it
>> >> is
>> >> today. [...]
>> >
>> > Do you have the same view about Microsoft Windows?
>>
>> Yes. It meets all the criteria of a virus.
>
> So, to clarify: do you think it has serious problems?
Ask the users whose PC's keep crashing. Ask the user's who find that the
XP
SP2 upgrade doesn't install. Ask the users who have installed XP SP2 only
to
find that some of their other applications no longer work.
Though you don't answer the question directly, I think you say enough
here to undermine your original argument that things that are popular
can't have serious problems with them.
>> Just stop saying that PHP has serious flaws because it is not totally
>> OO.
>
> A bit of a paraphrase, there:
>
> I'm not complaining about PHP the language.
>
> My beef here is with PHP's library - and how out-of-date and backwards
> it
> looks.
No language can survive if it keeps changing every year or so just to be
fashionable. It has to be consistent and provide backwards compatibility
otherwise developers would not switch to later versions.
I've never suggested that PHP should change in a manner that breaks
existing code.
Then who was the moron who said that PHP should ditch all the legacy
procedural functions and replace with fashionable OO alternatives? That is
what this whole thread is about. >> The functions in PHP work perfectly well as they are, and making them
>> all OO would not give any improvement.
>
> We don't agree on that point - and I'm /very/ suprised to find people
> defending the design as though it makes sense.
What improvement could I expect if PHP's functions were changed from
procedural to OO?
PHP would scale to building large projects better - and its standard
library would be better organised, easier to extend, and easier to
maintain.
I disagree. It would just be different, not better. Changing the names of
functions, or changing the way they are used would not give tangible
improvements to everybody, only perceived improvements to a meagre few. > PHP's function library is a historical legacy - the product of days
> gone by when PHP had no OO features at all - and that we now seem
> to be rather stuck with.
All languages evolve. The fact that OOP was not in the original design
does
not matter a jot. It made an apearance in PHP 4 and has been improved in
PHP
5. I like the fact that I can use procedural code when I want to and OO
code
when I want to. I am not forced into one or the other, so I can mix and
match to my heart's content. How many other languages give you that
option?
Most OO languages let you code in a procedural style if you want to.
Certainly this is true of languages such as C++, Perl and Java.
So if all those wonderful languages still let you write procedural code then
what is the big deal with insisting that everything should be OO?
--
Tony Marston http://www.tonymarston.net
"JZ" <z@b.com> wrote in message
news:33*****************************@40tude.net... Dnia Fri, 03 Sep 2004 18:44:15 +0200, Michael Fesser napisa³(a):
There are more encapsulation mechanismns than just namespaces.
Including any php file import *all* its classes and functions into one
big,
and flat namespace. It is unecessary and redundant.
If you have thousands of files, it is easy for a conflict, it a mess for
bigger projects. It is
also a waste of memory and processor time to parse all those files even if
you want to use only a few functions.
Then don't put all your functions and classes into one big file. If you
break them down into logical groups then you need only include() the groups
that you want. Stop blaming the language for your inability to organise your
code.
This is the reason why PEAR is so
slow. It is the reason why so fine project like ezPublish is also very
slow.
I do not use PEAR or ezPublish so I wouldn't know.
The language without namespaces is not full objected language.
Period.
PHP is not fully objected oriented and has never claimed to be. It's
procedural roots will never disappear, but it does give access to features
that make OOP a viable proposition. As for namespaces, according to the Gura
Q&A at zend.com (checkout
http://www.zend.com/expert_qa/search...spaces&CID=682) they are
unlikely to ever make an appearance in PHP, so you had just better get used
to that fact.
Python is also a dynamic language, but has many features
much powerfull than PHP5.
Who cares? Python != PHP.
Java != PHP as well. Perl != PHP, but many of those languages was imported
to PHP syntax. WHY? IMHO some of those features is totally unnecessary in
dynamic language (e.g. private and protected members which make sense for
static languages, but not for the dynamic ones)
There you go with those personal opinions again.
Python has namespaces, packages, automatic bytecode generation of
imported modules, documentation string feature builed in language etc.
Copying some feature of Python to PHP would be more usefull than
choosen Java features.
Why to copy all features of another language?
For the same reason why Java and Perl syntax was the basis for PHP and it
was a bad choice.
In your opinion.
But PHP can still be improved in many ways. Why not to
improve language, its syntax and features? Particularly if community may
want it. Something like http://www.python.org/peps/ could be very
helpfull.
So what's wrong with http://bugs.php.net/ with its option for
"feature/change request" ?
--
Tony Marston http://www.tonymarston.net
Tony Marston wrote: This is the reason why PEAR is so
slow. It is the reason why so fine project like ezPublish is also very
slow.
I do not use PEAR or ezPublish so I wouldn't know.
I *do* use PEAR and I don't find it slow. I use the DB, XML_Tree and
Mail_MIME parts of the library and don't them slow at all.
--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/
Tim Tyler wrote:
Using numeric methods on strings is /usually/ a bad idea - and
while automatic type-casting saves you some keystrokes, it
loses you a /lot/ in terms of type safety - and is consequently
a source of many bugs.
I agree.
I think:
$a = "98.6";
$b = $a->floor();
...should fail with an "unknown method" error - and would suggest using:
$a = "98.6";
$b = $a->number()->floor();
or perhaps
$a = "98.6";
$b = real::parse($a); // $b is a real
$b = (int)$b->floor(); // now $b is an int
this still requires some flexibility of typing but it's hard to know
where to draw the line.
either way, you will now *REQUIRE* ALL PHP programmers to use an OO
notation. Unless they understand even the most basic principles of OO,
the syntax will look confusing. I personally didn't bother to check out
the OO side of PHP for many months after I first started learning it. It
was a few years before I took advantage of it in any serious way.
Requiring people to understand OO concepts straight of the bat is not
going to help it's ease of adoption for people who aren't already
programmers before they get into the language. Remember, PHP's shining
success is based on it's easy accessibility. While your suggested
notation may strenghten one of PHP's weaknesses, I believe introducing a
compulsory OO notation will undermine it's fundamental strength of easy
adoption.
I know a lot of [HTML hacking] graphic designers who never would have
dreamed about "programming" if it weren't for PHP. This is where PHP
wins and other languages lose.
------------ And now a word from our sponsor ----------------------
For a quality mail server, try SurgeMail, easy to install,
fast, efficient and reliable. Run a million users on a standard
PC running NT or Unix without running out of power, use the best!
---- See http://netwinsite.com/sponsor/sponsor_surgemail.htm ---- This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Tony Johansson |
last post by:
Hello!
I'm reading a book about C++ and there is something that I don't understand
so I ask you.
Below I have the text from the book and the code from the file where main is
located and some...
|
by: weaknessforcats |
last post by:
C++: The Case Against Global Variables
Summary
This article explores the negative ramifications of using global variables. The use of global variables is such a problem that C++ architects have...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
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: 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...
| |
