Hi everyone,
Regarding some of the features that are going to ship in PHP 6, I'm going to
take some liberty and make some personal remarks in the form of positive
criticism.
- SYSTEM NAMESPACES. There are many PHP built-in functions that act on
certain groups of entities. The best examples are the array_* and
str *functions.
There are many of them, and it gets really cumbersome to repeat the same
prefix for each and every one. This is clearly a reminiscence of original
procedural-style PHP. But now we have namespaces, that were introduced
exactly for this kind of situations. Why not take advantage of it? PHP can
have a built-in \std\array or \php\array or __array namespace that
would group all functions related to arrays, and thus have the
*array_*prefix removed. I see this as an elegant solution for grouping
functionality, without the use of classes and objects as some languages do
to solve this issue. Also, as namespaces support const values, they can
easily be employed here and have some of their prefixes removed too.
Moreover, I see this extended to certain extensions as well, such as the
database extension. Because, let's face it, it's not that logical to have a
mysqli class and objects of type mysqli. It would make more sense to
have *mysql, mysqli, mssql, oracle *(not oci8), sqlite etc. namespaces
from a logical (and realistic) point of view. What I want to emphasize is:
Let's not use classes and repetitive prefixes for grouping purposes,
especially when we have a dedicated language feature for that.
- TYPE HINTING. Currently PHP supports argument type hinting for arrays and
objects. As I know, it's also been decided to offer support for this in
function return values. For me it is hard to understand why not offer
support for type hinting of scalar values as well. Hinting string, int,
float and bool values can save a lot of debugging time and would provide
a great mechanism for early detection of bugs. It will also allow developers
to avoid writing hundreds of lines of code (with *is_type *tests) in a
medium application just to ensure their parameters are of the expected type.
It's better and faster to have checks at compile time.
I cannot agree with the phrase "We do not allow type-hinted properties as
it's not the PHP way". But what is the PHP way? Classes and namespaces were
not the PHP way either. Here we have (and use) them. PHP needs type-hinted
object properties just as it needs type-hinted function arguments. It will
reduce a lot of errors and bugs in code that logically requires some
properties to be of a certain type. It will make objects more consistent. It
will make interfaces more intuitive and more semantic. And the time spent by
the compiler to make the checks will be a better tradeoff than have lots of
lines of application code testing for types. It's logical for a Person to
have a string name, an int age, a bool gender and so on. I believe
this is the PHP way.
- CONST VALUES. PHP supports class constants and, as of 5.3, namespace
constants with the same syntax. However, there is a major limitation upon
constants: "The value must be a constant expression, not (for example) a
variable, a property, a result of a mathematical operation, or a function
call". I think PHP makes a faulty use of constants throughout its
implementation. We have original constants (can be define'd even
with non-constant expressions), class and namespace constants (can have only
constant-expression values) and the so-called magic constants that... are
not really constants at all.
Generally, constants are language elements that are defined with an initial
value and cannot be reassigned or redefined later. It's an improper use of
"initial value" as this is their only value. There should be no restriction
upon where their value comes from, as long as you cannot change it later on.
In PHP this limitation comes from the fact that constants are resolved at
compile time, rather than run time. However, I think it should be possible
to have constant arrays as their values, just as we have them in object
properties. Also, as with the introduction of namespaces, the non-namespaced
code coincides with the global namespace ( \ ) code, I think it's safe to
remove the define function and possibly allow the *const *keyword to
define runtime constants as well (when the value is not a constant
expression).
- PARAMETER ORDER. As noted in an older PHP meeting:
We went over the string functions and found that there are only two
functions that have "needle, haystack" instead of "haystack, needle", namely
in_array() and array_search(). For in_array() it makes sense in a logical
way to work in the same way as SQL, where you first specify the value, and
then you check if it fits "in the array". As array_search() was modelled on
this is_array() function the parameter order is the same.
As there are not many inconsistencies, and changing them would cause quite
some problems for current applications we decided not to change the order.
The conclusion here is a bit disappointing. We have the chance to fix a
problem, but we choose not to. The very fact that there are only
twofunctions with an inconsistent parameter order is a
*real reason *to make the change. What if a third of the functions were
inconsistent, would we make the change more easily? I doubt it, and at the
same time I am convinced that it is much better to have things fixed earlier
and before it's too late.
These were the major issues that came to my mind until now. I am sure many
things and ideas can be rejected with the reason of backward compatibility
and fear of breaking tons of lines of ancient code. But existing code can
and has to be rewritten, modified or maintained in order to keep the pace.
I'm totally against the idea that PHP should keep the pace with old code,
and against the idea of an unbreakable constant-expression PHP style. This
is a dynamic language and should act like one. Developers expect it to
change for the better, and not just add up features.
I hope I didn't sound too harsh :-), I really appreciate all the hard work
that has been put into the development of PHP 5.3, as I use it quite
heavily. I like seeing intuitive and efficient (not just productive)
features added, the same way I want bad features taken out. Sorry for any
features that are planned for implementation and that I'm not aware of.
Thank you for your time,
Adrian Nita
Hi everyone,
Regarding some of the features that are going to ship in PHP 6, I'm going to
take some liberty and make some personal remarks in the form of positive
criticism.
- SYSTEM NAMESPACES. There are many PHP built-in functions that act on
certain groups of entities. The best examples are the array_* and
str *functions.
There are many of them, and it gets really cumbersome to repeat the same
prefix for each and every one. This is clearly a reminiscence of original
procedural-style PHP. But now we have namespaces, that were introduced
exactly for this kind of situations. Why not take advantage of it? PHP can
have a built-in \std\array or \php\array or __array namespace that
would group all functions related to arrays, and thus have the
*array_*prefix removed. I see this as an elegant solution for grouping
functionality, without the use of classes and objects as some languages do
to solve this issue. Also, as namespaces support const values, they can
easily be employed here and have some of their prefixes removed too.
I think that that would be a bad idea - cause endless confusion.
Coders copy code between files, you will have code written with some prefix
in mind going into code with a different prefix - and doing something
completely different.
Moreover, I see this extended to certain extensions as well, such as the
database extension. Because, let's face it, it's not that logical to have a
mysqli class and objects of type mysqli. It would make more sense to
have *mysql, mysqli, mssql, oracle *(not oci8), sqlite etc. namespaces
from a logical (and realistic) point of view. What I want to emphasize is:
Let's not use classes and repetitive prefixes for grouping purposes,
especially when we have a dedicated language feature for that.
-1
- TYPE HINTING. Currently PHP supports argument type hinting for arrays and
objects. As I know, it's also been decided to offer support for this in
function return values. For me it is hard to understand why not offer
support for type hinting of scalar values as well. Hinting string, int,
float and bool values can save a lot of debugging time and would provide
a great mechanism for early detection of bugs. It will also allow developers
to avoid writing hundreds of lines of code (with *is_type *tests) in a
medium application just to ensure their parameters are of the expected type.
It's better and faster to have checks at compile time.
This has been discussed many times. The problem seems to be if something
of a different type is passed, do you try to type juggle or throw an error;
also if type juggle - should the rules be stricter than normal ?
I agree that this would be a good idea - and could lead to better/faster code.
+1
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Hi!
- SYSTEM NAMESPACES. There are many PHP built-in functions that act on
certain groups of entities. The best examples are the array_* and
str *functions.
There are many of them, and it gets really cumbersome to repeat the same
prefix for each and every one. This is clearly a reminiscence of original
Come on. Is it really that hard to write strlen? Or array_merge? Would
it be better if they were len (of what?) and merge (what?)? I don't
think so.
procedural-style PHP. But now we have namespaces, that were introduced
exactly for this kind of situations. Why not take advantage of it? PHP can
Nope. The namespaces were introduced to manage deep and wide class
hierarchies, especially large frameworks with hundreds of classes, not
to bother little string functions that never hurt anyone.
- TYPE HINTING. Currently PHP supports argument type hinting for arrays and
objects. As I know, it's also been decided to offer support for this in
function return values. For me it is hard to understand why not offer
Decided by whom? When?
support for type hinting of scalar values as well. Hinting string, int,
float and bool values can save a lot of debugging time and would provide
This topic was discussed to death on the list, please read the archives.
If after that you still do not understand what it is about, or have some
comments, please ask then.
code coincides with the global namespace ( \ ) code, I think it's safe to
remove the define function and possibly allow the *const *keyword to
define runtime constants as well (when the value is not a constant
expression).
That would not work since code can not be run when class is being
parsed, and after that it is not clear when it is supposed to be run and
in what context, etc. But more importantly - what for? If you need to
calculate something, make it a variable and calculate it in the ctor.
Constants aren't meant to be results of complex calculations, they are
meant to be simple and fixed.
There was a proposal for read-only variables and one for per-variable
getters/setters (actually, with some effort you can do it right now, a
bit less efficiently maybe but doable). This might be direction to go in
this case.
- PARAMETER ORDER. As noted in an older PHP meeting:
Two letters: BC.
Changing variable order in an existing function is a big fat BC break.
And if we put such a bomb into a new version, what would be the
incentive for people to use it? So that apps would have to be shipped in
2 versions, for the old php and the new php?
These were the major issues that came to my mind until now. I am sure many
things and ideas can be rejected with the reason of backward compatibility
and fear of breaking tons of lines of ancient code. But existing code can
Please remember - what you call "ancient code" other people call
"application on which my paycheck depends". So I think we should be
super-extra-careful when messing with it. That doesn't mean we would
never do any BC-breaking change ever - that does mean there always has
to be a very good reason for it. And I personally don't see
"consistency" being good enough reason. Don't get me wrong - it's good,
it's just not good enough to be valued over working applications.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi,
Come on. Is it really that hard to write strlen? Or array_merge? Would it be
better if they were len (of what?) and merge (what?)? I don't think so.
I think you missed the point when I said we should use system namespaces.
There are several ways in which to use namespaces, including aliasing.
procedural-style PHP. But now we have namespaces, that were introduced
exactly for this kind of situations. Why not take advantage of it? PHP can
Nope. The namespaces were introduced to manage deep and wide class
hierarchies, especially large frameworks with hundreds of classes, not to
bother little string functions that never hurt anyone.
You know, there is a world out there too, outside the "deep and wide class
hierarchies". I really doubt that namespaces were introduced in the language
with the sole purpose of grouping hundreds of classes. But you can, if you
make everything a class.
- TYPE HINTING. Currently PHP supports argument type hinting for arrays
and
objects. As I know, it's also been decided to offer support for this in
function return values. For me it is hard to understand why not offerDecided by whom? When?
Here
http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values.
But this may be outdated, sorry if I may not know well.
code coincides with the global namespace ( \ ) code, I think it's safe to
remove the define function and possibly allow the *const *keyword to
define runtime constants as well (when the value is not a constant
expression).That would not work since code can not be run when class is being parsed,
and after that it is not clear when it is supposed to be run and in what
context, etc. But more importantly - what for? If you need to calculate
something, make it a variable and calculate it in the ctor. Constants aren't
meant to be results of complex calculations, they are meant to be simple and
fixed.
There was a proposal for read-only variables and one for per-variable
getters/setters (actually, with some effort you can do it right now, a bit
less efficiently maybe but doable). This might be direction to go in this
case.
When I said global namespace, I meant outside any class as well, where we
would normally use define. My focus was that constants are not meant to be
nor simple, nor complex, but just... constant. I cannot use a variable
computed in the ctor or anywhere else, because that would not be constant.
Simulating readonly properties with a combination of private access and a
magic getter is probably a good example of bad code.
- PARAMETER ORDER. As noted in an older PHP meeting:
Two letters: BC.
Changing variable order in an existing function is a big fat BC break. And
if we put such a bomb into a new version, what would be the incentive for
people to use it? So that apps would have to be shipped in 2 versions, for
the old php and the new php?
What you call a bomb, I call a fix in the language. People should use it
because it is better, not because it is "more". Current apps are shipped in
two versions, for both PHP 4 and 5? No. Take a look at Python 3 for another
example. In the long run, it's more acceptable to break some code once with
a new feature (and devs will know why and what to fix), than have the code
break itself over the time due to bad design.
Please remember - what you call "ancient code" other people call
"application on which my paycheck depends". So I think we should be
super-extra-careful when messing with it. That doesn't mean we would never
do any BC-breaking change ever - that does mean there always has to be a
very good reason for it. And I personally don't see "consistency" being good
enough reason. Don't get me wrong - it's good, it's just not good enough to
be valued over working applications.
I totally agree with the phrase "application on which my paycheck depends".
But applications are developed, fixed and maintained, they are not static,
nor statues that we stare at. I cannot agree with the idea of preferring
working applications to good working applications. Our main focus here is
the language and developers' main focus is their applications.
So, indeed, my opinion is that PHP should take several design decisions in
the future even though some are bolder than others, because I believe
applications will benefit from this in the long term. I don't refer to the
proposals above, but to any solid change that deserves a chance. With
breaking code in mind, we'll have only things added up and end up with a
much bigger and only slightly better PHP.
I cannot agree with the idea of preferring
working applications to good working applications.
Except that's not what's at stake. The application does not become one
bit better or worse by using an updated function that's more
consistent with other functions. The language is what might become
better or worse by the change, not any applications. The side-effect
however, is that you're forcing incredible amounts of developers to
fix code if they want to move it to a newer version of PHP. With the
risk of having tons of code break or just never migrated to newer
versions of PHP with all the problems which that creates.
A better option would probably be to introduce functions that
essentially do exactly the same as the old ones but consistently with
the other functions. Then deprecate the old functions slowly - no
instant BC break and people can migrate to the new proper functions in
good time.
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
</hype
Hi!
You know, there is a world out there too, outside the "deep and wide
class hierarchies". I really doubt that namespaces were introduced in
the language with the sole purpose of grouping hundreds of classes. But
you can, if you make everything a class.
Of course, you know much more that I do about why namespaces were
introduced, but while there is indeed wide world out there, namespaces
aren't meant to be everything to everybody in this world. They were
meant to solve specific problem, which is management of name
hierarchies, because as they grew wider and deeper, names grew longer
and more complex to avoid name collisions, and that became a serious
nuisance. You can, of course, use namespaces for other things, but
renaming strlen() doesn't seem to me being worth it.
Here
http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values.
But this may be outdated, sorry if I may not know well.
Since 2005 a lot happened... return type hints still don't have
consensus required to introduce them, and ample discussion can be found
in the archives if you are interested in the reason why.
When I said global namespace, I meant outside any class as well, where
we would normally use /define/. My focus was that constants are not
So why not use define()?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
- SYSTEM NAMESPACES.
Come on. Is it really that hard to write strlen? Or array_merge? Would
it be better if they were len (of what?) and merge (what?)? I don't
think so.
No, it is not hard to write strlen but I would also like to see these
functions organized better. I've felt that PHP has been a mess since I
learned it way back when, the naming inconsistencies are everywhere.
- TYPE HINTING.
This topic was discussed to death on the list, please read the archives.
If after that you still do not understand what it is about, or have some
comments, please ask then.
Sure, it has been discussed over and over but the fact that it keeps
coming up here should show you that PHP developers want this feature.
- PARAMETER ORDER.
Two letters: BC.
Changing variable order in an existing function is a big fat BC break.
And if we put such a bomb into a new version, what would be the
incentive for people to use it? So that apps would have to be shipped in
2 versions, for the old php and the new php?
Is this something that could be fixed if it's moved to a namespace? The
new "alias" can have the "correct" order but original function can have
the old order.
These were the major issues that came to my mind until now.
Please remember - what you call "ancient code" other people call
"application on which my paycheck depends". So I think we should be
super-extra-careful when messing with it. That doesn't mean we would
never do any BC-breaking change ever - that does mean there always has
to be a very good reason for it. And I personally don't see
"consistency" being good enough reason. Don't get me wrong - it's good,
it's just not good enough to be valued over working applications.
I agree here but again, it could probably be worked around with some
thought. These are a few items that I'd like to see worked on, as a PHP
developer anyway.
At the same time, I'd like to thank the internal developers. Several
other things that were on my list have been worked on, specifically Late
Static Bindings. Thanks again, these are just my comments, not meant to
offend anyone.
- TYPE HINTING.
This topic was discussed to death on the list, please read the archives. If after that you still do not understand what it is about, or have some comments, please ask then.Sure, it has been discussed over and over but the fact that it keeps coming up here should show you that PHP developers want this feature.
check out the RFC's on the topic. See if you want to champion one of them, or add another one if you have different ideas.
- PARAMETER ORDER.
Two letters: BC.
Changing variable order in an existing function is a big fat BC break. And if we put such a bomb into a new version, what would be the incentive for people to use it? So that apps would have to be shipped in 2 versions, for the old php and the new php?Is this something that could be fixed if it's moved to a namespace? The new "alias" can have the "correct" order but original function can have the old order.
Right, if we ever namespace internal stuff (obviously there would be a need for some out of the box BC extension), than this would be the moment to fix stuff like this.
Anyways, if anyone cares about any of the above proposals write up an RFC (or champion an existing one). Lets not end up in a situation where we have to refer people to the archives to understand a previous decision ever again.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
- PARAMETER ORDER.
Two letters: BC.
Changing variable order in an existing function is a big fat BC break. And
if we put such a bomb into a new version, what would be the incentive for
people to use it? So that apps would have to be shipped in 2 versions, for
the old php and the new php?Is this something that could be fixed if it's moved to a namespace? The new
"alias" can have the "correct" order but original function can have the old
order.
No, it would me having two implementations.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
- PARAMETER ORDER.
Two letters: BC.
Changing variable order in an existing function is a big fat BC break.
And
if we put such a bomb into a new version, what would be the incentive
for
people to use it? So that apps would have to be shipped in 2 versions,
for
the old php and the new php?Is this something that could be fixed if it's moved to a namespace? The
new
"alias" can have the "correct" order but original function can have the
old
order.No, it would me having two implementations.
Derick
There's only one way to both maintain BC during a "transition" period, and
fix flaws to prepare for the next 10 years. And that's having two
implementations.
The original one will gradually be deprecated and eventually removed.
Regards,
Stan Vassilev
No, it is not hard to write strlen but I would also like to see these functions organized better. I've felt that PHP has been a mess since I learned it way back when, the naming inconsistencies are everywhere.
I don't believe there's anything stopping you (or other users) from creating either userspace or extension wrappers to handle organization and consistency. You could even use the "system" namespaces, since they don't exist.
S
Sean Coates wrote:
I don't believe there's anything stopping you (or other users) from creating either userspace or extension wrappers to handle organization and consistency. You could even use the "system" namespaces, since they don't exist.
True, the thought has crossed my mind. But I'm more concerned about
performance than organization. I don't know how to make a C extension,
but rather would have to make a PHP namespace.
Derick Rethans wrote:
No, it would me having two implementations.
Although I don't know C, couldn't you do something like:
namespace Foo;
funciton bar($arg1, $arg2) {
return foo_bar($arg2, $arg1);
}
Stan Vassilev wrote:
Ahem. We all secretly know how it should've been from the very start.
Pseudo-methods for the basic types.$array->merge($array2);
$string->len();
I like this. Although wouldn't this be more of a strict data type way of
doing things?
Lukas Kahwe Smith wrote:
Right, if we ever namespace internal stuff (obviously there would be a
need for some out of the box BC extension), than this would be the
moment to fix stuff like this.Anyways, if anyone cares about any of the above proposals write up an
RFC (or champion an existing one). Lets not end up in a situation
where we have to refer people to the archives to understand a previous
decision ever again.
I'm sure it would be a huge undertaking, I'm just saying that it would
be nice to see.
If I knew C I would try to help out, unfortunately I don't yet. That is
why these are all just my comments. I can't act on them but want to
voice my opinion. Again, it's up to all the great developers here.
There are a couple good proposals out there, either would fit. But, is
there something like type check foo(string $message) vs casting
foo((string) $message)?
Thanks,
Ryan
Come on. Is it really that hard to write strlen? Or array_merge? Would it
be better if they were len (of what?) and merge (what?)? I don't think so.
Ahem. We all secretly know how it should've been from the very start.
Pseudo-methods for the basic types.
$array->merge($array2);
$string->len();
Regards,
Stan Vassilev
Ahem. We all secretly know how it should've been from the very start. Pseudo-methods for the basic types.
$array->merge($array2);
$string->len();
Yes. Maybe implemented so that they can be called like functions in a namespace for each type with the "this" value as the first param. So that:
$array->merge($array2);
<=>
\array\merge($array, $array2);
and
\string\len($string);
<=>
$string->len();
Regards, Jacob
Ahem. We all secretly know how it should've been from the very start. Pseudo-methods for the basic types.
$array->merge($array2);
$string->len();Yes. Maybe implemented so that they can be called like functions in a namespace for each type with the "this" value as the first param. So that:
$array->merge($array2);
<=>
\array\merge($array, $array2);and
\string\len($string);
<=>
$string->len();
We then run into a danger of conflict with a user defined namespace \array.
Could I suggest the _ prefix trick, so that the above, if we do it, becomes:
\_array\merge($array, $array2);
\_string\len($string);
Ie all 'internal' ones start '_', such names should not be used by programmers.
'should', I did not write 'may'.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Hi,
There is already a convention that reserved (magic) function names start
with __ (double underscore). This may be extended to reserved namespaces, as
I pointed out in the original message. Then, one can use say __array as it
is, or can alias it with a shorthand notation. Maybe we can turn to have a
look at using namespace std in C++ as a usage example.
On Wed, Apr 21, 2010 at 5:35 PM, Hartmut Holzgraefe <
hartmut.holzgraefe@gmail.com> wrote:
which leads to the main problem i have with readingOO code
(no matter what language actually):with array_merge($array1, $array2);
i can search for array_merge in the code and in the documentation
easily ( e.g. check http://php.net/array-merge )
I was not implying to turn basic (scalar or compound) data types to classes,
because that would be a too dramatic change and I don't want PHP turned into
Ruby or Java :-) However, namespaces are suited when organizing code into
libraries and you don't need the overhead and complexity of OO.
We'd underestimate namespaces if we used them only for grouping "hundreds of
classes and deep hierarchies". And it's not just about being hard to write *
strlen*, it's about having a clear design and grouping together logical
functionality.
As for the http://php.net/array-merge it can be easily changed to *
http://php.net/array/merge* or http://php.net/__array/merge or whatever
:-) Same goes for searching in the code, though these seem minor reasons for
a design decision.
On Wed, Apr 21, 2010 at 5:06 PM, Stan Vassilev sv_forums@fmethod.comwrote:
There's only one way to both maintain BC during a "transition" period, and
fix flaws to prepare for the next 10 years. And that's having two
implementations.The original one will gradually be deprecated and eventually removed.
I agree. Functions that are currently grouped by some prefix in their names
can be safely and gradually deprecated.
Regards,
Adrian
Ahem. We all secretly know how it should've been from the very start.
Pseudo-methods for the basic types.$array->merge($array2);
$string->len();Yes. Maybe implemented so that they can be called like functions in a
namespace for each type with the "this" value as the first param. So that:$array->merge($array2);
<=>
\array\merge($array, $array2);and
\string\len($string);
<=>
$string->len();We then run into a danger of conflict with a user defined namespace \array.
Could I suggest the _ prefix trick, so that the above, if we do it,
becomes:\_array\merge($array, $array2); \_string\len($string);Ie all 'internal' ones start '_', such names should not be used by
programmers.
'should', I did not write 'may'.--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include http://www.ukuug.org/%0A#include <std_disclaimer.h
Hi!
_array\merge($array, $array2);
_string\len($string);
how it's better or more clean than array_merge or strlen? I am a big fan
of OO and use it all the time, but there's a virtue in moderation - if
you just want a length of a string, you son't have to build class
hierachy with design patterns on top to do it - just take the length of
the string!
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
_array\merge($array, $array2);
_string\len($string);how it's better or more clean than array_merge or strlen? I am a big fan
of OO and use it all the time, but there's a virtue in moderation - if
you just want a length of a string, you son't have to build class
hierachy with design patterns on top to do it - just take the length of
the string!
I agree with you.
I just wanted to avoid namespace name pollution by proposing a reservation
of some of the name space IF this idea goes ahead -- I do not think
that it is a good idea - for the reasons that I gave when this was first proposed.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Hi everyone,
[...]
Thank you for your time,
Adrian Nita
The PHP-way is to NEVER BREAK BC!
On Wed, Apr 21, 2010 at 7:29 AM, Mark Skilbeck markskilbeck@gmail.comwrote:
Hi everyone,
[...]
Thank you for your time,
Adrian Nita
The PHP-way is to NEVER BREAK BC!
Except when you can do some cool stuff, or you are a lazy dev, and easier to
do BC, than correctly fix something, or both.
Tyrael