RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Hi Zeev, Specifically would it continue to work with the Zend Guard decoder (as it does now)? Thanks, John. -Original Message- From: Zeev Suraski [mailto:z...@zend.com] Sent: 30 January 2013 14:48 To: Christopher Jones Cc: internals@lists.php.net Subject: RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution This is the kind of info the RFC (and then user doc) should have. I updated the RFC with two extra sections - 'what's an opcode cache', and 'interaction with other plugins'. https://wiki.php.net/rfc/optimizerplus Zeev -- 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] Activation of IGBinary serialization extension in 5.4 by default
All, We're fairly heavy users of igbnary and we've found that the latest 1.1.1 from pecl has issues with values-by-reference and therefore can't be used as a drop-in replacement for the standard serialiser as it stands. I suspect it's the same issue as this https://github.com/igbinary/igbinary/issues/6 John. On Thu, 2011-08-18 at 12:12 +0100, Paul Dragoonis wrote: Hey guys, After a brief discussion with Pierre I'm taking this discussion to here. We have the igbinary pecl extension available [1], however not many of our userbase are familiar that it even exists. Here [2] is the performance boost we get from using igbinary with serialize() and unserialize(). Here we get a great perf boost, and what's more excellent as we don't have to break BC to get there! This seems like a no-brainer and a good investment in the speed increase of PHP by default for the future users of the platform. [1] http://pecl.php.net/package/igbinary [2] http://www.php.net/~pierre/vcqa/apcigninary_perf.png Comments please. Regards, Paul Dragoonis. -- John Carter Development Manager Identity Networks
Re: [PHP-DEV] APC distribute cache/dump files?
Hi Pierre, Is this a technical limitation, or just something you're not particularly interested in doing? John. On Fri, 2011-07-22 at 19:04 +0200, Pierre Joye wrote: yeah, just re read it and I realized that I miss the zend guard part, which is definitively not on my todos, and will never be :) On Fri, Jul 22, 2011 at 6:46 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: The original question was for something akin to Zend Guard which is an encryption mechanism. There really are no plans for that. -Rasmus On 07/22/2011 09:40 AM, Stefan Neufeind wrote: I know the political discussions like not needed etc. But imho it might also be useful in corner-cases when you'd need an on-disk-cache etc. So if we have a volunteer to add it and it could maybe be done cleanly (plugin-API, ...) I'd appreciate if you'd allow him to try to come up with a solution :-) Regards, Stefan On 07/22/2011 06:15 PM, Pierre Joye wrote: hi, The 4.x plans went a bit to nowhere while there are good ideas in there. Moving the user cache out of the opcode cache is one of them. At the same time we could prepare something to have a driver based (simple) cache API. I plan to add persistent caching in the next couple of month so I may do this as well, as long as Gopal or Rasmus are fine with the idea. On Fri, Jul 22, 2011 at 5:56 PM, John Carter jcar...@identitynetworks.com wrote: Hi, Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Brian is this what you're working on? (on disk cache from https://wiki.php.net/pecl/apc/todo/40?s[]=apc). Thanks, John. -- John Carter Development Manager Identity Networks -- John Carter Development Manager Identity Networks
[PHP-DEV] APC distribute cache/dump files?
Hi, Are there any plans to make APC work in a similar way to Zend Guard et al so that we could distribute cache/dump files instead of the php source. Is this something that would be easy to add? Brian is this what you're working on? (on disk cache from https://wiki.php.net/pecl/apc/todo/40?s[]=apc). Thanks, John. -- John Carter Development Manager Identity Networks
[PHP-DEV] Inconsistent exit code from CLI?
Hi, When php is invoked from the command line with -h we get exit code 0 as expected: -bash-3.2# php -h ; echo $? Usage: php [options] [-f] file [--] [args...] php [options] -r code [--] [args...] php [options] [-B begin_code] -R code [-E end_code] [--] [args...] ... --re name Show information about extension name. --ri name Show configuration for extension name. 0 However if we use (what I understand to be an) invalid option we also get 0: php -Z ; echo $? Usage: php [options] [-f] file [--] [args...] 0 I've checked a couple of other tools (ls and grep) and they return exit code 2 when the options aren't recognised. Found on 5.2.14 and 5.3.3. Thanks, John. -- John Carter Development Manager johnc...@cisco.com
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 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
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] 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: 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: 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?
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: [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: [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
