Re: [PHP-DEV] Extending PHP with C++ (Newbie Question)
Thank you all for the reply. I guess I'll take a look at those document and samples, start playing around with it a bit. :D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [DOC-CVS] cvs: phpdoc /en/features commandline.xml
On Mon, Nov 10, 2008 at 12:05, Hannes Magnusson <[EMAIL PROTECTED]> wrote: > On Mon, Nov 10, 2008 at 11:10, Jakub Vrana <[EMAIL PROTECTED]> wrote: >>> Not true: >>> $ php -l t.php; echo $? >> >>> Parse error: syntax error, unexpected $end in t.php on line 3 >>> Errors parsing t.php >>> 255 >> >> In which PHP version and in which OS? Because in >> http://lxr.php.net/ident?i=php_lint_script I see FAILURE and in >> http://lxr.php.net/ident?i=FAILURE I see -1 which is the number that >> PHP 5.2.6 under Windows really returns. > > I'm running Linux, Ubuntu, and FreeBSD. > > Your reading of the code is correct, however: > "The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other > value, though only the least significant 8 bits (that is, status & > 0377) shall be available to a waiting parent process." > > The same rules apply to the userland exit() function. > > Maybe we should fix the exist status here, manually setting it to 255 > in the else clause of php_cli.c:1138? There are few other exit()s that use negative values.. If there are no objections I will change them all to actual POSIX values on monday. (i.e -1 will be 255, -2 254..). -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
Why? I have developed framework using PHP namespaces and studied Zend Framework source codes and result is: if we use the new resolution rules (1), than in nearly all cases developers must prefix class names with \, only in few cases prefix is not required. Why? Because usually classes in more nested namespaces extends classes in less nested namespaces. If you don't believe, look in framework sources :-) A quick study on the Zend Framework source reveals most top-level classes requiring, using, and accepting as arguments "more inner" classes and interfaces in the relevant namespace: Zend_Acl ==> Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface, Zend_Acl_Role_Registry, Zend_Acl_Assert_Registry... Zend_Auth ==> Zend_Auth_Storage_Session, Zend_Auth_Storage_Interface, Zend_Auth_Adapter_Interface... Zend_Cache ==> Zend_Cache_Core, Zend_Cache_Frontend, Zend_Cache_Backend (including all specific frontend/backend adapters). Zend_Db ==> it's a factory for all classes like: Zend_Db_Adapter_* Zend_Pdf ==> Zend_Pdf_Page, Zend_Pdf_Cmap, Zend_Pdf_Font, Zend_Pdf_Style, Zend_Pdf_Parser, Zend_Pdf_Trailer, Zend_Pdf_Color etc. So, I really suggest we leave that argument out. Regard, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
On 15.11.2008, at 20:17, Stanislav Malyshev wrote: Hi! So what if we for now stick with the BC fix? However maybe for PHP 6.0 we should make a real effort to figure out how objects are supposed to be handled in our PHP type juggeling world. Depends what you mean by BC fix. If you mean just rolling these functions back to using zval** and converting manually, I'm not sure it's the best idea... It'd be better for parameter parsing API to be able to handle such things. no i meant .. going along with the fix you suggested. and for those places where you said we its not clear how things should behave, we should just go by how things behaved in 5.2. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
Hi! So what if we for now stick with the BC fix? However maybe for PHP 6.0 we should make a real effort to figure out how objects are supposed to be handled in our PHP type juggeling world. Depends what you mean by BC fix. If you mean just rolling these functions back to using zval** and converting manually, I'm not sure it's the best idea... It'd be better for parameter parsing API to be able to handle such things. -- 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
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
Are you aware of __NAMESPACE__? Also, if you are using a lot of external namespace names, you might consider simply defining constants: namespace foo\bar\baz; const ns = __NAMESPACE__; then you can simply do use foo\bar\baz; $name = baz\ns; I don't see a huge pressing need for nameof since the above is 3 extra lines of code - total - per NS. If this sounds good, I will add an example to the new docs yet-to-be-committed. Greg I'm aware of __NAMESPACE__, and your example is kinda creative, but I think that's a touch too much acrobatics for something that's a basic need :P Consider callbacks, factories, strategies, drivers, adapters, proxies and so on which typically may and do pass class/function names around. I don't know. I'd rather endure the pain and write the string in full every single time than cause extra confusion in my source code :) Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
2008/11/15 Lukas Kahwe Smith <[EMAIL PROTECTED]>: > > On 13.11.2008, at 19:19, Stanislav Malyshev wrote: > >> Hi! >> >>> Can anyone write up a summary of the situation and the options we have? >> >> Sure. A number of array functions in 5.2 accept arrays, but use HASH_OF to >> extract array value, which means they automatically accept objects if the >> object has working get_properties handler. In 5.3, such function use new API >> with 'a' parameter, which accepts only arrays proper. >> The proposal is to have some new parameter - say 'a%' - which would call >> HASH_OF on objects where it makes sense. The definition of "makes sense" is >> not clear yet, since, for example, sort() on some objects may make sense - >> if the object's get_properties returns real storage - or may not, if that >> handler returns the mere copy of the real data. We might use some interface >> as a marker - like ArrayAccess - though I'm not sure if it will work in all >> circumstances. > > So what if we for now stick with the BC fix? > However maybe for PHP 6.0 we should make a real effort to figure out how > objects are supposed to be handled in our PHP type juggeling world. > I think we should fix it, if theres BC its most likely people will draw away from using it, especially people writing cross version applications if they have to "hack" their way to use this feature. I like Stas' suggestion for changing the parameter parsing api to support it like that. -- Kalle Sommer Nielsen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
On 13.11.2008, at 19:19, Stanislav Malyshev wrote: Hi! Can anyone write up a summary of the situation and the options we have? Sure. A number of array functions in 5.2 accept arrays, but use HASH_OF to extract array value, which means they automatically accept objects if the object has working get_properties handler. In 5.3, such function use new API with 'a' parameter, which accepts only arrays proper. The proposal is to have some new parameter - say 'a%' - which would call HASH_OF on objects where it makes sense. The definition of "makes sense" is not clear yet, since, for example, sort() on some objects may make sense - if the object's get_properties returns real storage - or may not, if that handler returns the mere copy of the real data. We might use some interface as a marker - like ArrayAccess - though I'm not sure if it will work in all circumstances. So what if we for now stick with the BC fix? However maybe for PHP 6.0 we should make a real effort to figure out how objects are supposed to be handled in our PHP type juggeling world. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace resolution rules has been changed?
David Grudl wrote: > Why? I have developed framework using PHP namespaces and studied Zend > Framework source codes and result is: if we use the new resolution rules > (1), than in nearly all cases developers must prefix class names with \, > only in few cases prefix is not required. Why? Because usually classes > in more nested namespaces extends classes in less nested namespaces. If > you don't believe, look in framework sources :-) > > So, resolution al?? 1) is nearly in all cases pain and in few cases nice, > resolution al?? 2) is nearly in all cases nice and in few cases not too > nice. true, however i have a counter example: classes from more general namespace that use further nested classes (think some kind of behaviour and different drivers/plugins for example). so while it's true that more nested classes usually extend the less nested ones it also common for more generic code to use it's namespace descendants. in sutch condition possibility to use just the remaining namespace part is a big help and i'd say it's usage would be more comon than single "extends" at class definition where you're obligated to supply FQN [1]. > > Furthermore, resolution al?? 1) means, that namespace named foo\stuff is > fiction - there is only namespace named \foo\stuff. Lets use \foo\stuff > everywhere: i second that (at least when FQN is used) - would provide more consistency. m. [1] FQN: fully quallified name -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
"Stan Vassilev | FM" wrote: > For me the only way to make it clear to both humans and parsers alike is > the filepath semantics, in all places, including use. It's not perfect, > there's no completely problem-free solution, but "prepend \ for absolute > path" is able to become muscle memory, while other mixed solutions I've > seen are more confusing and require more thinking: "wait in this context > what was what?". My point exactly. This was a real pain in the ass while converting from old to new resolution rules (though I now this is a one-time example). However i was explaining the new resolution rules to my co-workers recently and it was aparent the context dependant resolution isn't clear, while understanding: "it's always relative to current namespace" is simple and easy. Also most people are familiar with filepath semantics so there is a obvious point of reference (and confusion when it's not consistent). > But this introduces a new keyword: nameof, which could clash with > function/class/constant "nameof" in existing source code. I could suggest [...] > But it's definitely in-your-face issue while using namespaced code. I'm not shure how big of a problem "nameof" clashing would be, however a way to get fully qualified name is a nessesity in my opinion - i strugle with this in my framework too. Gregs suggestion of __NAMESPACE__ concatenated solution (if i understand it correctly) isn't one accualy because __NAMESPACE__ resolves to current namespace; and "typeof" might (and probably usually will) be used on aliased classes not nessecerely from current namespace. m. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extending PHP with C++ (Newbie Question)
hi, Take a look in pecl/rar for an example of a c++ based extension (or some other pecl extensions) On Sat, Nov 15, 2008 at 4:11 PM, Chris Jiang <[EMAIL PROTECTED]> wrote: > Hi all, it's my first time posting in this mailing list. > > I've been trying to make a PHP extension for my project, and would really > like to use C++ instead of C to write the code. I've been searching for some > tutoral or manual for some time already, but not so lucky fining anything > useful for newbies like myself. > > Yes, I've searched quite carefully on the search engine and the achive of > this mailing list. End up finding a really old (posted in 2004) thread by > someone signed as 'J', directing to a link sort of like > http://tutorbuddy.com/software/phpcpp. I guess this might be what I need, > but the article seems already out of date. I've found a translated version > of this article, and made a testing extension following the instructions, > however it didn't work. > > The article was written for PHP 4.2.X, and the sample code is missing (the > link is broken). I'm currently working with PHP 5.2.5. Is it because PHP > 5.2.5 is really different with 4.X? Or the document was not properly > translated? > > Can someone be so kind to point me an URL of this original article? > > Thank you all! > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
Stan Vassilev | FM wrote:
>> Hi Marcin,
>>
>> Stan also requested this, so it should be considered as a possibility.
>>
>> Personally, I would rather not introduce this land mine. It requires
>> the user to do an implicit prepending of namespace name ("foo") to "bar"
>> in the use statement as well as a translation of "A", which could fast
>> lead to unreadable code.
>>
>> It is probably best to simply require a fully qualified name where it is
>> intended. Thus
>>
>> 1) require leading "\" in use statements
>> 2) allow "namespace\blah" in use statements, as this is a valid fully
>> qualified name.
>>
>> > namespace my\ns;
>>
>> // this is a better way to do the suggested "use bar as A;"
>> use namespace\bar as A;
>> use \bar as B;
>>
>> class mine extends \my\parentclass {}
>> ?>
>
> Greg, I can't spot where does your example differ from what I and Marcin
> suggested? Please explain.
I would not allow "use blah\blah as bar;"
> And there's one more pain point which I posted earlier on the list
> about, but now as I prepare my framework for 5.3 namespaces, I *really*
> feel the pain in practice: the inability to pass a class/function name
> without specifying it fully as a string.
>
> My suggestion was: use foo\bar\baz as alias;$name = nameof alias;
> // $name == 'foo\bar\baz'
Are you aware of __NAMESPACE__? Also, if you are using a lot of
external namespace names, you might consider simply defining constants:
namespace foo\bar\baz;
const ns = __NAMESPACE__;
then you can simply do
use foo\bar\baz; $name = baz\ns;
I don't see a huge pressing need for nameof since the above is 3 extra
lines of code - total - per NS.
If this sounds good, I will add an example to the new docs
yet-to-be-committed.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extending PHP with C++ (Newbie Question)
Hi Chris, On Sat, Nov 15, 2008 at 3:11 PM, Chris Jiang <[EMAIL PROTECTED]> wrote: > I've been trying to make a PHP extension for my project, and would really > like to use C++ instead of C to write the code. I've been searching for some > tutoral or manual for some time already, but not so lucky fining anything > useful for newbies like myself. It looks like http://developers.facebook.com/phpembed/ will give you what you're looking for. Paul -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Thu, Nov 13, 2008 at 4:14 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > 1) ext/mhash in 5.3. > I) enable ext/hash by default +1 > II) remove ext/mhash +1 > 2) deprecate ereg*. +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN and > friends) > b) Should we instead just throw an E_STRICT > c) Document as is a > 4) keep ext/phar enabled by default in 5.3? +1 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default -1 > II) also enable ext/mysql, mysqli and pdo_mysql by default since there will > be no external dependencies in this case -1 > 7) should Output buffering rewrite MFH? this one comes with some baggage, we > need enough people to actually have a look at how things are in HEAD and > make it clear that they will be available for bug fixing and BC issues > resolving. the risk here is obviously that any BC issues will be hard to > isolate for end users. +1 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 b -- moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Extending PHP with C++ (Newbie Question)
Hi all, it's my first time posting in this mailing list. I've been trying to make a PHP extension for my project, and would really like to use C++ instead of C to write the code. I've been searching for some tutoral or manual for some time already, but not so lucky fining anything useful for newbies like myself. Yes, I've searched quite carefully on the search engine and the achive of this mailing list. End up finding a really old (posted in 2004) thread by someone signed as 'J', directing to a link sort of like http://tutorbuddy.com/software/phpcpp. I guess this might be what I need, but the article seems already out of date. I've found a translated version of this article, and made a testing extension following the instructions, however it didn't work. The article was written for PHP 4.2.X, and the sample code is missing (the link is broken). I'm currently working with PHP 5.2.5. Is it because PHP 5.2.5 is really different with 4.X? Or the document was not properly translated? Can someone be so kind to point me an URL of this original article? Thank you all! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
Hi Marcin,
Stan also requested this, so it should be considered as a possibility.
Personally, I would rather not introduce this land mine. It requires
the user to do an implicit prepending of namespace name ("foo") to "bar"
in the use statement as well as a translation of "A", which could fast
lead to unreadable code.
It is probably best to simply require a fully qualified name where it is
intended. Thus
1) require leading "\" in use statements
2) allow "namespace\blah" in use statements, as this is a valid fully
qualified name.
Greg, I can't spot where does your example differ from what I and Marcin
suggested? Please explain.
As for the leading \ for fully qualified identifiers, well it's a necessary
evil. As you said yourself PHP is PHP, and we have unique constraints to
meet, we have no scopes, we have no compile time packaging of the resources,
and since we don't have meta files describing the namespace resources (wink
wink...), we should stick to a single-rule no-ambiguity system.
For me the only way to make it clear to both humans and parsers alike is the
filepath semantics, in all places, including use. It's not perfect, there's
no completely problem-free solution, but "prepend \ for absolute path" is
able to become muscle memory, while other mixed solutions I've seen are more
confusing and require more thinking: "wait in this context what was what?".
And there's one more pain point which I posted earlier on the list about,
but now as I prepare my framework for 5.3 namespaces, I *really* feel the
pain in practice: the inability to pass a class/function name without
specifying it fully as a string.
My suggestion was: use foo\bar\baz as alias;$name = nameof alias; //
$name == 'foo\bar\baz'
But this introduces a new keyword: nameof, which could clash with
function/class/constant "nameof" in existing source code. I could suggest
simply not having "nameof" and having direct assignment assign the class
name, but then we clash with constants which have the same name as the
class. So that's not doable either.
But it's definitely in-your-face issue while using namespaced code.
Regards, Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
