hi Sara!
On Tue, Oct 30, 2012 at 2:57 AM, Sara Golemon poll...@php.net wrote:
http://wiki.php.net/rfc/uconverter
Discuss!
Nice job!
Some comments, raw :) :
- the UCNV prefix is not necessary, we are in the UConverter class
already, I would simply use LATIN_1, or ILLEGAL for exampe.
- It is
btw, can you add the changes to config.w32 too pls? Pretty much the
same than in .m4, so I can add it to our CI and valid the RFC patch
in a more handy manner :)
On Tue, Oct 30, 2012 at 2:57 AM, Sara Golemon poll...@php.net wrote:
http://wiki.php.net/rfc/uconverter
Discuss!
--
PHP
Very nice work.
Bravo!
On 30/10/12 02:57, Sara Golemon wrote:
http://wiki.php.net/rfc/uconverter
Discuss!
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and
I would say that the proposed accessors is what we should have added back
then instead of __get/__set . The problem is that now we will have two
similar (albeit one is an ugly subset of the other) feature which needs to
co-exists.
My gut tells me that we should ditch the magic method approach with
Em 2012-10-30 2:57, Sara Golemon escreveu:
http://wiki.php.net/rfc/uconverter
Discuss!
Good work. I do, however, have some concerns:
* Error handling is done in a different way from the rest of the
extension.
Error handling in ext/intl is, admittedly, a little strange. Errors are
both
Hi Internals,
it's been a while since we started talking about PHP 5.5 and we are
already a little bit late with my release plans. I've started reviewing
the current master and came to the conclusion that it does make more
sense to me to branch 5.5 of master for a few reasons:
(1) Parts of
- the UCNV prefix is not necessary, we are in the UConverter class
already, I would simply use LATIN_1, or ILLEGAL for exampe.
- I would add ERROR_ to the error related constants (UNASSIGNED co), or?
For the UConverterType enum I could maybe get behind that. For
UConverterCallbackReason I
Hi!
http://wiki.php.net/rfc/uconverter
Discuss!
Looks nice. Some points:
1. transcode() accepts options, but there's no comparable way to set
options to the object. I think these APIs should be synchronized.
Imagine code keeping options in array/config object - it's be really
annoying to
1. transcode() accepts options, but there's no comparable way to set
options to the object. I think these APIs should be synchronized.
Imagine code keeping options in array/config object - it's be really
annoying to have two separate procedures to feed these to object and to
transcode().
Most of these utilities require admin user access to the server. For
example, Logrotate is normally run as a daily cron job
There are a lot of shared services that will not allow users to install or
run certain jobs.
How difficult will if be to add this feature to PHP? Will it require major
So? Non-administrative users should not be worrying about rotating log
files. Shared services have administrators who are keenly interested
in not running out of disk space due to silly things like log files
and provide rotation of them (or if not, you have a choice of better
providers who do).
On Tue, Oct 30, 2012 at 10:00 AM, d...@php.net d...@php.net wrote:
The rest looks fine to me. So I'll go ahead and start PHP-5.5 branch by
Thursday from current master. I know we then have 4 active branches
which is a pain to keep in sync and merge and I am open for suggestions.
Could we maybe
There are still use cases for __get(), when the list of internal
properties is dynamic. We're actually leveraging that for Drupal 8's
entity system. Removing it would be a big problem. :-)
But that still doesn't resolve the mental model question.
--Larry Garfield
On 10/30/12 3:05 AM,
Hi!
Stas, you seem to have missed the point behind my mail. This wasn't
about what the exact details of the implementation will be, the
message was that the semantics of a dedicated accessors syntax and the
semantics of a magic implementation can not match.
I see your point now, thanks, but
With the exception of renaming the UConverter::UCNV_* constants to
remove the UCNV_ prefix, I believe I've addressed the concerns thus
far. ((Waiting to hear if anyone else wants to weigh in on the
contants)) The RFC has been updated accordingly.+
--
PHP Internals - PHP Runtime Development
On Tue, Oct 30, 2012 at 10:52 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Stas, you seem to have missed the point behind my mail. This wasn't
about what the exact details of the implementation will be, the
message was that the semantics of a dedicated accessors syntax and the
Hi!
I'm not sure why you are expecting this, and also this is probably an
LSP violation, since such override would change semantics of the value
that A clients expect. It may be possible to implement, technically, but
I'm not sure it's the right thing to do.
Why would it be not expected
Would you say the same of unset? Always benign?
On 10/29/2012 2:14 PM, Stas Malyshev wrote:
Hi!
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this-b = $x; }
}
}
$o = new a();
if(!isset($o-b)) {
/* delete files */
}
echo
18 matches
Mail list logo
