Re: [PHP-DEV] Patch: Marking DateTime Instances Immutable
On Sun, Dec 5, 2010 at 6:44 PM, Benjamin Eberlei kont...@beberlei.de wrote: So currently preferred over my patch are two solutions: 1. Just create a DateTimeValue object that is immutable, not optimizing PHP to handle it with efficient garbage collection. 2. One step further, add a static class DateTimeValue like syntax that creates an immutable class. Any ideas? I'd prefer BC breakage. DateTimeValue just doesn't have a good ring to it. Besides, having two both a mutable and an immutable version at the same time is bound to cause confusion. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
$result = new ResultMaker()-getIt(); Isn't this issue just a matter of defining one thing as being correct and then get on with it? There are lots of ambiguities in php's grammar already. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] horizontal reuse: traits vs. grafts
Hi On Thu, Mar 25, 2010 at 4:00 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 25.03.2010, at 14:48, David Soria Parra wrote: Stefan what do you think about stackable traits ? Woha .. that code really scares me. While I like features like this in other languages, I think it would be a big break with PHP's model. PHP has always had a rather static object model, which may be somewhat limiting, but has the benefit of being easy to comprehend. Traits/Grafts stays within this paradigm, but making it possible to modify objects dynamically would be stretching it. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Raise warning first on Maximum execution time exceeded
Hi Stan. On Tue, Mar 23, 2010 at 8:47 AM, Stan Vassilev sv_for...@fmethod.com wrote: Thanks for your patch, but you're going to affect a whole group of users who do advanced logging and recovery in the shutdown phase. This is why these things have to be considered when they're first added. How would they be affected? Current behavior would still be there. A grace period of 1 second seems sufficient on a pristine condition unused server, but when your server is loaded, a spike in load may cause a number of shutdown handlers to take more than 1 second, and stop middway running, causing a lot of unpredictability and trouble for those who rely on this feature. So, you mean that a patch that fixes 90% of the cases, but leaves the 10%, is worse than no patch, because of the confusion it might cause? I guess that could be a valid point; Is it a generally agreed-on strategy for php? -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Raise warning first on Maximum execution time exceeded
Hi list.
We log all errors that happens in our production environment, but as
fatal errors can't be handled from within php, we end up with little
information to go on for further debugging. I'm not very familiar with
the php internals code, but I managed to throw in a hack that appears
to work. In the handler function for timeouts (zend_timeout), I raise
a WARNING, sleep for 1 second and then resume normal behavior, which
results in a fatal error. This gives userland code 1 second to log the
error somewhere, which should be sufficient for debugging.
Would like to get feedback as to if this has any hidden problems, but
otherwise I propose that it's included in the project.
--
troels
--- ./Zend/zend_execute_API.c.orig 2010-03-22 15:33:17.0 +0100
+++ ./Zend/zend_execute_API.c 2010-03-22 15:33:01.0 +0100
@@ -1302,6 +1302,9 @@
ZEND_API void zend_timeout(int dummy) /* {{{ */
{
+zend_error(E_WARNING, Maximum execution time of %d second%s exceeded. Execution will shut down in 1 second., EG(timeout_seconds), EG(timeout_seconds) == 1 ? : s);
+sleep(1);
+
TSRMLS_FETCH();
if (zend_on_timeout) {
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Raise warning first on Maximum execution time exceeded
2010/3/22 Johannes Schlüter johan...@php.net: A one second delay is no option there. And what actually happens is that the warning triggers your custom error handler. After that it sleeps then it dies. What do you mean by no option? Otherwise yes, that's what it does. This also creates a nice way to extend the script runtime after the timeout occurred. aka. making the timeout useless for many scenarios it was meant for. I'm not sure I understand. Are you implying that it is somehow possible to circumvent the second (fatal) error with this change? How? -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Raise warning first on Maximum execution time exceeded
On Mon, Mar 22, 2010 at 4:41 PM, Herman Radtke hermanrad...@gmail.com wrote: What do you mean by no option? Otherwise yes, that's what it does. Using sleep there is not a good practice. Since the custom error handler is triggered, there is no need for the sleep call anyways. So control isn't returned to the C-code before the php error handler finishes. Is that it? On Mon, Mar 22, 2010 at 4:41 PM, Herman Radtke hermanrad...@gmail.com wrote: Consider for a second what you are asking the language to do. The script has run out of memory and instead of halting you want it to switch into an error handler to log the error. What happens when that error handler creates new variables or an object instance? Where does that memory come from? This patch handles timeout, not memory exhaustion. Although a similar solution for memory exhaustion could be useful as well. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP continuations
On Mon, Feb 8, 2010 at 2:38 PM, mathieu.suen mathieu.s...@easyflirt.com wrote: Hi, I am wondering if there is some effort for having continuation in php. Or is there already some construction for continuation? phaux (http://code.google.com/p/phaux/) is an attempt at creating a continuation-based framework for php. It's handled on the framework level, rather than language level, but you might find it interesting. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inspecting opcode
Here's another extension for the same. Generates nice graphs too. http://www.bytekit.org/ -- troels On Thu, Dec 3, 2009 at 4:53 PM, Graham Kelly sgkel...@gmail.com wrote: Hi, It sounds like what you want is VLD. http://pecl.php.net/package/vld - Graham Kelly On Thu, Dec 3, 2009 at 10:51 AM, Mathieu Suen mathieu.s...@easyflirt.comwrote: Hi, Does anyone know how to inspect the opcode of a php file? Thanks -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance question about create_function
On Mon, Oct 26, 2009 at 3:25 PM, Mathieu Suen mathieu.s...@easyflirt.com wrote: Yes that the same but only for PHP = 5.3. I am more asking about performance. You mean PHP 5.3 ? In that case, I would strongly suggest that you use a procedural style. create_function is slow, leaks memory and offers no compile-time validation of syntax. It's also ugly as heck. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reference caller object
On Fri, Sep 18, 2009 at 1:05 PM, Ford, Mike m.f...@leedsmet.ac.uk wrote: Well, that sounds like a pretty good definition of a magic constant, so maybe __CALLER__ might be appropriate as well? It's not a constant, is it now? __FILE__, __LINE__, __CLASS__ etc. can be resolved at compile-time. The caller will only be known at run time. I, for one, am quite happy that it's fairly complicated and convoluted to get the caller of a method, since it could lead to some seriously incomprehensible code in the hands of someone who don't know what they are doing. Requiring the user to use the backtrace is a clear warning sign, and I think that's a good thing. -- troels On Fri, Sep 18, 2009 at 1:05 PM, Ford, Mike m.f...@leedsmet.ac.uk wrote: -Original Message- From: Richard Quadling [mailto:rquadl...@googlemail.com] Sent: 18 September 2009 10:43 Considering we have func_get_args(), maybe func_get_caller() would be a nice fit. I don't like the idea of a constant (CALLER) which changes value as you move around the code. Quite obviously, it isn't constant! Well, that sounds like a pretty good definition of a magic constant, so maybe __CALLER__ might be appropriate as well? Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507, Civic Quarter Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Replacing errors with Exceptions
On Fri, Jul 24, 2009 at 3:23 PM, u...@domain.invalid wrote: I published a (work in progress) RFC today about replacing certain errors with exceptions. I know that there already was something similiar on the php6dev blog, but this is not completly the same, so awating your comments: http://wiki.php.net/rfc/errors_as_exceptions Maybe I'm missing the point somewhere, but isn't this as simple as installing an error-handler with set_error_handler? You can install a global handler, that throws ErrorException, if you want that. The example mentioned in the rfc - simplexml_load_file - is a bit special. If you load an invalid file, you may get more than one error. If these were converted into exceptions, you would miss all but the first. u...@domain.invalid whois -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: [PHP-DEV] Type hinting - Request for Discussion
-- Forwarded message -- From: troels knak-nielsen troel...@gmail.com Date: Fri, Jul 10, 2009 at 2:12 PM Subject: Re: [PHP-DEV] Type hinting - Request for Discussion To: Lukas Kahwe Smith m...@pooteeweet.org On Fri, Jul 10, 2009 at 1:40 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: right .. lets not forget the original goal (though it hasnt been perfectly defined) Good point, clarifying the goal should probably have been done long time ago. I think that some of the reason why this discussion has fragmented and begun to go sour, is that it started with an implementation proposal - not with a problem to be solved. This makes it very hard to agree on anything or even to have a meaningful discussion. So you suggest the following goals: Move common validation code out of the function body in order to * reduce code * increase readability * enable IDE's to be even smarter. That sounds like a good proposal. Now, static typing is one possible solution to that. Contracts is another. I like contracts better, since they focus on the interface rather than on the implementation. I think this is much more in lieu with php's type system. I do agree that moving imperative code into the signature complicates matters and looks rather messy. I don't think that's the case as per my initial proposal however. Now, static typing does provide one benefit over a strictly run-time contract. It enables a more meaningful static analysis of the code. This translates into smarter IDE's and enables certain transformations of source code (Eg. automated refactoring). But they also come at a cost in flexibility, makes the language more verbose and even then, it will still only be a partial solution. Personally I just don't think this price is worth it, just to get smarter IDE's. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
Hi list.
In advance, sorry for muddying the waters even further.
Following the current discussion about typehints to primitives, I'm
wondering if anyone have ever suggested to include some sort of
user-land contract system, such as the one that exists in
plt-scheme[1]
Given the dynamic nature of php, I would suspect that it might be a
much better fit. Unlike the semi-static typecheck that typehints can
give, a contract system would be much more expressive and would add a
lot more value (in my opinion anyway).
I think part of the reason for the popularity of typehints is that it
looks familiar for people coming from Java/C++/C#. The biggest
challenge for such a contract system would then be to come up with
something that doesn't look too alien. A simple way that I can think
of is to overload the meaning of typehints so that they may either
denote a class/interface (as they work currently) OR they may be a
function which takes the variable as argument and yields a boolean.
Eg.:
function array_of_numeric($x) {
foreach ($x as $val) {
if (!is_numeric($val)) {
return false;
}
}
return true;
}
class Foo {
/** Example use-case for a contract */
function sum(array_of_numeric $a) {
return array_sum($a);
}
}
This is just one suggestion - There are other ways to implement the concept.
I can see a number of benefits to a contract system over the currently
discussed typehint system:
1) It covers all the use cases for a type-based system (You can use
`is_integer` as a contract, if you want that)
2) It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.
3) It's focused on the interface of input-parameters, rather than their type.
[1] http://docs.plt-scheme.org/guide/contracts.html
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On Fri, Jul 10, 2009 at 2:28 AM, Josh
Thompsonspam.goes.in.h...@gmail.com wrote:
troels knak-nielsen wrote:
- How do you know if it is a contract or the current object type hint?
The simplest solution would be to make one take precedence. You're not
likely to have both a class and a function with the same name, and if
you do, you kind of had it coming to you. For backwards compatibility
it would probably be most fitting to let the current behaviour
(class/interface) take precedence, although the other way around makes
for some quite interesting possibilities.
- It doesn't allow a type to be forced (casted) to the correct type.
As far as I can tell, this is a moot point. The whole discussion about
casting comes from the fact that hinting to a primitive type is more
restrictive than php's weak typing system. With a contract system this
problem doesn't exist. You could test that something conforms to your
specifications and then simply let the type system do its thing.
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be numeric, it is safe to to arithmetic on
it. No reason to explicitly type cast here.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Thu, Jul 9, 2009 at 2:15 AM, Markmark...@gmail.com wrote: I personally would be highly in favor of adding type hinting/casting BUT with the benifit that php actually becomes faster if you do things like that. Afterall you can use way more effective c code if you know what you expect right? As for the version to include type I sure hope that all the people in favour of this change aren't basing their opinion on some delusion that it would improve performance in any way. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] constructors are callable as regular functions.
I just realised that the following is valid php code:
class Foo {
function __construct() {
echo constructor called\n;
}
}
$f = new Foo();
$f-__construct();
Output:
constructor called
constructor called
I would have expected the second call to __construct() to yield an error.
Has this been discussed before? In that case, was it decided to go
with this behaviour or is it purely accidental? Are there perhaps some
implementation issues in preventing the second call to __construct()?
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constructors are callable as regular functions.
On Thu, Jul 2, 2009 at 4:47 PM, Edward Z. Yangezy...@mit.edu wrote:
Excerpts from troels knak-nielsen's message of Thu Jul 02 10:14:18 -0400 2009:
I would have expected the second call to __construct() to yield an error.
Why should it? Especially since this is idiomatic code:
class A {
public function __construct($a) {
$this-a = $a;
}
}
class B extends A {
public function __construct($a, $b) {
$this-b = $b;
parent::__construct($a);
}
}
In that example, the object instance is not initialised when
parent::__construct() is called.
__construct doesn't do anything like allocate memory. It just happens
to get called when we do new B(1, 2)
I understand that. It's not a technical issue - It's more a matter of
language semantics. Constructors are used for initializing state on an
object. Basically, this behaviour makes it impossible to implement
immutable objects in php. It's not a huge deal - I don't remember ever
seen __construct() called directly.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $_GET['a.b.c']
In a recent mail, some kind of issue regarding queryparams was mentioned (Possibly related to namespaces). Could anybody explain what the issue is, or point to where it's discussed? On Mon, Jan 12, 2009 at 11:56 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote: - I guess we are not going to deal with foo.php?a.b.c = 10 in 5.3.0 (should we put something on the 6.0 todo list for this?) -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures, Lambdas and use
On Sun, Jan 4, 2009 at 10:05 PM, Larry Garfield la...@garfieldtech.com wrote:
$f = function($a, $b) use ($y, $z) global ($x, $w) {
It would still leave the static keyword as an outlier. It wouldn't
make sense to declare a static by-ref.
Another problem with this, is that use and global doesn't match
conceptually. To make sense, we would have to rename use to
something like lexical (I think we had that discussion a year ago).
With the current proposed syntax, that isn't as much of a problem,
because the syntactic placement of use helps you to understand its
meaning..
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
On Fri, Dec 19, 2008 at 3:31 PM, Nathan Rixham nrix...@gmail.com wrote: type hints are all ready there so adding primitives /should/ be possible without any bc issues PHP is loosely typed. Adding typehints to primitives would change this. The only reason that it is working with object types, is because you can't automatically coerce object types anyway. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode()
On Tue, Dec 16, 2008 at 3:06 PM, Richard Quadling rquadl...@googlemail.com wrote: Would it be at all possible to have an ini setting json.strict_encode = On So, my code doesn't change, but I can activate it globally. Essentially I don't want to shoot myself. I don't want to take the safety off. I think we have lots of prior examples of why it's a bad idea to change language semantics with a global setting. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode()
On Tue, Dec 16, 2008 at 12:57 PM, Scott MacVicar sc...@macvicar.net wrote: For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE parameter to the options flag. So you can use json_encode($var, JSON_STRICT_ENCODE); I'm really not a fan of named constants to change the semantics of a function like that. Not to mention that it's a pita to type out, so nobody would bother. It also doesn't address the crux of the matter - That the name json_encode is slightly misleading, in that it may or may not emit json. Would it be a problem to introduce a second function (js_encode?) instead? It could work as json_encode does today, and json_encode could then be changed to raise a warning on illegal input. I realise that this means breaking existing scripts, but it's a trivial change, and if it's announced in advance, people should have time to make that sed -r '/json_encode/js_encode/g' to their code base. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode()
On Mon, Dec 15, 2008 at 10:02 PM, mike mike...@gmail.com wrote: I'd like to see it do the right thing in PHP 6, and perhaps if I think everybody agrees to that. The question at hand, is what the right thing is. I, for one, think that the only sane choices are 1 or 2. The third option is way too magic, and will end up confusing people. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
On Thu, Nov 6, 2008 at 10:35 AM, Dan [EMAIL PROTECTED] wrote: What if you want to provide a set of helper/wrapper classes, appropriately namespaced, something along the lines of: MyFramework\Helpers\Array MyFramework\Helpers\Database MyFramework\Helpers\Session etc. If I want to use that naming convention, I don't want to have to name some of my classes differently just because PHP can't deal with it. It may not be trivial to fix, but to the end-developer, it's a trivial problem and it's something that should just work. I think the point is the same as with Zend_Validate_Interface ; While MyFramework\Helpers is a fair namespace, Array is a bad classname. You should use something like MyFramework\Helpers\ArrayHelper FWIW Zend_Validate_Interface looks odd to me today already, for that reason exactly. I read two namespaces and a classname, and that classname doesn't make much sense. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Iteration tools
On Tue, Nov 4, 2008 at 10:11 AM, Ionut Gabriel Stan [EMAIL PROTECTED] wrote: Anyway, I see there's nobody else that would like this but it's ok, at least now we have namespaces so that I don't have to come up with ugly names like my_map() for these kind of helper functions. I like the proposal. With the advent of first-class functions, functional-style iteration is becoming possible. An abstraction that hides away the difference between arrays and traversables would help further in this direction. And this is something that is much better implemented in the language, than in userland, to ensure interoperability. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Associative array syntax question?
I just realised that his is valid PHP:
?php
var_dump(
array(
'foo' = 42,
'foo' = 53));
Producing the following output:
array(1) {
[foo]=
int(53)
}
I can anticipate that there may be practical reasons for this
feature, but I can't think up any scenario, where it wouldn't be a
programming error to statically declare an associative array with the
same key multiple times. Is this a bug or a known quirk? Should I file
a bug-report on it?
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7- dropping the $ from the variable name - rfc
On Fri, Sep 19, 2008 at 10:50 AM, Hannes Magnusson [EMAIL PROTECTED] wrote: I totally agree. Its really annoying needing to type $ all the time, not to mention how hard it is on Norwegian keyboards. Lets replace it with £ ! There is even a patch available: http://php.markmail.org/message/jsex75rowudeu2nr £ is just as hard. Let's replace it with the international currency-symbol ¤ (Yes, that's what that weird symbol for, in case you've always wondered about it). -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7- dropping the $ from the variable name - rfc
On Thu, Sep 18, 2008 at 9:09 PM, Arvids Godjuks
[EMAIL PROTECTED] wrote:
Well, you can do that right now, PHP supports that for ages.
?php
$myVar = 'print';
$myVar('Hello!'); // Outputs hello
?
Partly because I can't resist being smug, partly because it might
confuse someone, I have to point out that that example won't work,
because pint isn't a function. It would work with most everything else
though.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Introducing Boost.PHP - PHP Extensions in C++, in a minute
On Tue, Jul 29, 2008 at 2:58 PM, Moriyoshi Koizumi [EMAIL PROTECTED] wrote: Hi folks, I created a library that may draw some attention. Boost.PHP is a set of macros and C++ classes that wrap around common Zend Engine structs that Is Boost.PHP affiliated with boost.org ? -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] __toBoolean()
First, apologies if this has been discussed before. I couldn't find
any evidence to suggest that it has, but it kind of surprises me.
As strings aren't objects in PHP, __toString is quite a useful
construct, but it begs the question as to why there aren't
__toprimitve-type for each of the primitive types in PHP? Through
SPL, we have __toArray covered, and I presume that there is no real
value in a __toInteger or __toFloat, but __toBoolean seems as it could
be quite useful, since it would allow an object to be evaluated in a
conditional. Eg. a simple use-case:
class Validation {
protected $errors = array();
function fail($error) {
$this-errors[] = $error;
}
function __toBoolean() {
return count($this-errors) === 0;
}
}
I wonder if the reason why this haven't been suggest yet is because of:
a) Nobody thought about it before
b) Somebody thought about it, and figured out that it was a bad idea
While this looks pretty simple, I have a hunch that introducing such
behaviour could have far-fetching consequences, as it hooks into PHP's
dynamic typing system. It also have a smell of C++'s ability to
overload operators and the ensuing shooting of feet. On the other
hand, it does allow some nifty tricks, and as it's optional,
presumably people would only use it when it actually makes sense.
Even if this, for some reason, doesn't fit into core PHP, it might be
a candidate for SPL? (Even if the syntax would then be slightly
different)
Have a nice weekend.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
On Mon, Jun 30, 2008 at 12:41 AM, Lars Strojny [EMAIL PROTECTED] wrote: Hi Stas, Am Sonntag, den 29.06.2008, 15:20 -0700 schrieb Stanislav Malyshev: [...] If we use this syntax, and $view-escape is not defined, should we call __call or __get? That's indeed a good question. Calling __get() after resolving $view-escape as a property would break BC. Maybe we would do the I really think, the only sane thing to do, is to invoke __call. Since lambda's are first-class, it would make sense to get rid of __call entirely, but as it's already there, I would say, that we should preserve BC. With the current behaviour (invoke __call), it's still possible to delegate to a lambda, from within the __call method. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
On Tue, Jun 24, 2008 at 9:19 AM, Kalle Sommer Nielsen [EMAIL PROTECTED] wrote:
Another subject I would like to see now the closures has been brought up
again
is, how about adding type hinting in method/function prototypes:
function call(function $callback)
{
$callback();
}
Good point. If we implement closures as objects, as already suggested,
then it's simply a matter of typehinting to the classname we pick.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
On Thu, Jun 19, 2008 at 8:44 AM, Andi Gutmans [EMAIL PROTECTED] wrote:
- In PHP 5, object storage is resources done right. I don't think
we should be using the resource infrastructure for this
implementation and would prefer to use the object one. It's better.
I suggest to take a look at it.
Hmm, seems like a good idea. If nobody objects in the next few days,
I'll rewrite my patch to use objects instead of resources. What class
name do you suggest?
Great. I think Closure is probably a good name.
[Btw, if we want to get fancy we could even have a __toString() method on
those which would print out information about the Closure. But this is not a
must, just something which eventually could be nice for debugging purposes...]
Using objects, instead of resources is an excellent idea. Would it be
possible to introduce a general __invoke (Or whatever name is more
fitting) magic-method, so that whichever object implements that
method, is callable with call_user_func (and directly through
variable-function-syntax). Eg.:
class Foo {
function __invoke($thing) {
echo Foo: . $thing;
}
}
$foo = new Foo();
$foo(bar); // echoes Foo: bar
I'm not sure how this would play together with lexical scope?
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
On Thu, Jun 19, 2008 at 4:37 PM, Dmitry Stogov [EMAIL PROTECTED] wrote: I don't like lexical keyword, because it can be used anywhere in function (e.q. inside if or loop statement), however lexical variables must be the That does sound wtf-y, indeed. Is that allowed with the global keyword? Even if it is, I think it would be a sane limitation to put on lexical, that it must come at the beginning of a function body (Perhaps allowing global and static to precede it). -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hints
On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena [EMAIL PROTECTED] wrote:
class test {
static public function +Itest testing($instance) {
return $instance;
}
}
A more sane syntax, might be something like:
class test {
static function testing($instance) : Itest {
return $instance;
}
}
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Feb 18, 2008 8:27 PM, [EMAIL PROTECTED] wrote:
Hi,
during last six months I've studied a language construct called Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose here.
The following RFC deals with the questions what Traits are, how they are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.
Thank you for your attention and I'm looking forward to hear your comments
:)
Kind Regards
Stefan
I know this is in the bike-shed department, but the following syntax
doesn't look very PHP to me:
use B { !bigTalk, talk = bigTalk }
Could we separate exclusions from aliases somehow?
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Feb 19, 2008 9:54 PM, Jochem Maas [EMAIL PROTECTED] wrote:
how about 'possesses' or 'exhibits' - both these words are closer to the
natural language usage of 'trait' with regard to a subject.
John exhibits a trait
Jack possesses a trait
I prefer ``without`` over ``except``, because ``except`` is close to
``exception`` and because it has a different meaning in other
languages (Eg. ``catch``).
I'm not sure if the use-keyword is a good idea as namespaces are already
used. If we use use for traits, maybe going back to import for
namespaces would be the way to go.
I agree that ``use`` is a bad choice, because of the nameclash with
the namespaces syntax (pun intended). ``possesses`` is hideous, but
``exhibit`` isn't too bad.
On Feb 19, 2008 10:02 PM, Stefan Marr [EMAIL PROTECTED] wrote:
Here are some notation proposals:
(snip)
I'm not sure about Aa and Ab because they do not read well in my opinion.
What do you think?
[Ac] How about this:
class FooFoo {
exhibit Traitor {
alias foo as bar;
}
}
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Feb 19, 2008 10:51 PM, Evert | Rooftop [EMAIL PROTECTED] wrote:
Aliasing doesn't make a lot of sense, as you can always :
function newMethod() {
return $this-oldMethod();
}
just seems like unneeded complexity, without a clear benefit..
I believe the idea was to resolve nameclashes.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Array syntax []
One problem, I have with this proposal is, that it isn't much like
javascript anyway. In javascript, there is a distinction between array
and hashmap, with different syntaxes. If anything, the syntax should
probably be {'foo' = 1, 'bar' = 2}.
I don't think the added noise is worth it though, since we already
have a syntax, which has worked for a decade. Having two different
syntaxes, for the exact same thing, isn't that great an idea. All
IMHO, of course.
-1 for those counting.
--
troels
(Which is in fact pronounced trolls)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: Implementing closures in PHP (was: anonymous functions in PHP)
I have another observation about names. Instead of using an arbitrary name, as the name of the function, wouldn't it be possible to let the name be derived from the function-body. Eg., if you took the function-body's tokens and created a hash from them. This would have two implications: 1) Multiple definitions of the same function would be optimised into one. And more importantly 2) , it would be possible to serialize/unserialize a closure. Of course, this won't work if an anonymous function is a resource, since resources can't be serialized. This would work for Wez' original patch though. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: Implementing closures in PHP
On Dec 23, 2007 2:23 AM, Christian Seiler [EMAIL PROTECTED] wrote: First of all: I don't quite understand what you mean when you want to serialize a function (closure or not)? The opcodes? Ok, sure, with the current PHP implementation you can serialize the variable used to CALL the function (e.g. with $func = 'str_replace'; $func is only a string Admittedly, I got the idea, in relation to Wez' patch. There, it would be trivial to serialize/unserialize the function pointer. I suppose that isn't immediately possible, if the closure is a resource type. and can be serialized). But where would you need that? (Ok, for normal functions that are named this could actually be useful, but for anonymous functions?) If a closure could be serialized, it would allow for continuation style applications. I'm not sure, how good idea this is in web applications anyway, so just ignore that. Just a minor note; The semi-colon after the closing brace, seems superfluous. Is there any reason for it? Otherwise excellent work there. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
(Sorry if you get this twice, Antony. I didn't hit 'Reply to all' the
first time)
On Dec 20, 2007 10:19 AM, Antony Dovgal [EMAIL PROTECTED] wrote:
On 20.12.2007 11:18, Alexey Zakhlestin wrote:
On 12/20/07, Antony Dovgal [EMAIL PROTECTED] wrote:
On 20.12.2007 09:57, Alexey Zakhlestin wrote:
being able to do the following (and not to worry about runtime
compilation) is a good reason on it's own:
array_filter($my_data, function($test){ return 3 === ($test % 4) });
Oh, my..
This code clearly demonstrates why a syntax like this should not be
allowed. Ever.
you prefer cluttering namespace with a lot of oneliners?
Oh, come on.. Since when do we call it cluttering?
Is there some kind of limit on number of functions in a namespace?
Yes there is. Or more precise, there is a limited to the number of
sanely named functions.
Why limit yourself and inline the function instead of putting it
into a nice library of utility functions?
currently, people prefer to use explicit cycles instead of
array_map/array_filter and that looks ugly (hides actual logic behind
syntax), but at least it is not as slow as create_function.
Whatever people currently use - it's their choice.
If you think that people would magically switch to the new syntax (if we
decide to
add it after all) in a moment, I'm afraid I have to upset you - this will not
happen
in the next 10 years because of many reasons, so people would still use the
good
old syntax they're used to.
I don't care what other people do with their code base. I don't want
to impose anything on them. I just want to not get a headache, when
reading my own.
So here is what we _actually_ get with this anonymous function syntax:
1) Yet another way to make the code unreadable and overcomplicated.
2) Yet another incompatible syntax you cannot use if you need to support
older PHP versions
(and you can't check for it in runtime, since this is a compile time thingie).
By that standard, we should never change anything in PHP. Ever.
I'm not proposing to roll this out with the next minor release. PHP6
is happening soon; It could include this patch. Of course, if we
postprone it long enough, we will have to wait for PHP7.
3) 10 people happy because they got a new toy.
I don't know how to respond to that, without being rude, so I won't.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 20, 2007 7:02 PM, Sean Coates [EMAIL PROTECTED] wrote:
Apart from saving a few keystrokes, the above could easily be changed
to the following, which is much more clear, DOES compile at compile-
time, and works without adding a new construct that looks like a
closure, but is not indeed one:
function aiusdyasdjkhasdIMASHEDTHEKEYBOARD($test){ return 3 === ($test
% 4) }
array_filter($my_data, 'aiusdyasdjkhasdIMASHEDTHEKEYBOARD');
I'm not sure. Are you using this as an argument _for_ or _against_?
Because to me, that looks ridiculous.
It won't work either. You have to add guards, to prevent a fatal
error, if you include the file twice. So the entire solution would
be:
if (!function_exists('aiusdyasdjkhasdIMASHEDTHEKEYBOARD')) {
function aiusdyasdjkhasdIMASHEDTHEKEYBOARD($test){ return 3 === ($test % 4); }
}
array_filter($my_data, 'aiusdyasdjkhasdIMASHEDTHEKEYBOARD');
At risk of wading into yet circular another discussion on internals@,
I was part of the original thread on this subject, and I agree with
Stas here: unless they're real closure, they're pretty useless.
I don't believe that has been Stanislavs point so far. As I understand
it, he says that adding the syntax, without adding closures, may
confuse people, who then will intuitively expect closures. That is not
the same as saying, it is useless.
On the point of uselessness, I have already explained how it would be
a useful construct.
On Dec 20, 2007 7:09 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
and you did it again :-) Not working? What the hell are you talking of?
We can easily make it working with whatever feature set we want. We do not
We meaning who? I can't easily make closures working in PHP. And even
if I could, I'm not sure I want to.
I agree fully. Static scope should not be implemented in PHP. Could we
discus the patch, rather than something, which is purely theoretical
and only marginally related?
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 18, 2007 12:41 AM, Jeff Moore [EMAIL PROTECTED] wrote: Reading the prior discussion, I think either $_SCOPE['x'] or the lexical $x syntax is fine for accessing local variables in the enclosing scope. But closures also should also support $this and static:: when the closure is defined in a method. While I realise that the possibilities of static scope in PHP, are intriguing, I really think it's a whole different discussion. Related, yes. Interesting, yes. But let's keep it separate, to avoid derailing the whole discussion. On Dec 17, 2007 8:46 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: While we are at it, what's wrong with knowing the name? I can see why closure can be fun when you can dynamically use outer-scope variables. But when you can't, what exactly prevents one from just doing the function? If the code block, which needs to create the function, could be run more than once, it would try to define the function twice, leading to a fatal error. Yes, I could guard it with is_function_defined(), but that wouldn't be pretty. Technically speaking, you're right, but I think aesthetics does have some weight. Or should. It's also my main gripe against create_function() in the first place. On Dec 17, 2007 8:46 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: First, about 100% on the first encounter for any user ever seeing closures in any other language. Second, all the confusion possible, like So how big a part of PHP's userbase is that? I'm guessing, it's small. On Dec 17, 2007 8:46 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: closures in any other language. Second, all the confusion possible, like oh, closures! cool! let me do this and that! what, I can't use variables?! Are you kidding me?! WTF is it useful for?! True, but the people who will anguish over lack of closures, are already tearing their hair out over create_function(). On Dec 17, 2007 8:46 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I'm not sure I understand what you mean by static scope and dynamic scope, ... Static scope is a synonym for lexical scope. On Dec 17, 2007 8:46 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: scope, but anyway thing that looks like closure but works like regular function definition that isn't - is not a very good idea, IMO. Yes, that's the primary problem with the patch. I don't think it's as big an issue, as you do and given the alternatives, I'm willing to make that sacrifice. How's other peoples take on this point? -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 19, 2007 11:21 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: So how big a part of PHP's userbase is that? I'm guessing, it's small. If it's small, we don't need it in the language anyway. I think we need it. In the current incarnation, anonymous functions are so impractical to use, that it's a barrier. I think that is unfortunate, because it could be an interesting and useful direction to take for PHP. The users, who don't know what a closure is, could still learn to use anonymous functions and they would then not assume closures. So even if the user base is small initially (naturally, since the feature doesn't exist), it could grow. And for the rest of us, it's at least better than create_function(). Having no [closure] and knowing it is better than having something that looks like it but doesn't work. Saves time that would be spent unsuccessfully trying to make it work. (I assume you meant closure?) It can still work, without closures. Not all anonymous functions need variable input and if they do, you can use currying. Admittedly, currying has its own practical issues in PHP, but that's a separate discussion. (And one, I'd like to take at a later time for that matter) The point is, that static lambda still has something to offer, even if it doesn't allow closures. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 20, 2007 12:44 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I think we need it. In the current incarnation, anonymous functions are so impractical to use, that it's a barrier. I think that is unfortunate, because it could be an interesting and useful direction to take for PHP. The users, who don't know what a closure is, could Direction like what? Well, the whole functional programming thing. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 20, 2007 1:51 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Well, the whole functional programming thing. But PHP is not an FP language and wasn't built to be one. If one needs an FP language, why not look into languages built with that purpose? We can change it then. PHP wasn't built to be object oriented either. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 16, 2007 8:56 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I don't see how it'd help anything in debugging. Presumably, a stack trace would now contain file and line number. That's not binding. But the problem is, seeing this, one expects closure. And it's no closure. One might expect that, coming from a language with static scope. Then again, one would also expect global variables in that event. I don't really see this as a huge show stopper. My experience from Javascript (Which probably is the language, that most PHP'ers are likeable to have met anonymous functions in) is, that lesser experienced programmers, are often surprised by static scope. Even if they have used Javascript for a while, they have just assumed, that it was global variables. I think the majority of the users won't miss the feature and those who do, will be able to appreciate why it isn't there. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 17, 2007 6:09 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Don't have time right now but we should go back and re-read those discussions before opening a new one. I can probably do it over the next couple of days. I am not necessary against supporting such a solution but we need to make sure it's fully baked and that we clear know and agree on what is and what isn't supported (and that should be documented and not revisited every time someone comes and complains). Variable binding is one thing which would likely not make it into such an implementation unless there's a big shift in the intent of the patch. Allow me to recap then. Static lambdas (in lack of a better name) and create_function() differ from each other in that the former happens at compile time, while the latter happens at run time. The consequence of this is, that you can bind (primitive) variables to the created function, with create_function(), but not with static lambdas. Functionally, create_function() is a variation of eval, which allows you to create new code at runtime. Static lambda is syntactic sugar for creating a function in the global scope, without knowing its name at compile time. Static lambda is more restrictive than create_function(), because there is no way to share scope between the inner and the bounding function. This is specific for PHP, because the language doesn't have static scope. Without going much into details, I think it's pretty safe to say, that introducing static scope into PHP is not only undesireable, but also technically impossible. So let's not spend any time discussing that. In brief, there are the following benefits of introducing static lambdas: A1 Better readability. A2 Syntactic errors happen at compile time, rather than run time. A3 Better support for debugging/introspection. A4 Optimisations are possible. And the following problems: B1 Users might assume, that lambdas have static scope. B2 There is some overlap between the application of create_function() and static lambdas, meaning some level of redundancy. B3 Static lambdas are less powerful, since there is no way to bind variables. If I missed any points, please bring them up. Otherwise, this is what a decision should be based on. (And sorry for pointing out the obvious, but _not_ making a decision, is a decision too) Of the cons, B1 is probably the biggest issue. There are (at least) two considerations to take here; First, how probable is it, that users will make this assumption? And second, how much confusion will it cause to those, which it affects? The first question could perhaps be answered by a survey (Or less scientifically, by random consensus), but the latter is rather subjective. I'd like to make the argument, that those who will tend to suffer most from peculiarities of scoping rules, are the same people, who are less likely to have encountered static scope in the first place. The simple rule, that PHP has dynamic scope, should be simple to understand for anyone who actually knows the difference. Did I miss anything? -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Actually it's the opposite. With create_function, you can bind variables, by marshalling them to a string and embed them in the function-definition. With a static syntax, this isn't possible. However, this is only a problem, when you need to bind variables, which isn't always the case and even then, there are other ways to bind variables in runtime. So it's different from create_function, in that it doesn't allow binding of variables, but I don't see why that should stop us from implementing, considering the benefits it gives in readability and debugging. -- troels On Dec 16, 2007 7:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I think the problem there is that this syntax wouldn't support external variables, and without them there's not much difference between that and create_function. troels knak-nielsen wrote: What was the conclusion on Wez' patch from march [1]? The discussion seemed to steer a bit off, on the discussion of scoping rules, but is there any reason _not_ to implement Wez' patch in HEAD? Even if it doesn't entirely replace create_function, it would be nice to have as a compile-time alternative. [1] http://groups.google.com/group/mailing.www.php-dev/browse_thread/thread/a2c3296dc791369a/075209b288cb28de -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PATCH: anonymous functions in PHP
What was the conclusion on Wez' patch from march [1]? The discussion seemed to steer a bit off, on the discussion of scoping rules, but is there any reason _not_ to implement Wez' patch in HEAD? Even if it doesn't entirely replace create_function, it would be nice to have as a compile-time alternative. [1] http://groups.google.com/group/mailing.www.php-dev/browse_thread/thread/a2c3296dc791369a/075209b288cb28de -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tainted Mode Decision
If taint-mode is intended for testing only, it would never be something, which was turned on per default. Then maybe a tool such as php-sat ( http://www.program-transformation.org/PHP/PhpSat ) is a better solution? It seems to me like there is a rather big overlap between the projects. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how php knows the charset of my code?
On 9/27/07, drysler [EMAIL PROTECTED] wrote: Hello, i am practising with charsets at the moment and so i thought: - How does PHP know the charset i use in my source-code? - Are php-sources limited to specific charsets? - In which areas you have to be aware of the source-code-charset? Perhaps somebody here on the list can tell something about these issues? Thanks! Unless I'm mistaken, PHP expects the source files to be in the internal charset, which is ISO-8859-1. If you use the mbstring extension, you can use different internal encodings. See: http://www.php.net/mbstring Another good read on charset vs. PHP is: http://www.phpwact.org/php/i18n/charsets?s=utf -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type-hinted return values in PHP5?
On 7/18/07, David Duong [EMAIL PROTECTED] wrote: Since there isn't any comments on this, should I have posted this elsewhere? or is it just that no one is interested? It could be interesting to know, if the reason why this hasn't been implemented already, is technical one, or a design decision? -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
