Am 20.08.2012 19:43, schrieb Sebastian Krebs:
What I don't understand is, why should every function goes directly into
the core, if you can achieve exactly the same without core changes?
This comment from Sebastian got me thinking. It's true. Every-someone
has his own views on what is absolutely necessary and should be
available to every-one. Depending on ones coding style, it probably is
absolutely necessary.
Whenever a userland implementation is viable, it becomes a strong
argument against embedding it within the core.
But those suggestions keep coming up and some create more than a little
controversy among the contributors to the list and even among the
core-developers. That said:
Why dont we embed a library of userland code right there in the
documentation, next to the core code, where a php-user would expect or
look for the functionality. They'd have to be properly highlighted as
userland implementations of course but would still be there to be found
in the documentation. This would at least solve the problem of:
- "horrible" implementations, replaced by neatly formed official
userland solutions. - performance (because they would be as efficient as possible)
- correctness (because discussed on the internals (or docs) list, almost
as if it'd go into the core) - skill (because everyone can provide a solution, even if he's not able
to write c-code) - availability (because with a simple copy/paste-action I can use the
provided (currently) official solution immediately.
It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a
source for a userland implementation of, say, array_remove or
print_r_html. Also its alot more accessible and available than PECL,
because it is after all just PHP code.
I am not sure wether this is a good idea, but it struck me as a better
solution than just saying: it's so simple, do it yourself.
Am 20.08.2012 19:43, schrieb Sebastian Krebs:
What I don't understand is, why should every function goes directly into
the core, if you can achieve exactly the same without core changes?This comment from Sebastian got me thinking. It's true. Every-someone
has his own views on what is absolutely necessary and should be
available to every-one. Depending on ones coding style, it probably is
absolutely necessary.Whenever a userland implementation is viable, it becomes a strong
argument against embedding it within the core.
It's a ridiculous argument, IMO. Nothing you could add to core couldn't
be implemented in userland code somehow. (yes, that's hyperbole, but
there is very often a userland solution. Most functions are for convenience)
Adding functions is important for convenience as well as functionality.
Sure, it would be nice to have a small set of functions, but those lead
to overly verbose code and waste the time of developers. Yes, many of
them can be easily implemented in userland, but consider this: what if
half (say) of the array or string functions didn't exist and you had to
manually implement each? A little code can quickly become a lot to do a
lot of simple things.
That said, not every possible function has a compelling case for
addition, simply because it does something too obscure or is impractical.
But those suggestions keep coming up and some create more than a
little controversy among the contributors to the list and even among
the core-developers. That said:Why dont we embed a library of userland code right there in the
documentation, next to the core code, where a php-user would expect or
look for the functionality. They'd have to be properly highlighted as
userland implementations of course but would still be there to be
found in the documentation. This would at least solve the problem of:
- "horrible" implementations, replaced by neatly formed official
userland solutions.- performance (because they would be as efficient as possible)
- correctness (because discussed on the internals (or docs) list,
almost as if it'd go into the core)- skill (because everyone can provide a solution, even if he's not
able to write c-code)- availability (because with a simple copy/paste-action I can use the
provided (currently) official solution immediately.It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a
source for a userland implementation of, say, array_remove or
print_r_html. Also its alot more accessible and available than PECL,
because it is after all just PHP code.I am not sure wether this is a good idea, but it struck me as a better
solution than just saying: it's so simple, do it yourself.
--
Andrew Faulds
http://ajf.me/
Am 20.08.2012 22:51, schrieb Andrew Faulds:
It's a ridiculous argument, IMO. Nothing you could add to core couldn't
be implemented in userland code somehow. (yes, that's hyperbole, but
there is very often a userland solution. Most functions are for
convenience)
I don't think it's ridiculous because every core functionality to be
implemented and maintained causes some php-dev to invest time on
something, which is not absolutely necessary because it could be done,
with some additional work, in userland. There is a lot of functionality,
that can not be reasonably well implemented in userland, and php-dev
time should be used on such cases, no?
With my suggestion, any php-user could suggest a functionality he feels
is missing to go not into core but into the documentation, with a
suggestion of how to solve the problem. Therefore the bar, which decides
wether something is worthy of going into core could stay as high as it
is, but it could be lower for something that goes into the documentation
as an example.
Adding functions is important for convenience as well as functionality.
Sure, it would be nice to have a small set of functions, but those lead
to overly verbose code and waste the time of developers. Yes, many of
them can be easily implemented in userland, but consider this: what if
half (say) of the array or string functions didn't exist and you had to
manually implement each? A little code can quickly become a lot to do a
lot of simple things.
Therein lies the crux of it all...how much is too much or too little.
Who's to say? It's a matter of personal preference, I believe. That's
why such features will always trigger those discussions. Because it
depends on one's programming style...of which there are various, various
good ones, even if not always compatible.
That said, not every possible function has a compelling case for
addition, simply because it does something too obscure or is impractical.
Sometimes that is obvious and then the discussion will be short or not
even starts. But mostly it's not.
Am 20.08.2012 22:51, schrieb Andrew Faulds:
It's a ridiculous argument, IMO. Nothing you could add to core couldn't
be implemented in userland code somehow. (yes, that's hyperbole, but
there is very often a userland solution. Most functions are for
convenience)I don't think it's ridiculous because every core functionality to be
implemented and maintained causes some php-dev to invest time on
something, which is not absolutely necessary because it could be done,
with some additional work, in userland. There is a lot of
functionality, that can not be reasonably well implemented in
userland, and php-dev time should be used on such cases, no?With my suggestion, any php-user could suggest a functionality he
feels is missing to go not into core but into the documentation, with
a suggestion of how to solve the problem. Therefore the bar, which
decides wether something is worthy of going into core could stay as
high as it is, but it could be lower for something that goes into the
documentation as an example.
The problem is that these functions often improve the readability and
concise expressive power of PHP. Yes, you can import large libraries of
functions, but it is much more programmer-friendly not to.
Also, functions can often improve the maintainability of code, as
well. For instance, compare:
if (startswith($line, "<title>") && endswith($line, "</title>") {
with:
if (susbstr($line, 0, 7) === "<title>" && substr($line, -8) ===
"</title>") {
The first is more readable, and more maintainable, since you're not
dealing with manually specified string lengths, which can easily be wrong.
Adding functions is important for convenience as well as functionality.
Sure, it would be nice to have a small set of functions, but those lead
to overly verbose code and waste the time of developers. Yes, many of
them can be easily implemented in userland, but consider this: what if
half (say) of the array or string functions didn't exist and you had to
manually implement each? A little code can quickly become a lot to do a
lot of simple things.Therein lies the crux of it all...how much is too much or too little.
Who's to say? It's a matter of personal preference, I believe. That's
why such features will always trigger those discussions. Because it
depends on one's programming style...of which there are various,
various good ones, even if not always compatible.
There seems to be a problem in here of "if I don't need it, nobody else
does". Of course the reverse "if I need it, everyone else should have it
in core" is also true, but I think the first point is a problem.That said, not every possible function has a compelling case for
addition, simply because it does something too obscure or is
impractical.Sometimes that is obvious and then the discussion will be short or not
even starts. But mostly it's not.
It quite often is obvious, I fear: the most vocal may often be the minority.
--
Andrew Faulds
http://ajf.me/
2012/8/21 Andrew Faulds ajf@ajf.me
Am 20.08.2012 22:51, schrieb Andrew Faulds:
It's a ridiculous argument, IMO. Nothing you could add to core couldn't
be implemented in userland code somehow. (yes, that's hyperbole, but
there is very often a userland solution. Most functions are for
convenience)I don't think it's ridiculous because every core functionality to be
implemented and maintained causes some php-dev to invest time on something,
which is not absolutely necessary because it could be done, with some
additional work, in userland. There is a lot of functionality, that can not
be reasonably well implemented in userland, and php-dev time should be used
on such cases, no?With my suggestion, any php-user could suggest a functionality he feels
is missing to go not into core but into the documentation, with a
suggestion of how to solve the problem. Therefore the bar, which decides
wether something is worthy of going into core could stay as high as it is,
but it could be lower for something that goes into the documentation as an
example.The problem is that these functions often improve the readability and
concise expressive power of PHP. Yes, you can import large libraries of
functions, but it is much more programmer-friendly not to.
Really? Use composer and you'll not feel any difference. Don't use composer
and it will require a single 'include' from you. That is "much more
user-unfriendly"? At the end in both cases you will not feel any
difference. So where is this "readability and concise expressive power",
that is no possible with already existing userland tools?
Also, functions can often improve the maintainability of code, as well.
For instance, compare:if (startswith($line, "<title>") && endswith($line, "</title>") {
with:
if (susbstr($line, 0, 7) === "<title>" && substr($line, -8) ===
"</title>") {The first is more readable, and more maintainable, since you're not
dealing with manually specified string lengths, which can easily be wrong.
Yes, that are functions I can imagine can go into a php-based standard
library. They can even be more efficient than the self-made solution
(strncmp() is faster than substr() ;)) and the user of startsWith() and
endsWith() doesn't even need to take care.
Adding functions is important for convenience as well as functionality.
Sure, it would be nice to have a small set of functions, but those lead
to overly verbose code and waste the time of developers. Yes, many of
them can be easily implemented in userland, but consider this: what if
half (say) of the array or string functions didn't exist and you had to
manually implement each? A little code can quickly become a lot to do a
lot of simple things.Therein lies the crux of it all...how much is too much or too little.
Who's to say? It's a matter of personal preference, I believe. That's why
such features will always trigger those discussions. Because it depends on
one's programming style...of which there are various, various good ones,
even if not always compatible.There seems to be a problem in here of "if I don't need it, nobody else
does". Of course the reverse "if I need it, everyone else should have it in
core" is also true, but I think the first point is a problem.That said, not every possible function has a compelling case for
addition, simply because it does something too obscure or is impractical.
Sometimes that is obvious and then the discussion will be short or not
even starts. But mostly it's not.It quite often is obvious, I fear: the most vocal may often be the
minority.--
Andrew Faulds
http://ajf.me/--
Lars Schultz wrote:
Am 20.08.2012 19:43, schrieb Sebastian Krebs:
What I don't understand is, why should every function goes directly into
the core, if you can achieve exactly the same without core changes?This comment from Sebastian got me thinking. It's true. Every-someone has his
own views on what is absolutely necessary and should be available to every-one.
Depending on ones coding style, it probably is absolutely necessary.Whenever a userland implementation is viable, it becomes a strong argument
against embedding it within the core.But those suggestions keep coming up and some create more than a little
controversy among the contributors to the list and even among the
core-developers. That said:Why dont we embed a library of userland code right there in the documentation,
next to the core code, where a php-user would expect or look for the
functionality. They'd have to be properly highlighted as userland
implementations of course but would still be there to be found in the
documentation. This would at least solve the problem of:
- "horrible" implementations, replaced by neatly formed official userland
solutions.- performance (because they would be as efficient as possible)
- correctness (because discussed on the internals (or docs) list, almost as if
it'd go into the core)- skill (because everyone can provide a solution, even if he's not able to write
c-code)- availability (because with a simple copy/paste-action I can use the provided
(currently) official solution immediately.It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a source for a
userland implementation of, say, array_remove or print_r_html. Also its alot
more accessible and available than PECL, because it is after all just PHP code.I am not sure wether this is a good idea, but it struck me as a better solution
than just saying: it's so simple, do it yourself.
Boilerplates on how to do more complex operations sounds a very good idea to me.
It's exactly the sort of thing I've been asking for ... especially now that the
vast majority of third party tutorials are no longer suitable? Rasmus has
pointed out the same problem only in the last hour, and while trying to sort my
own mysqlnd compile problem, the number of totally out of data results from
google just re-enforce that situation.
Even PEAR is little use as a good example of coding style since it needs to be
updated to be strict compliant in a tidy way - rather than just fire fighting
error messages.
Using them as a replacement for tidying up core functions may be a little
controversial, but it does seem the ideal idea for archiving the excellent
examples that have been presented on the various lists? If they then form the
base for an update to a core function, then the boilerplates just get updated to
be current.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Am 20.08.2012 23:13, schrieb Lester Caine:
Boilerplates on how to do more complex operations sounds a very good
idea to me. It's exactly the sort of thing I've been asking for ...
I am glad you like the idea!;) although "boilerplate" does seem to leave
a metallic aftertaste in my mouth.
especially now that the vast majority of third party tutorials are no
longer suitable? Rasmus has pointed out the same problem only in the
Are you referring to "Rasmus Schultz" from the "removing an item from an
array" thread? As far as I understood, Rasmus is arguing in favor of
having more functionality built into core, while I am arguing, that a
lot of functionality should go into the documentation first, as a
userland implementation. I am not sure I understand what you're getting at.
last hour, and while trying to sort my own mysqlnd compile problem, the
number of totally out of data results from google just re-enforce that
situation.
You mean that when you're googling you get bad results, because of the
whitespread use of php? I know what you mean. If good and proven
examples of common problems would be within the official documentation,
no googling would be necessary.
Even PEAR is little use as a good example of coding style since it needs
to be updated to be strict compliant in a tidy way - rather than just
fire fighting error messages.
Personally I have never used PEAR, so I can't say anything about the
situation there, but I can imagine that maintaining such a large
codebase has it's disadvantages. This could probably happen to my idea
as well...causing lots of necessary maintenance-work, I mean. But since
its userland code, lots of people can work on the problem. Also the kind
of code I'd like to see there is very concise and bare-bones, so it
probably won't need much adjustment to new php-versions.
Using them as a replacement for tidying up core functions may be a
little controversial, but it does seem the ideal idea for archiving the
excellent examples that have been presented on the various lists? If
they then form the base for an update to a core function, then the
boilerplates just get updated to be current.
That's something I thought of too. If some functionality becomes very
popular (difficult to measure, I guess) it could go into core, AFTER
it's proven its worth in real-world applications.
Lars Schultz wrote:
Am 20.08.2012 23:13, schrieb Lester Caine:
Boilerplates on how to do more complex operations sounds a very good
idea to me. It's exactly the sort of thing I've been asking for ...
I am glad you like the idea!;) although "boilerplate" does seem to leave a
metallic aftertaste in my mouth.
I run some model engineering sites ;)
especially now that the vast majority of third party tutorials are no
longer suitable? Rasmus has pointed out the same problem only in the
Are you referring to "Rasmus Schultz" from the "removing an item from an array"
thread? As far as I understood, Rasmus is arguing in favor of having more
functionality built into core, while I am arguing, that a lot of functionality
should go into the documentation first, as a userland implementation. I am not
sure I understand what you're getting at.
No Rasmus Lerdorf was sorting out a problem for someone who was 'following a
tutorial' which was no longer correct.
last hour, and while trying to sort my own mysqlnd compile problem, the
number of totally out of data results from google just re-enforce that
situation.
You mean that when you're googling you get bad results, because of the
whitespread use of php? I know what you mean. If good and proven examples of
common problems would be within the official documentation, no googling would be
necessary.
Exactly ...
Even PEAR is little use as a good example of coding style since it needs
to be updated to be strict compliant in a tidy way - rather than just
fire fighting error messages.
Personally I have never used PEAR, so I can't say anything about the situation
there, but I can imagine that maintaining such a large codebase has it's
disadvantages. This could probably happen to my idea as well...causing lots of
necessary maintenance-work, I mean. But since its userland code, lots of people
can work on the problem. Also the kind of code I'd like to see there is very
concise and bare-bones, so it probably won't need much adjustment to new
php-versions.
Just spent the last two days getting a customers joomla sites working again ...
first problem ... add error_reporting(E_ALL& ~E_STRICT & ~E_WARNING ); to the
config file to hide all the errors and warnings.
Using them as a replacement for tidying up core functions may be a
little controversial, but it does seem the ideal idea for archiving the
excellent examples that have been presented on the various lists? If
they then form the base for an update to a core function, then the
boilerplates just get updated to be current.That's something I thought of too. If some functionality becomes very popular
(difficult to measure, I guess) it could go into core, AFTER it's proven its
worth in real-world applications.
I'm still having trouble finding out the preferred way to use some of the basics
- stuff I've used for years but now throws warnings :( And a clean boilerplate
design without some of the esoteric bells and whistles would be nice.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi,
Nice to see my name not only in my signature ;)
I've not much to say right now, but what you wrote was slightly in my mind,
when I wrote the other mail.
I'll keep an eye on it (at least ;)).
Regards,
Sebastian
2012/8/20 Lars Schultz lars.schultz@toolpark.com
Am 20.08.2012 19:43, schrieb Sebastian Krebs:
What I don't understand is, why should every function goes directly into
the core, if you can achieve exactly the same without core changes?This comment from Sebastian got me thinking. It's true. Every-someone has
his own views on what is absolutely necessary and should be available to
every-one. Depending on ones coding style, it probably is absolutely
necessary.Whenever a userland implementation is viable, it becomes a strong argument
against embedding it within the core.But those suggestions keep coming up and some create more than a little
controversy among the contributors to the list and even among the
core-developers. That said:Why dont we embed a library of userland code right there in the
documentation, next to the core code, where a php-user would expect or look
for the functionality. They'd have to be properly highlighted as userland
implementations of course but would still be there to be found in the
documentation. This would at least solve the problem of:
- "horrible" implementations, replaced by neatly formed official userland
solutions.- performance (because they would be as efficient as possible)
- correctness (because discussed on the internals (or docs) list, almost
as if it'd go into the core)- skill (because everyone can provide a solution, even if he's not able to
write c-code)- availability (because with a simple copy/paste-action I can use the
provided (currently) official solution immediately.It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a source
for a userland implementation of, say, array_remove or print_r_html. Also
its alot more accessible and available than PECL, because it is after all
just PHP code.I am not sure wether this is a good idea, but it struck me as a better
solution than just saying: it's so simple, do it yourself.
Hi,
I find this idea awesome! We could maybe take some inspiration from other communities, for example Ruby. In Ruby there's the "Ruby Standard Library" (http://www.ruby-doc.org/stdlib-1.9.3/) which is a collection of classes written in Ruby and shipped with the Ruby distribution.
I imagine something similar for PHP, but I'm uncertain if we should directly put it into "php-src", or provide it via with a PEAR/Composer package. The Ruby community also plans to unbundle the Userland Standard Library from the distribution, to make it accessible for other Ruby implementations (which would be in our case also good). So I guess it would be best to ship PHP's Userland Standard Library as collection of functions, installed as PEAR package by default, just like PHP_Archive.
If it's installed as a default PEAR package, then the library would already be within PHP's include path by default, so the user could just "require" the needed modules. For example:
require_once "stdlib/strings";
if (strings\startsWith($foo, "bar")) {
// ...
}
I think the Userland standard lib should be structured in reasonable namespaces ("net", "arrays", "strings",…) and could also be a testbed for a redesign of PHP's standard library.
So what we need would be:
- Design document outlining the principles of the intended structure for the
userland standard library. - Consistent conventions for error handling
- Rule out, how the user should use the code. Require individual modules or
include everything with one "require"? - The Userland Standard Library available as PEAR/composer package.
- RFC ruling out the way to ship the Userland Standard Library with the PHP distribution.
--
Christoph Hochstrasser
❖ http://twitter.com/hochchristoph ❖ http://christophh.net ❖ https://github.com/CHH ❖
Am Montag, 20. August 2012 um 22:43 schrieb Lars Schultz:
Am 20.08.2012 19:43, schrieb Sebastian Krebs:
What I don't understand is, why should every function goes directly into
the core, if you can achieve exactly the same without core changes?This comment from Sebastian got me thinking. It's true. Every-someone
has his own views on what is absolutely necessary and should be
available to every-one. Depending on ones coding style, it probably is
absolutely necessary.Whenever a userland implementation is viable, it becomes a strong
argument against embedding it within the core.But those suggestions keep coming up and some create more than a little
controversy among the contributors to the list and even among the
core-developers. That said:Why dont we embed a library of userland code right there in the
documentation, next to the core code, where a php-user would expect or
look for the functionality. They'd have to be properly highlighted as
userland implementations of course but would still be there to be found
in the documentation. This would at least solve the problem of:
- "horrible" implementations, replaced by neatly formed official
userland solutions.- performance (because they would be as efficient as possible)
- correctness (because discussed on the internals (or docs) list, almost
as if it'd go into the core)- skill (because everyone can provide a solution, even if he's not able
to write c-code)- availability (because with a simple copy/paste-action I can use the
provided (currently) official solution immediately.It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a
source for a userland implementation of, say, array_remove or
print_r_html. Also its alot more accessible and available than PECL,
because it is after all just PHP code.I am not sure wether this is a good idea, but it struck me as a better
solution than just saying: it's so simple, do it yourself.
2012/8/22 Christoph Hochstrasser christoph.hochstrasser@gmail.com
Hi,
I find this idea awesome! We could maybe take some inspiration from other
communities, for example Ruby. In Ruby there's the "Ruby Standard Library" (
http://www.ruby-doc.org/stdlib-1.9.3/) which is a collection of classes
written in Ruby and shipped with the Ruby distribution.I imagine something similar for PHP, but I'm uncertain if we should
directly put it into "php-src", or provide it via with a PEAR/Composer
package. The Ruby community also plans to unbundle the Userland Standard
Library from the distribution, to make it accessible for other Ruby
implementations (which would be in our case also good). So I guess it would
be best to ship PHP's Userland Standard Library as collection of functions,
installed as PEAR package by default, just like PHP_Archive.If it's installed as a default PEAR package, then the library would
already be within PHP's include path by default, so the user could just
"require" the needed modules. For example:require_once "stdlib/strings";
if (strings\startsWith($foo, "bar")) {
// ...
}I think the Userland standard lib should be structured in reasonable
namespaces ("net", "arrays", "strings",…) and could also be a testbed for a
redesign of PHP's standard library.
So much /sign!
So what we need would be:
- Design document outlining the principles of the intended structure for
the
userland standard library.- Consistent conventions for error handling
- Rule out, how the user should use the code. Require individual modules
or
include everything with one "require"?
At least with composer you can use a kind of "autoloading": You can define
files, that are always included, when the autoloaded is prepared.
- The Userland Standard Library available as PEAR/composer package.
I would prefer composer, but I guess it is more useful to provide both? For
composer only a git repository and a composer.json is required, thus making
a composer-package from a PEAR-package should be straight forward.
- RFC ruling out the way to ship the Userland Standard Library with the
PHP distribution.
With Composer (again ;)) every project defines the dependencies themself,
thus no additional distribution required.
--
Christoph Hochstrasser❖ http://twitter.com/hochchristoph ❖ http://christophh.net ❖
https://github.com/CHH ❖Am Montag, 20. August 2012 um 22:43 schrieb Lars Schultz:
Am 20.08.2012 19:43, schrieb Sebastian Krebs:
What I don't understand is, why should every function goes directly
into
the core, if you can achieve exactly the same without core changes?This comment from Sebastian got me thinking. It's true. Every-someone
has his own views on what is absolutely necessary and should be
available to every-one. Depending on ones coding style, it probably is
absolutely necessary.Whenever a userland implementation is viable, it becomes a strong
argument against embedding it within the core.But those suggestions keep coming up and some create more than a little
controversy among the contributors to the list and even among the
core-developers. That said:Why dont we embed a library of userland code right there in the
documentation, next to the core code, where a php-user would expect or
look for the functionality. They'd have to be properly highlighted as
userland implementations of course but would still be there to be found
in the documentation. This would at least solve the problem of:
- "horrible" implementations, replaced by neatly formed official
userland solutions.- performance (because they would be as efficient as possible)
- correctness (because discussed on the internals (or docs) list, almost
as if it'd go into the core)- skill (because everyone can provide a solution, even if he's not able
to write c-code)- availability (because with a simple copy/paste-action I can use the
provided (currently) official solution immediately.It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a
source for a userland implementation of, say, array_remove or
print_r_html. Also its alot more accessible and available than PECL,
because it is after all just PHP code.I am not sure wether this is a good idea, but it struck me as a better
solution than just saying: it's so simple, do it yourself.--
--
Christoph Hochstrasser wrote:
In Ruby there's the "Ruby Standard Library"
Isn't that more like PEAR anyway? But with a lot less options :)
Personally I'm looking for a 'Official Userland Library' that provides EXAMPLES
of how to do operations rather than yet another downloadable library. Something
I can cut and past from into my own code when I need a widget and which provides
a much more 'PHP approved' style to the code I'm using now. Putting this into
PEAR is most definitely not what I need. I need to be able to see the code on-line.
There are a few such 'samples' in the manual, but the user added ones tend to be
messy, and finding them is rather hit and miss. I HAVE found good samples, but
getting back to them can be a problem. So perhaps a samples index is all that is
missing, and only index material that is clean and fully 'rules compliant'? Many
examples in the user comments now throw deprecated errors which are the reason
to be looking for alternatives anyway nowadays :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Am 22.08.2012 09:45, schrieb Lester Caine:
Personally I'm looking for a 'Official Userland Library' that provides
EXAMPLES of how to do operations rather than yet another downloadable
library. Something I can cut and past from into my own code when I need
a widget and which provides a much more 'PHP approved' style to the code
I'm using now. Putting this into PEAR is most definitely not what I
need. I need to be able to see the code on-line.
I guess as always, the deployment of this userland-library depends on
the php-users personal preference. I agree with Lester in that I'd
rather have it available online as a proven example of how to solve a
very specific problem instead of loading yet another bunch of functions
I might not even need, just for the sake of having them.
But I guess we could have both. I am not sure we should have a hefty
namespace attached to those functions though...it would of course make
the situation of naming clashes less dire, but that could also be solved
manually by copy/pasting and then renaming according to taste.
This is the beauty of it all. Wether you want to make the functions
available globally, grouped as a static class or using namespaces is
left to the user.
Making the "Library" available for download as a complete package or
using PEAR/Composer could be a second project, no? Lets focus on how it
could fit into the manual (or not) and then go on to how it could be
served as a package?
I'd really like some comments/thoughts from a php-dev on this...and
maybe someone from docs?