RE: [PHP-DEV] PATCH: zend_mm_heap_overflow()
Shire, Xlog looks really useful. Does it also help with "exception thrown without a stack trace"? Thanks, John. -Original Message- From: shire [mailto:sh...@tekrat.com] Sent: 19 January 2009 01:45 To: PHP Internals List Subject: [PHP-DEV] PATCH: zend_mm_heap_overflow() I'm releasing an extended PHP logging extension that we currently use at facebook with much success. I currently use a small patch to determine if a memory overflow has occurred as there's currently no direct access into the allocator structures. You can get more information on the project at http://tekrat.com/php/xlog/. It would be useful if this patch (and perhaps more accessors into the memory allocator) where added. Although I understand there should be some careful choices and limitations here, and this case is a pretty specific use case, but I thought I'd share it in case there are others who happen to find this useful as well or perhaps someone can propose a more general alternative. Patches for different branches are here (I've pasted php53 below): http://tekrat.com/downloads/bits/zend_mm_heap_overflow.php6.patch http://tekrat.com/downloads/bits/zend_mm_heap_overflow.php53.patch http://tekrat.com/downloads/bits/zend_mm_heap_overflow.php52.patch diff --git a/ZendEngine2/zend_alloc.c b/ZendEngine2/zend_alloc.c index 8853d06..b8884a0 100644 --- a/ZendEngine2/zend_alloc.c +++ b/ZendEngine2/zend_alloc.c @@ -2537,6 +2537,13 @@ ZEND_API void start_memory_manager(TSRMLS_D) #endif } +/*** BEGIN Patch: zend_mm_heap_overflow ***/ ZEND_API int +zend_mm_heap_overflow(TSRMLS_D) { +return AG(mm_heap)->overflow; +} +/*** END Patch: zend_mm_heap_overflow ***/ + ZEND_API zend_mm_heap *zend_mm_set_heap(zend_mm_heap *new_heap TSRMLS_DC) { zend_mm_heap *old_heap; diff --git a/ZendEngine2/zend_alloc.h b/ZendEngine2/zend_alloc.h index d92df4b..3610931 100644 --- a/ZendEngine2/zend_alloc.h +++ b/ZendEngine2/zend_alloc.h @@ -231,6 +231,7 @@ struct _zend_mm_storage { }; ZEND_API zend_mm_heap *zend_mm_startup_ex(const zend_mm_mem_handlers *handlers, size_t block_size, size_t reserve_size, int internal, void *params); +ZEND_API int zend_mm_heap_overflow(TSRMLS_D); /* Patch: +zend_mm_heap_overflow */ ZEND_API zend_mm_heap *zend_mm_set_heap(zend_mm_heap *new_heap TSRMLS_DC); ZEND_API zend_mm_storage *zend_mm_get_storage(zend_mm_heap *heap); -shire -- 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] json_encode()
How about a strict mode added to the list of the current json_encode() options? That way current code will continue to work and anyone reading the docs will know the default behaviour isn't strictly correct. John. John Carter Development Manager NAC Governance Server Cisco johnc...@cisco.com +44 161 249 5825 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error_log -> sapi.log_message
Good idea. Would also be nice if added constants for the existing 0, 1 and 3 options. John. John Carter Development Manager NAC Governance Server Cisco [EMAIL PROTECTED] +44 161 249 5825 -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: 12 November 2008 20:58 To: 'PHP Internals' Subject: [PHP-DEV] error_log -> sapi.log_message Hi! I want to add error_log option (message_type = 4) which would send the message directly to sapi_module.log_message whatever error_log INI setting is. This would allow more flexibility in using SAPI logging channel, since presently there's no reliable way to access it without resetting error_log. Any objection? -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Deprecate define_syslog_variables in 5.3
We use syslog a lot. I've always found define_syslog_variables to be pointless and frankly a little bizarre. +1 on this. John. -Original Message- From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] Sent: 14 October 2008 08:42 To: Kalle Sommer Nielsen Cc: PHP Development Subject: Re: [PHP-DEV] Deprecate define_syslog_variables in 5.3 On 14.10.2008, at 04:04, Kalle Sommer Nielsen wrote: > Hello internals > > I've been looking at the function define_syslog_variables(), and I'm > unsure if its intentional to keep this old functionality in PHP, > seeing as define_syslog_variables defines a shortcut for each of the > LOG_* constants in the form of $LOG_*. > > Therefore I propose the function is being deprecated in 5.3 and > removed in HEAD. I agree. Fixing your code is easy (just remove the call to define_syslog_variables() and the $ in front of LOG), maintains BC with older PHP releases. On the up side this function could create an insanely hard to debug problem for users, is redundant and was a very bad idea from the start (and the docs seem incorrect too). That being said I never used this function or the constants in my code. So is there anyone that does actually use it and has some objection? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- 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
[PHP-DEV] test
John Carter Cisco - PolicyApp [EMAIL PROTECTED]
RE: [PHP-DEV] Class Properties in Interfaces?
Marcus, I think the idea of supporting properties via getters/setters is a fine idea (just like Java, Delphi etc). Many of us simulate this behaviour with __get()/__set(), and it would be nice to formalise it a little. However I don't quite understand the "multiple inheritance" argument - I understand that we can't implement two interfaces that have the same declared method, why wouldn't we just prevent people declaring an identical attribute in the same way? John. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: 06 May 2008 15:22 To: John Carter -X (johncart - PolicyApp Ltd at Cisco); Derick Rethans Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Class Properties in Interfaces? Hello John, the main reason really is storage. If you allow storage in interfaces then you get multiple inheritance with its virtual inheritance (diamond style inheritance) issue. That however onlly applies to plain attributes and not properties which are usually understood as attributes that result in function calls (getter & setter). That said, if PHP had properties, PHP could also allow peroperties in interfaces. So the actual question shoul dbe why we do not support properties. To give an idea how properties could look like: interface Coordinate { public $coord = __get => getCoord, __set => setCoord, __isset => hasCoord, __unset => delCoord; public getCoord(); public setCoord($val); public hasCoord(); public delCoord(); } class MyCoord implements Coordinate { private $_coord = array(0, 0); // actual storage for $coord public __construct($x, $y) { $this->coord = array($x, $y); // calls setCoord } public getCoord() { return $this->_coord; } public setCoord($val) { if (!is_array($val) || count($val) != 2 || !is_numeric($val[0]) || !is_numeric($val[1])) { throw new UnexpectedValueException('Array(x,y) of floats expected'); } $this->_coord = $val; } public hasCoord() { return isset($this->_coord[0]) || isset($this->_coord[1]); } public delCoord() { $this->_coord = array(0, 0); } } This tells me two things: a) Pretty damn complex and in that kind of the opposite of PHP's usual KISS approach (Keep It Simple Safe). b) Pretty sexy as it gives a hell lot of control and you can document everything. Check out all the minor details and think of what that would allow. My conclusion is that even it looks sexy, it might be a bit to complex. A much shorter thing to do might be: interface Coord { abstract $coord; } This would just somehow make sure the attribute $this->coord will be accessible as a public attribute in the implementing class. The same rules as for methods would apply. Derick and me discussed solutions around abstract/virtual attributes a lot in the passed. They were all refused however. But what we had in mind also was more about specifying attributes in an abstract way in classes so that they become documentable while being still handled through __get() and friends. marcus Tuesday, April 29, 2008, 5:51:30 PM, you wrote: > The article explicitly mentions OOP interfaces in a few languages. But > the article, or for that matter any formal definition of an interface > isn't really what I asked about: > > My question was simply: why can't interfaces have properties? > > John. > ____________ > From: Nathan Nobbe [mailto:[EMAIL PROTECTED] > Sent: 29 April 2008 16:17 > To: John Carter -X (johncart - PolicyApp Ltd at Cisco) > Cc: internals@lists.php.net > Subject: Re: Re: [PHP-DEV] Class Properties in Interfaces? > On Tue, Apr 29, 2008 at 6:28 AM, John Carter -X (johncart - PolicyApp > Ltd at Cisco) <[EMAIL PROTECTED]> wrote: > > I think I must be missing something here, but this sounds a > little > tautological - "we can't do it because it doesn't make sense. > This is > because it doesn't make sense" > > Certainly most people (myself included) consider interfaces to > be > methods only, but I can't find a reason why not, and a > search-on-wikipedia-instead-of-doing-proper-research appears to > allow > it: > http://en.wikipedia.org/wiki/Interface_%28computer_science%29 > the problem with that article, as it pertains to this conversation is > that it is referring to interfaces as a general concept. 'interfaces' > can be formed in many ways, via extension of an abstract class or even > an expected set of a parameters in an HTTP request... > getting to the more concrete term 'interface' as it pertains to a > language keyword, interfaces define a contract; they do not specify > implementation details. member variables only facilitate
RE: [PHP-DEV] Class Properties in Interfaces?
I think there's been two responses to this query: 1. We can't have properties in interfaces because interfaces don't have properties. I would say this is tautological and doesn't add anything. 2. Why would you need to? Getters and setters work. So I suppose to answer my question for myself, there's no real technical reason for not having properties in interfaces, but getters and setters work just fine and no-one (including me) really misses them. John. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: Re: [PHP-DEV] Class Properties in Interfaces?
Nathan, By example: interface EggLayer { public $eggsLaid; } class Chicken implements EggLayer; Some would say (and maybe I would too) that you should have a getEggsLaid() method, that's fair enough. But why not the above? You say interfaces can't have properties because they require instance variables. Why do they require instance variables? I also think for the purposes of this discussion, property and instance variable mean the same thing. John. From: Nathan Nobbe [mailto:[EMAIL PROTECTED] Sent: 29 April 2008 17:14 To: John Carter -X (johncart - PolicyApp Ltd at Cisco) Cc: internals@lists.php.net Subject: Re: Re: [PHP-DEV] Class Properties in Interfaces? On Tue, Apr 29, 2008 at 9:51 AM, John Carter -X (johncart - PolicyApp Ltd at Cisco) <[EMAIL PROTECTED]> wrote: The article explicitly mentions OOP interfaces in a few languages. my bad. But the article, or for that matter any formal definition of an interface isn't really what I asked about: My question was simply: why can't interfaces have properties? when you say properties, do you mean a particular set of methods map to a particular instance variable, as getters and setters (i saw that definition from Sebastian earlier)? if thats the case than interfaces cant have properties because they require instance variables. -nathan
RE: Re: [PHP-DEV] Class Properties in Interfaces?
The article explicitly mentions OOP interfaces in a few languages. But the article, or for that matter any formal definition of an interface isn't really what I asked about: My question was simply: why can't interfaces have properties? John. From: Nathan Nobbe [mailto:[EMAIL PROTECTED] Sent: 29 April 2008 16:17 To: John Carter -X (johncart - PolicyApp Ltd at Cisco) Cc: internals@lists.php.net Subject: Re: Re: [PHP-DEV] Class Properties in Interfaces? On Tue, Apr 29, 2008 at 6:28 AM, John Carter -X (johncart - PolicyApp Ltd at Cisco) <[EMAIL PROTECTED]> wrote: I think I must be missing something here, but this sounds a little tautological - "we can't do it because it doesn't make sense. This is because it doesn't make sense" Certainly most people (myself included) consider interfaces to be methods only, but I can't find a reason why not, and a search-on-wikipedia-instead-of-doing-proper-research appears to allow it: http://en.wikipedia.org/wiki/Interface_%28computer_science%29 the problem with that article, as it pertains to this conversation is that it is referring to interfaces as a general concept. 'interfaces' can be formed in many ways, via extension of an abstract class or even an expected set of a parameters in an HTTP request... getting to the more concrete term 'interface' as it pertains to a language keyword, interfaces define a contract; they do not specify implementation details. member variables only facilitate the actions member functions expose and therefore, they are part of the implementation. additionally, one can look to java (and likely others) to see that public attributes are not supported on interfaces. here is a definition from a java5 cert book; "When you create an interface, you're defining a contract for *what* a class can do, without saying anything about how the class will do it. An interface is a contract." -nathan
RE: Re: [PHP-DEV] Class Properties in Interfaces?
I think I must be missing something here, but this sounds a little tautological - "we can't do it because it doesn't make sense. This is because it doesn't make sense" Certainly most people (myself included) consider interfaces to be methods only, but I can't find a reason why not, and a search-on-wikipedia-instead-of-doing-proper-research appears to allow it: http://en.wikipedia.org/wiki/Interface_%28computer_science%29 John. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann Sent: 29 April 2008 11:16 To: internals@lists.php.net Subject: Re: [PHP-DEV] Class Properties in Interfaces? John Carter -X (johncart - PolicyApp Ltd at Cisco) schrieb: > could you explain why Interfaces can't have properties Because interfaces are implemented which makes no sense for attributes. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- 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] Class Properties in Interfaces?
It might be bad design, but design is down to the application developer and not the people who define a language. I'm not necessary asking for the feature, I just want to understand why we can't do it. John. From: James Dempster [mailto:[EMAIL PROTECTED] Sent: 29 April 2008 11:17 To: John Carter -X (johncart - PolicyApp Ltd at Cisco) Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Class Properties in Interfaces? I would start by saying it's bad design. you should use getters and setters which you can define in you interface -- /James On Tue, Apr 29, 2008 at 11:07 AM, John Carter -X (johncart - PolicyApp Ltd at Cisco) <[EMAIL PROTECTED]> wrote: Marcus, I understand why Interfaces can't have bodies, but could you explain why Interfaces can't have properties? Thanks, John. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: 29 April 2008 10:46 To: Jeremy Privett Cc: PHP Developers Mailing List Subject: Re: [PHP-DEV] Class Properties in Interfaces? Hello Jeremy, interfaces cannot have properties, nor can they have method bodies - that is the whole purpose of interfafces. We are thinking of adding traits which would allow for both but would treat inheritance differently. Until we get that you would need to provide an abstract interface to access data in the same way. marcus Tuesday, April 29, 2008, 5:31:33 AM, you wrote: > Hey list, > I was curious what everyone thought of implementing the ability to > specify class members in interfaces. I've run into a couple of > circumstances where I would like to specify public member names inside > of an interface to ensure that these members are accessed in a > standard way and to ensure that they exist. Currently, trying to > include them in an interface results in "*Fatal error*: Interfaces may > not include member variables in file/line number". > Thoughts? > Thanks. > -- > Jeremy Privett > C.E.O. & C.S.A. > Omega Vortex Corporation > http://www.omegavortex.net > Please note: This message has been sent with information that could be > confidential and meant only for the intended recipient. If you are not > the intended recipient, please delete all copies and inform us of the > error as soon as possible. Thank you for your cooperation. Best regards, Marcus -- 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] Class Properties in Interfaces?
Marcus, I understand why Interfaces can't have bodies, but could you explain why Interfaces can't have properties? Thanks, John. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: 29 April 2008 10:46 To: Jeremy Privett Cc: PHP Developers Mailing List Subject: Re: [PHP-DEV] Class Properties in Interfaces? Hello Jeremy, interfaces cannot have properties, nor can they have method bodies - that is the whole purpose of interfafces. We are thinking of adding traits which would allow for both but would treat inheritance differently. Until we get that you would need to provide an abstract interface to access data in the same way. marcus Tuesday, April 29, 2008, 5:31:33 AM, you wrote: > Hey list, > I was curious what everyone thought of implementing the ability to > specify class members in interfaces. I've run into a couple of > circumstances where I would like to specify public member names inside > of an interface to ensure that these members are accessed in a > standard way and to ensure that they exist. Currently, trying to > include them in an interface results in "*Fatal error*: Interfaces may > not include member variables in file/line number". > Thoughts? > Thanks. > -- > Jeremy Privett > C.E.O. & C.S.A. > Omega Vortex Corporation > http://www.omegavortex.net > Please note: This message has been sent with information that could be > confidential and meant only for the intended recipient. If you are not > the intended recipient, please delete all copies and inform us of the > error as soon as possible. Thank you for your cooperation. Best regards, Marcus -- 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] intl naming
Stanislav, I like the look of the API. The naming convention appears logical, on the question of internal class names existing in userland I'm sure people will refer to the discussions around DateTime. Many extensions appear to offer procedural style equivalents to the OOP API, personally I think it would not missed if omitted - have you had any specific requests for it? On the API side have you considered throwing exceptions instead of checking error statuses? Also would it not be useful to have the DateFormatter optionally accept DateTime instances in addition to strings? Thanks, John. -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: 03 April 2008 05:58 To: 'PHP Internals' Subject: [PHP-DEV] intl naming Hi! I wanted to ask the people here for opinions on the subject of functions naming in pecl/intl (hopefully soon to be ext/intl ;) module. Current state can be seen at http://docs.php.net/manual/en/book.intl.php First, a bit of background. Intl extension project was created with the purpose to bring internationalization capabilities of the ICU library to PHP 5, specifically 5.2.x and 5.3.x branches. We felt that as PHP gets more and more enterprise adoption, it needs to start supporting internationalized development much sooner than PHP 6 roadmap would allow us to. Thus, the goals of the project were chosen as follows: 1. Provide dual OO/procedural API for all functions 2. Provide same PHP API for both PHP 5 and PHP 6, to allow easy migration in the future 3. Keep same codebase in 5.x versions and keep codebases between 5 and 6 as close as possible 4. Have separate functional modules for each functionality piece (number formatter, locale handling, collator, normalization, etc.) with intend to add more modules as we go, while keeping single extension as an umbrella for them. As a consequence, we arrived at the naming scheme we have now in pecl/intl, i.e. classes named as NumberFormatter, MessageFormatter, DateFormatter, Collator, etc. and functions named as numfmt_*, msgfmt_*, collator_*, datefmt_*. The latter were chosed in accordance to the guidelines stated at http://www.php.net/reST/php-src/CODING_STANDARDS, saying: If they [function names - SM] are part of a "parent set" of functions, that parent should be included in the user function name, and should be clearly related to the parent program or function family. This should be in the form of parent_*. Recently, concerns were raised specifically about the name DateFormatter, which can potentially infringe on ext/date namespace, and in general about all the names. There were proposals to prefix all class and function names with Intl and intl_ respectively. While I feel that would make the API unnecessarily cluttered (since each module will have to keep its prefix anyway, we'd have stuff like intl_numfmt_parse_currency which IMO looks much uglier than numfmt_parse_currency, same goes for IntlCollator vs. Collator, etc.) However, technically it is possible to do such change, and I believe if it has to be done it has to be done now, when we have first phase of the development feature-complete and ready (up to bugfixes here and there) to announce the module as 1.0 version for everybody to use. So, I propose people to consider all the above and the following options: 1. Leave it as is. Pro: we have it now and it works, and it looks nice. Contra: see above 2. Rename only problematic one - DateFormatter to IntlDateFormatter Pro: minimal change, nice names stay and can be used in PHP 6 API too. Contra: one piece starts with Intl, others don't - API looks weird as a whole 3. Rename all classes to Intl* while leaving functions as is Pro: All classes in the extension look the same, functions still have nice names Contra: All classes get ugly names, and they are going to stay in PHP 6 where those will be recommended system classes (so not Locale but IntlLocale, not Collator but IntlCollator). 4. Rename both classes and functions. Pro: All API looks the same, purists are happy Contra: API looks ugly, too many prefixes for functions. So, please comment. If you have more ideas on the topic, please feel welcome to propose. We want to make this decision ASAP, so that we could move forward with the extension release. -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php