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 (int)
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 ex
On Tue, Oct 30, 2012 at 10:52 PM, Stas Malyshev 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
>> semantics of a magic
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 Mail
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, b
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, Ferenc
On Tue, Oct 30, 2012 at 10:00 AM, 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 do the sam
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).
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
chan
> 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().
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
> - 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
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 maste
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 sto
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
15 matches
Mail list logo
