[PHP-DEV] Potential PC conflict.
Hi. [1] vs [2] Not asking for a change or anything. Regards, Richard. [1] http://svn.php.net/viewvc?view=revisionrevision=277701 [2] http://www.urbandictionary.com/define.php?term=mongoid -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Potential PC conflict.
On 8 November 2010 19:00, Richard Quadling rquadl...@gmail.com wrote: [1] vs [2] Not asking for a change or anything. I think it's probably OK the way it is: the manual page is specifically for MongoId, and the capitalisation's quite distinct from any other meaning there. The URL might be a touch unfortunate, but I don't think it's worth worrying about, personally. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Potential PC conflict.
On 8 November 2010 11:32, Adam Harvey ahar...@php.net wrote: On 8 November 2010 19:00, Richard Quadling rquadl...@gmail.com wrote: [1] vs [2] Not asking for a change or anything. I think it's probably OK the way it is: the manual page is specifically for MongoId, and the capitalisation's quite distinct from any other meaning there. The URL might be a touch unfortunate, but I don't think it's worth worrying about, personally. Adam And probably all sane, rational people will agree with you (and me). It's the loonies I worry about! Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Feasibility of additional support around constants.
Hi.
Some extensions provide a lot of constants. Currently, there is no
mechanism to group related constants.
Whilst many constants are prefixed with the extension name, within
that group, there is no standardised way to further group them.
Also, there is no way to reverse the mechanism. From a value, what is
the constant's name that would have been used in userland code?
It would be useful to have the ability to
tag/group/block/enum/const-array/etc. to form a collection of
constants so that from userland, you can easily identify the name of
the constant you have received.
I suppose, this is mainly useful where the userland code is a layer of
some sort, something that has to validate or extrapolate values
further down the chain and report back on them.
There are 3 main uses I can think of which would be useful.
1 - Validating that the value received is in a collection of known
constants. This would allow for new constants to be added without the
layer having to be amended to verify the value. If it isn't in the
group - it's invalid.
2 - For a constant value, report back the actual name of the constant.
The user supplied the value of 4 to the function. The function failed
for some reason and in the ensuing exception report, showing the name
of the constant would be extremely useful. Not all the extensions
document the value of the constants, so knowing what 4 is in't
instantly available.
3 - If the collection is a set of bitmasks (error_reporting for
example), then report back the constants that make the value.
This can all be done in userland code with some degree of simplicity,
but amending the code for each new constant seems that it should be
unnecessary.
Now, you may think, why not use Reflection? Yes. I have done that but
you can't easily group the constants. There are many constants set to
the value of 2 (for example).
All of these are from the standard extension.
Constant [ integer CONNECTION_TIMEOUT ] { 2 }
Constant [ integer INI_PERDIR ] { 2 }
Constant [ integer PHP_URL_PORT ] { 2 }
Constant [ integer PHP_ROUND_HALF_DOWN ] { 2 }
Constant [ integer INFO_CREDITS ] { 2 }
Constant [ integer CREDITS_GENERAL ] { 2 }
Constant [ integer ENT_COMPAT ] { 2 }
Constant [ integer STR_PAD_BOTH ] { 2 }
Constant [ integer PATHINFO_BASENAME ] { 2 }
Constant [ integer LC_CTYPE ] { 2 }
Constant [ integer SEEK_END ] { 2 }
Constant [ integer LOCK_EX ] { 2 }
Constant [ integer STREAM_NOTIFY_CONNECT ] { 2 }
Constant [ integer STREAM_NOTIFY_SEVERITY_ERR ] { 2 }
Constant [ integer STREAM_FILTER_WRITE ] { 2 }
Constant [ integer STREAM_CLIENT_ASYNC_CONNECT ] { 2 }
Constant [ integer STREAM_CRYPTO_METHOD_SSLv23_CLIENT ] { 2 }
Constant [ integer STREAM_SHUT_RDWR ] { 2 }
Constant [ integer STREAM_PF_INET ] { 2 }
Constant [ integer STREAM_SOCK_DGRAM ] { 2 }
Constant [ integer STREAM_PEEK ] { 2 }
Constant [ integer FILE_IGNORE_NEW_LINES ] { 2 }
Constant [ integer FNM_PATHNAME ] { 2 }
Constant [ integer PSFS_PASS_ON ] { 2 }
Constant [ integer PSFS_FLAG_FLUSH_CLOSE ] { 2 }
Constant [ integer LOG_CONS ] { 2 }
Constant [ integer EXTR_PREFIX_SAME ] { 2 }
Constant [ integer SORT_STRING ] { 2 }
Constant [ integer ASSERT_CALLBACK ] { 2 }
Constant [ integer STREAM_IGNORE_URL ] { 2 }
Constant [ integer STREAM_URL_STAT_QUIET ] { 2 }
Constant [ integer STREAM_OPTION_READ_BUFFER ] { 2 }
Constant [ integer STREAM_BUFFER_FULL ] { 2 }
Constant [ integer IMAGETYPE_JPEG ] { 2 }
Constant [ integer DNS_NS ] { 2 }
I think that extending the struct _zend_constant to include a constant
group number in addition to the existing module number, should be
enough in terms of storage (an extra int per constant). The
REGISTER__CONSTANT macros and their module specific clones would
been to be extended to allow for the constant group property to be
set, though a mechanism to supply a default for the constant group
would be a good thing I think so that untouched extensions still
report their constants as belonging to the to the unassigned group.
I guess that covers the ground work.
There would need to be a few new built-in functions to allow access to
the name and for the decomposition of the bitmask to its constituent
values.
Each extension would need to be amended to provide the additional
facilities - though, hopefully, this would be nothing more than adding
the constant group number to the constant creation macro call.
And the get_defined_constants() function could be amended to from ...
array get_defined_constants ([ bool $categorize = false ] )
to
array get_defined_constants ([ int $categorization_depth = 0])
where 0 is none, 1 is the same as true at the moment and 2 would be by
extension and then by each group.
If the additional grouping was alpha, rather than numeric, that would
help further I think (removing the magic numbers).
Is this anything that is ...
a - Useful
b - Doable
Regards,
Richard Quadling.
--
[PHP-DEV] Bug #52477
Hi all. I am investigate in the reason Bug #52477 (http://bugs.php.net/52477) and found that it appear because in PHP 5.2.14 there are two constant PS_DELIMITER and PS_UNDEF_MARKER. The value it's constants not allow to use in the root key of SESSION elements. Also in the version 5.2.0 was Bug #40274 (http://bugs.php.net/40274). For its decision the code has been added in PS_ENCODE_LOOP to pass elements with numerical keys. I not understand for what is necessary special algorithm for serialize roots elements. Why dont using php_get_session_var and php_var_unserialize functions for PS(http_session_vars) directly? Where i can read about it in manual? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Potential PC conflict.
On Mon, Nov 8, 2010 at 06:47, Richard Quadling rquadl...@gmail.com wrote: And probably all sane, rational people will agree with you (and me). It's the loonies I worry about! The person who submitted that is a mongoid. The term they were trying to be funny about is mongoloid, which is a racial classification that was a crude (but quasi-official) term referring to folks with Down Syndrome. -- /Daniel P. Brown Network Infrastructure Manager Documentation, Webmaster Teams http://www.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Potential PC conflict.
On 8 November 2010 17:25, Daniel Brown danbr...@php.net wrote: On Mon, Nov 8, 2010 at 06:47, Richard Quadling rquadl...@gmail.com wrote: And probably all sane, rational people will agree with you (and me). It's the loonies I worry about! The person who submitted that is a mongoid. The term they were trying to be funny about is mongoloid, which is a racial classification that was a crude (but quasi-official) term referring to folks with Down Syndrome. As an internet-scored, higher functioning autistic, I don't have the common sense to resent that remark.. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #52477
On Mon, Nov 8, 2010 at 1:33 PM, Alexandr Verbitsky verbitsky_alexa...@mail.by wrote: Hi all. I am investigate in the reason Bug #52477 (http://bugs.php.net/52477) and found that it appear because in PHP 5.2.14 there are two constant PS_DELIMITER and PS_UNDEF_MARKER. The value it's constants not allow to use in the root key of SESSION elements. Also in the version 5.2.0 was Bug #40274 (http://bugs.php.net/40274). For its decision the code has been added in PS_ENCODE_LOOP to pass elements with numerical keys. I not understand for what is necessary special algorithm for serialize roots elements. Why dont using php_get_session_var and php_var_unserialize functions for PS(http_session_vars) directly? Where i can read about it in manual? Hi, The special algorithm was necessary because the root keys could be used in session_register() as global variables, which have certain naming restrictions. This is no longer necessary since session_register() has been deprecated. I wrote a patch a while ago to use php_var_serialize but the complication emerged of adding a version number to the serialized string (otherwise migrating existing sessions is awkward). I haven't had time to work on it but can dig up the latest code if you'd like, it will be another few weeks until I can pick it up again. Regards, Arpad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: jharris
While I have experience in compiler, interpreter, and virtual machine development, I plan to work primarily on PDO-related items and cleanup. Sadly, that's all I have time for these days :( Regardless, I've submitted patches in the past--some have been applied, others are still pending; with your permission, this just seems to be an easier way to get some of the cleanup items accomplished more quickly. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feasibility of additional support around constants.
On Mon, November 8, 2010 6:33 am, Richard Quadling wrote:
1 - Validating that the value received is in a collection of known
constants. This would allow for new constants to be added without the
layer having to be amended to verify the value. If it isn't in the
group - it's invalid.
Generally-speaking, it's valid if it's between 0 and the largest
value, rather than being in an array/list...
And, yes, updating the code to check this is really hard, unless
you're smart enough to do something like:
define('FOO_0', 0);
define('FOO_1', 1);
.
.
.
define('FOO_42', 42);
define('FOO_MAX', 42);
and then your check is on FOO_MAX, which you update when you add
another constant.
2 - For a constant value, report back the actual name of the constant.
The user supplied the value of 4 to the function. The function failed
for some reason and in the ensuing exception report, showing the name
of the constant would be extremely useful. Not all the extensions
document the value of the constants, so knowing what 4 is in't
instantly available.
It doesn't really take a lot of effort to copy/paste the constant
names and echo out their values...
Not that you *should* do that, as those might change in a new release,
if there is some kind of meaningful order to those constants by name,
and one is INSERTED and they were never intended to be stored
externally, much less embedded in your code...
In fact, the whole point of USING constants will be violated by using
the magic number to reverse-engineer the name of the constant, if
you think about it for a bit.
3 - If the collection is a set of bitmasks (error_reporting for
example), then report back the constants that make the value.
Here the valid combinations may be subject to some
application-specific logic where the range would have holes in it...
E.g., 1 4 might be an invalid bitmask, where 12 and 18 is
perfectly valid... So I can see where this maybe needs a list of
known valid values, sometimes...
But the library itself should take care of this, and provide a
function to check the validity, not the app layer.
It's putting the burden on every single app that uses the library,
which is just fundamentally wrong.
Now, you may think, why not use Reflection? Yes. I have done that but
you can't easily group the constants. There are many constants set to
the value of 2 (for example).
If you don't know which extension generated the error in the first
place, you are in REAL trouble...
So just knowing the extension and 2 ought to tell you which constant
it is...
In the rare occasion where I felt the need to reverse-engineer this,
an array like $foo_constants[ FOO_1 ] = 'FOO 1'; did the trick for me.
And, yes, updating that when constants are added is somewhat painful,
but then you'll have to update SOMETHING somewhere to get meaningful
text out of it, unless you get the parser to just slap the first
parameter to define() into the zval...
So instead of a group number, you'd have the zval storing
'INFO_CREDITS' (for example) somehow for the 2 that goes with
phpinfo()...
a - Useful
Honestly, not really...
I can see why it looks useful at first, but it just violates too many
principles to implement, at least as you describe it...
And storing the constant name in the zval at the time of the define()...
Come to think of it, whatever 'defined' does to look up the answer
implies that PHP is already storing the constant name *somewhere*...
How you would tie that back to the value of the constant is beyond me,
but doing that in the 'define' C codebase that seems far more simple
than making up some new group number...
Of course, I'm not gonna be the guy writing that code :-)
b - Doable
Seems like a lot of effort for minimal benefit to this naive reader.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feasibility of additional support around constants.
*snip* Seems to me that some of this could be handled with a custom built function wrapping http://dk2.php.net/manual/en/function.get-defined-constants.php Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
