On Fri, May 18, 2018 at 1:59 PM Rowan Collins
wrote:
> On 17 May 2018 10:35:11 BST, Etienne Kneuss wrote:
> >That said, if the plan is to subsume pecl-weakref, I suggest we also
> >reimplement weakmaps, which offer a convenient way of storing
> >meta/cache
> >data
On Thu, May 17, 2018 at 8:10 AM Joe Watkins wrote:
> Morning internals,
>
> I'd like to raise for discussion https://wiki.php.net/rfc/weakrefs
>
> Am I missing anything ?
>
I'm all for implementing all this natively, the way it was implemented in
pecl-weakref always felt hackish and brittle.
Th
On Fri, Feb 26, 2016 at 7:12 PM wrote:
> Hi,
>
>
> I'd be very thankful for a clear explanation on this:
> http://stackoverflow.com/questions/35656898
>
>
> May be it's just a word game and I don't understand it correctly, but
> documentation states one, though $object::$staticProperty works in a
On Mon, Aug 3, 2015 at 2:26 PM Alexander Lisachenko
wrote:
> Hello, internals!
>
> I like the idea to assign a custom identifier to the object, but why this
> should be only in the core? Java has a method 'hashCode' which can be used
> to return an unique identifier for specific object.
Java's
On Sat Feb 21 2015 at 21:08:39 Anthony Ferrara wrote:
> Zeev,
>
> I won't nit-pick every point, but there are a few I think need to be
> clarified.
>
> >> > Proponents of Dynamic STH bring up consistency with the rest of the
> >> language, including some fundamental type-juggling aspects that hav
On Wed Dec 17 2014 at 1:44:13 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Hi,
>
> Answering the question of Christopher Becker. It is not possible to
> traverse and get your desired elements.
> How would you achieve a foreach by key (returning object) without having to
> sto
itly.
>
Let me rephrase:
The small expressivity gain of omitting a call comes at a quite high (IMO)
cost in your implementation. I believe it is not worth it.
Comparing only one side of this equation with another feature makes no
sense.
Best,
--
Etienne Kneuss
-intuitive and counter-productive: one would expect
to find the object there, not its "hash".
As others noted, it also prevents a full-fledged objects-as-key
implementation in the future.
In the end it causes issues and brings very little compared to an explicit
call to convert an object to a key.
-1
--
Etienne Kneuss
https://wiki.php.net/phpng-upgrading should be completed to
reflect all changes.
It is only then that we can vote with knowledge of how much this big patch
affects the codebase.
Best,
--
Etienne Kneuss
Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
> Posted with an email client that doesn't mangle email: alpine
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
compiler produces tons of warnings on PHP source, I'm planning
> to get to them, probably next weekend.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
On Mon, Jun 10, 2013 at 1:47 PM, Pierre Joye wrote:
>
> On Jun 10, 2013 1:24 PM, "Etienne Kneuss" wrote:
> >
>
> > So if I understand correctly var_dump now indicates a different type than
> > what accessing the property returns?
> >
> > Even
On Mon, Jun 10, 2013 at 1:56 PM, Anatol Belski wrote:
> Hi Etienne,
>
> On Mon, June 10, 2013 13:24, Etienne Kneuss wrote:
> > On Fri, Jun 7, 2013 at 9:27 PM, Gustavo Lopes
> > wrote:
> >
> >
> >> On Fri, 07 Jun 2013 14:06:11 +0200, Derick Rethans
>
/int(437)
>
> So this applies only to var_dump() output, serialization output and
> something exotic as an array cast (which anyway has its own peculiarities
> wrt the key type conversion -- or the absence of it).
>
>
So if I understand correctly var_dump now indicates a different type than
what accessing the property returns?
Even if the change itself does not constitute a big BC break, this
behavior is confusing and seems like a big no-no to me.
--
Etienne Kneuss
://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
On Fri, May 24, 2013 at 5:32 PM, Ferenc Kovacs wrote:
>
>
>
> On Fri, May 24, 2013 at 5:26 PM, Etienne Kneuss wrote:
>
>> Sure the default implementation would have to be identical to the
>> behavior of not defining one.
>>
>>
> agree
>
>
>&
inked thread, personally I agree that those are
> different both in intention and implementation, so shouldn't affected by
> this change.
>
> ps: for example having an empty __sleep() or __wakeup implementation would
> be entirely differrent that one would expect.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>
--
Etienne Kneuss
http://www.colder.ch
ns to strings may not have been written
with support for exceptions in mind.
I guess the alternative approach is to allow exceptions, review the code
(i.e. a lot of work), and eventually fix reports as they come in.
Best,
--
Etienne Kneuss
gt; >> It's likely due to the precompiled nature of closures, vs the
> compilation
> >> happening multiple times at invocation in the preg_replace /e case.
> >>
> >> But it's still worth noting that switching from the /e style to a more
> >> traditional preg_replace_callback implementation will get you a
> >> significant
> >> boost in performance of that.
> >>
> >> Now, keep in mind, we're talking 0.05 seconds saved per "execution"
> >> (group of 6 replacements). So it's not likely to matter much or be worth
> >> worrying about...
> >>
> > Hey:
> > thanks for the benchmark, but please don't think it's useless just
> > because it's monior
> >
> > PHP is a web program language, let's think about a high trafiic site,
> > which get 100, 000, 000 pv perday.
> >
> > 100, 000, 000 * 0.005 = 500s perday
> >
> > and inefficent not always means performance only, in this case , you
> > need to define various functions for different regexs if you use loop
> style.
> >
> > and do you prefer array_walk or foreach when you try to iteraterly
> > process an array?
> >
> >
> > thanks
> >
> >>
> >> My $0.02 at least...
> >>
> >> Anthony
> >>
> >
> >
> >
> > --
> > Laruence Xinchen Hui
> > http://www.laruence.com/
> >
>
>
>
> --
> Laruence Xinchen Hui
> http://www.laruence.com/
>
--
Etienne Kneuss
http://www.colder.ch
stently no
> checkable literals or IDE support for anything.
>
>
We have User::class now instead of 'User'. You should use it, it makes it
easy to refactor and stuff.
More seriously:
I'm just saying you are arguing for a *new* syntax that would allow
something rarely used (I
hing, I'm sure "IDE support" is as easy
to implement with or without this new syntax.
Introducing new syntax must be done with extreme care, and so far this case
looks quite far from convincing.
> On Wed, May 1, 2013 at 10:24 AM, Etienne Kneuss wrote:
>
>>
>>
>
sterisk (or some other character) offers and easier
> > > implementation path, whatever.
> >
> > It doesn't. This is a fringe feature, as evidenced by the fact that you
> > are having a hard time convincing people that it is needed, and thus
> > shouldn't overload an existing operator. Visually it would be confusing
> > to take any well-known operator and give it a different obscure meaning.
> > But yes, syntax-wise ^ could be made to work, the implementation problem
> > I referred to is lower-level than that. Properties simply don't carry
> > this information with them so a lot of things would have to change
> > internally for this to ever work and if a clean implementation could be
> > found, like I said, adding it to the reflection functions is the proper
> > place.
> >
> > -Rasmus
> >
>
--
Etienne Kneuss
http://www.colder.ch
reateShape('circle');
> $circle->radius = 10;
> echo $circle->getArea();
>
> It would be great if this feature could be added to 5.5 :)
>
> __
> Raymond Irving
>
--
Etienne Kneuss
http://www.colder.ch
ype out typeof() may not be the most elegant approach,
> and using this syntax it does resemble a function - having a more distinct
> syntax might be better.
>
> But those things aside, what do you think about having a way to statically
> reference types and members?
> Thanks,
>Rasmus Schultz
>
--
Etienne Kneuss
On Tue, Feb 19, 2013 at 2:55 PM, Derick Rethans wrote:
> Gah, no top posting!
>
> On Tue, 19 Feb 2013, Etienne Kneuss wrote:
>
> > On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans wrote:
> >
> > > On Tue, 19 Feb 2013, Nikita Popov wrote:
> > >
&g
t; Posted with an email client that doesn't mangle email: alpine
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
> that references can be returned so multi-dimensional arrays can be properly
> unset aka:
> $ar = new ArrayObject(array('foo' => array('bar' => array('baz' =>
> 'foo';
> unset($ar['foo']['bar']['baz']);
>
> Regards,
>
> Mike
>
--
Etienne Kneuss
http://www.colder.ch
2. SplObjectStorage already solves this problem - minus e.g. resources,
> but
> > you could put your resources in an object and address that (very exotic)
> > need.
> >
> > Bottom line, I'm not in favor of this idea - it just doesn't seem
> necessary
> > or really even beneficial to me.
> >
> > - Rasmus Schultz
> >
>
--
Etienne Kneuss
http://www.colder.ch
foo() { $this->v = 2; } } class B
extends A {public foo() { $this->v = 4; }}
B should violate LSP, since the postcondition of B::foo() does not
imply postcondition of A::foo(). This is obviously not correct: this
code is fine.
Best,
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s aren't either - see discussion about interfaces,
> etc. They simulate regular properties but they aren't regular
> properties. E.g., what would happen if you serialize an object with
> simulated property?
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: ht
he idea of having generics, but I am not sure
> that the work it would take is worth it.
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ays as well (function
> foo(array $array){})...
This would require O(n) runtime tests, I would definitely not go there.
>
> On the other hand, the syntax leaves a lot to be desired. It's quite
> confusing and really is ugly. As far as how to fix the syntax, I'm not sure.
>
On Mon, Oct 15, 2012 at 10:07 PM, Etienne Kneuss wrote:
> On Mon, Oct 15, 2012 at 6:45 PM, Lester Caine wrote:
>> Etienne Kneuss wrote:
>>>
>>> I can understand why we might not want that in PHP in order to
>>> simplify the implementation, but it we follow l
On Mon, Oct 15, 2012 at 6:45 PM, Lester Caine wrote:
> Etienne Kneuss wrote:
>>
>> I can understand why we might not want that in PHP in order to
>> simplify the implementation, but it we follow logical reasoning I
>> can't see why we shouldn't implement th
be allowed because defining a property to
>>> satisfy the requirements of an accessor is not right.
>>
>> According to whom? In my opinion, not allowing a property to satisfy
>> the requirement of an accessor is wrong.
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t; set; }
}
is entirely fulfilled by the class:
class B extends A {
public $a;
}
You can see a public property as an underlying private property with
all usual public accessors defined.
>From the point of view of the user both should be interchangeable
>transparently.
>
>&
equirements imposed by the interface A. (The same goes if A was a
class, BTW)
Is that the case in your current patch? (I couldn't find information
in your RFC nor in the tests on github)
If it is the case, I'm fine with having accessors and not plain
properties in interfaces.
Best,
>
> -Clint
--
Etienne Kneuss
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ference between going
>> trough an accessor and accessing a plain property is really relevant
>> in that context (especially as lazy-loading would have required a
>> method otherwise).
>>
>> What I'd rather see is the reverse behavior: An accessor property
>> shadows a plain property, so that the plain property is only
>> accessible from within the accessor methods. This would allow you to
>> write code like in the last example above and I think it would also
>> make automatic properties more meaningful (you could store the state
>> in a property with the same name; also nicely integrating with
>> serialization and debugging).
>>
>> I know that you (Clint) want to create a hard distinction between
>> plain properties and accessor properties, but I think that making it
>> more smooth juts integrated better with PHP. I already noticed several
>> people who, after reading the RFC, tried to write code where they
>> access the property from within the accessor. It seems to me that
>> people think it should work. The current behavior where you can shadow
>> the accessor property by assigning a property of the same name seems
>> rather obscure to me.
>>
>> This is the feedback I have for now. Looking forward to your thoughts
>> on the manner.
>> Nikita
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
name; also nicely integrating with
> serialization and debugging).
>
> I know that you (Clint) want to create a hard distinction between
> plain properties and accessor properties, but I think that making it
> more smooth juts integrated better with PHP. I already noticed several
> people who, after reading the RFC, tried to write code where they
> access the property from within the accessor. It seems to me that
> people think it should work. The current behavior where you can shadow
> the accessor property by assigning a property of the same name seems
> rather obscure to me.
>
> This is the feedback I have for now. Looking forward to your thoughts
> on the manner.
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t; /home/nikic/dev/php-src/t29.php on line 13
> NULL
>
> =
>
> I feel like this approach to the implementation will be a big can of
> worms. Sure, it works, but it is rather fragile and the enduser ends
> up dealing with internal stuff which he ought not care about. I thin
*if* we wanted it...
Even though it's not really useful, we should have it for the sake of
consistency.
As long as it doesn't cause major technical complications to
implement, I don't see why we shouldn't have that available.
Best,
--
Etienne Kneuss
--
PHP Internals - PH
op;
Even though Plop might only be contained in one of those namespaces,
PHP does not necessarily know, and it doesn't know whether to try
\Plop, Foo\Plop, or Bar\Plop.
This problem is of course non-existent in other languages supporting
wildcard imports, because the set of imported classes is finite and
well known, which means that conflicts can be detected right away.
Best,
--
Etienne Kneuss
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ot;=>150, "banana"=>300, "lemon"=>300}
> ruby-1.9.2-p180 :008 > h.delete_if { |k,v| v==300 }
> => {"apple"=>150}
>
> May be we should have something like
>
> array_delete_if($array, function($v, $k=null) { if ($v == 300) return true; })
So array_filter?
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
gt;
> --
> Gustavo Lopes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
IMHO we should really rethink the "let's not throw exceptions from the
engine/normal code so that people don't have to learn them"
--
Etienne Kneuss
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
it over.
It seems it has already been taken over: https://github.com/zenovich/runkit
--
Etienne Kneuss
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Clint,
On Wed, May 2, 2012 at 3:23 PM, Clint Priest wrote:
> Anyone have any help with this?
hard to say like this with this partial patch, do you have some git
branch I can pull from to reproduce and analyze this?
Alternatively, the complete an up-to-date patch?
Best Regards,
--
PHP Inter
which is unnexpected for isset
2) return true, which is also unexpected.
I don't see much point in that.
Best regards,
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hrough the source code, I found Z_DELREF_P. Would this be the correct
> macro to call? Is there anything else to keep in mind when calling it?
You should use zval_ptr_dtor instead. it will delref and free in case
the refcount hits 0.
Best,
>
> thx
--
Etienne Kneuss
http://www.co
of WS changes that you should probably fix.
Best,
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
11"
>
>
> -Original Message-
> From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne Kneuss
> Sent: Friday, April 13, 2012 3:27 PM
> To: Dmitri Snytkine
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] Ability to assign new object to a class prope
; E-Mail: dsnytk...@ultralogistics.com
> Web: www.ultralogistics.com
>
> "A Top 100 Logistics I.T. Provider in 2011"
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to use this kind of formula, but I realised It neither improves
> performance nor readability, especially if you want to use $result after
> the if statement.
>
>>
>> You can do something similar with empty():
>>
>> if (empty($values = $this->getValues()) {
>>
t believe it is useful though: people that know
what empty() really does can use "!expr" when expr is not a variable,
which is less confusing, especially for strings.
Best,
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
directly in such cases.
Best,
>
>
>
> Dmitri Snytkine
> Web Developer
> Ultra Logistics, Inc.
> Phone: (888) 220-4640 x 2097
> Fax: (888) 795-6642
> E-Mail: dsnytk...@ultralogistics.com
> Web: www.ultralogistics.com
>
> "A Top 100 Logistics I.T. P
e actual clear functionality.
>
> Patch attached to this email, made using 'svn diff'
>
> - Paul Dragoonis.
>
> On Sun, Jan 8, 2012 at 4:38 PM, Etienne Kneuss wrote:
>> Hi Paul,
>>
>> On Sun, Jan 8, 2012 at 16:32, Paul Dragoonis wrote:
gt; RETURN_TRUE;
> }
>
>
> Can someone help me out?
Is that all the modifications you did to the code? If not, could you
please attach a patch.
I will take a look.
Best,
>
> Thanks,
> Paul Dragoonis.
>
> --
> PHP Internals - PHP Runtime Development Mailing Li
Hi,
On Jan 7, 2012 10:41 AM, "Sebastian Bergmann" wrote:
>
> Am 07.01.2012 10:34, schrieb Stas Malyshev:
> > Why you need to add $this there? $this should be available automatically
> > IIRC unless you make the closure static.
>
> That is not the point I wanted to make. Explicitly listing $this
lso impose a security threat to other application that rely on the
> entropy source.
In essence there should only be the need for one random number per
request, so it should be fine in that regard.
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
or version.
Best,
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ther terms, arguments' types should be contra-variant. Currently PHP
expects them to be invariant, but there is already an RFC discussing how to
extend it:
https://wiki.php.net/rfc/prototype_checks
Best,
>
> Julien.Pauli
>
--
Etienne Kneuss
http://www.colder.ch
versions work as before. It doesn't bring much to return an empty string
instead of the first char. I believe every case should work as before,
throwing a notice is enough IMO.
Also, you don't mention whether your patch modifies the behavior of
isset(), is $str = "foo"; isset($str['bar']) true or false ?
Best,
> >>
> >
> > I think that those changes are pretty much in line with the discussion
> that
> > we had.
> > Thanks for fixing this!
> >
> >
> > --
> > Ferenc Kovács
> > @Tyr43l - http://tyrael.hu
>
>
>
> --
> Laruence Xinchen Hui
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
ot
> bring a lot of benefits to PHP (given the actual usage of this
> syntax). I would go with a revert, add tests and never change this
> behavior again. It is a confusing enough topic.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
5_4, makes everything
less magic and more consistent.
>
> Thanks,
>
> --Dan
>
> --
> T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
> data intensive web and database programming
> http://www.AnalysisAndSolutions.com/
> 40
ata intensive web and database programming
> http://www.AnalysisAndSolutions.com/
> 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.ph
Nikita
>>
>> [1]: https://bugs.php.net/bug.php?id=60039
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ds;
>
> public function __construct($Seconds) {
> $this->Seconds = $Seconds;
> }
> public $Hours {
> get {
> return $this->Seconds / 3600;
> }
> /* set { $t
7;t expect it to issue a Notice if I do $var == "asd" and
$var turns out to be an array. But then again, it's not the question
here.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Nov 2, 2011 4:05 PM, "Stas Malyshev" wrote:
>
> Hi!
>
>
>> In such cases, the notice actually seems fine to me. This is typically
>> the cases where you want to inform the user that he probably did
>> something wrong...
>
>
> In this specific case, I would say notice is not needed - it is obvio
s
In such cases, the notice actually seems fine to me. This is typically
the cases where you want to inform the user that he probably did
something wrong...
>
>> --
>> Stanislav Malyshev, Software Architect
>> SugarCRM: http://www.sugarcrm.com/
>> (408)454-6900 ext. 22
xplain better why I think it's an issue, and why the patch is
> needed?
>
> An indication as to if anyone is reviewing the proposed patch, and
> considering applying it, or telling me that this is the completely wrong
> approach to solve the problem and dropping a few hints would be
C); } ctor_arguments { zend_do_end_new_object(&$3, &$4, &$7
> TSRMLS_CC); zend_do_extended_fcall_end(TSRMLS_C);
> zend_do_end_variable_parse(&$1, BP_VAR_W, 0 TSRMLS_CC); $3.u.EA.type =
> ZEND_PARSED_NEW; zend_do_assign_ref(&$$, &$1, &$3 TSRMLS_CC); }
> | T_NEW class_name_reference {
> zend_do_extended_fcall_begin(TSRMLS_C);
> zend_do_begin_new_object(&$1, &$2 TSRMLS_CC); } ctor_arguments {
> zend_do_end_new_object(&$$, &$1, &$4 TSRMLS_CC);
> zend_do_extended_fcall_end(TSRMLS_C);}
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
n-private methods, since
> the method is open for extension, and as such is really declaring its
> own personal interface. For private methods, you can't override it
> anyway, so that's a non-issue from the start...
>
> That's my $0.02. I say leave it as is. The way
Hi,
On Mon, Sep 19, 2011 at 12:40, Etienne Kneuss wrote:
> Hi,
>
> On Mon, Sep 19, 2011 at 12:18, Gustavo Lopes wrote:
>
>> Em Mon, 19 Sep 2011 10:56:03 +0100, Etienne Kneuss
>> escreveu:
>>
>>
>>
>>> Apparently you guys are speaking about t
Hi,
On Mon, Sep 19, 2011 at 12:18, Gustavo Lopes wrote:
> Em Mon, 19 Sep 2011 10:56:03 +0100, Etienne Kneuss
> escreveu:
>
>
>
>> Apparently you guys are speaking about the initial implementation of an
>> abstract method, while I was talking about overriding a method
that we are currently diverging from the theory, so we should
have a BIG gain of doing so, not the opposite.
>
> --
> Gustavo Lopes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
p://blog.mageekbox.net/public/cv.frederic.hardy.pdf>
> Blog : http://blog.mageekbox.net
> Twitter : http://twitter.com/mageekguy
> ==**==**
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
Hi,
On Mon, Sep 19, 2011 at 11:28, Etienne Kneuss wrote:
> Hi,
>
> On Mon, Sep 19, 2011 at 11:19, Pierre Joye wrote:
>
>> On Mon, Sep 19, 2011 at 11:12 AM, Stas Malyshev
>> wrote:
>> > Hi!
>> >
>> > On 9/19/11 2:02 AM, Pierre Joye wrote:
| http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
Blog : http://blog.mageekbox.net
> Twitter : http://twitter.com/mageekguy
> ==**==**
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
extends C { function g(A $a) { } }
>
> * Allow extra parameters with a default value (implemented):
>
> class C { function g($a) {} }
> class D extends C { function g($a,$b=true) { } }
>
> --
> Gustavo Lopes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
reason not to allow it to do that. There's no "act" that makes B
> incompatible with A here, this warning is completely useless.
>
Right, In this very specific case the error should not be outputted, the
check could be refined to let that pass. Just it it may be refined to handle
contravariant typehints correctly
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
--
Etienne Kneuss
http://www.colder.ch
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
> >
> >
> > --
> > Ferenc Kovács
> > @Tyr43l - http://tyrael.hu
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> --
> Laruence Xinchen Hui
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
due to the
> >> > enforced signature), this would seem to break things on a different
> >> > front (I can't docblock non defined parameters for examples).
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
>
>
>
> --
> Laruence Xinchen Hui
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
needed.
> Does anybody has an idea if on this case, about ArrayAccess vs
> setter/getter ?
> For example, wouldn't people expect "foreach" to work when $wm[] access is
> possible ?
> Personally, I like the current syntax, it's short. I'm just wondering of
> any corner case exists?
>
I'll probably make it iterable in the future, yes.
Best,
>
> Nicolas
>
--
Etienne Kneuss
http://www.colder.ch
27;t understand how the code you just gave would be useful in practice?
I've implemented a WeakMap class in the weakref pecl ext, see:
http://svn.php.net/viewvc/pecl/weakref/trunk/tests/weakmap_001.phpt?revision=316293&view=markup
for an example of usage.
I believe this better fit
Hi,
On Sat, Sep 3, 2011 at 17:14, Lars Schultz wrote:
> Am 03.09.2011 13:56, schrieb Etienne Kneuss:
>
>> Indeed, I planned to implement that as well, I haven't had the time to do
>> it
>>
>> yet though. It should happen in the following weeks.
>>
> > A discussion for bundling it might occur in the future, but given the
> > feedbacks PECL might very well be the right place for it.
>
> that mail was sent on Aug 9.
>
right :) why did I feel Aug 9 was 2 days ago ? Time flies...
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>
--
Etienne Kneuss
http://www.colder.ch
t;> optimizing :)
> >>
> >
> > Of course. I am not saying that its a must have...just wanted to defend
> it
> > from being marked as useless.
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
--
Etienne Kneuss
http://www.colder.ch
;t move our project to 5.3 yet because of a BC issue) i had
> to
> > manually clear those cycles before dropping the last userland reference
> to
> > the tree of objects because otherwise I'd run into memory problems when
> > processing alot of those trees.
> >
> >
> > --
> > 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
>
>
--
Etienne Kneuss
http://www.colder.ch
the past couple of weeks, the patch
was in fact intentional and we decided not to revert it.
Best,
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
On Thu, Aug 25, 2011 at 14:54, Etienne Kneuss wrote:
> Hi,
>
> On Thu, Aug 25, 2011 at 14:49, Sebastian Bergmann wrote:
>> On 08/25/2011 02:47 PM, Kalle Sommer Nielsen wrote:
>>>
>>> Speaking of which, wouldn't it be easier to check all our internal
>
http://thePHP.cc/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
On Thu, Aug 25, 2011 at 14:43, Sebastian Bergmann wrote:
> On 08/25/2011 02:39 PM, Etienne Kneuss wrote:
>>
>> To me this feature makes no sense. But if people find use for it and
>> it remains in Reflection, I won't object to it, so +0.
>
> It should only
pal Consultant
> http://sebastian-bergmann.de/ http://thePHP.cc/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
one liner patch to the report, which like
>> Hannes said, should go into 5.3.8 to keep BC.
>>
>> --
>> regards,
>>
>> Kalle Sommer Nielsen
>> ka...@php.net
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubsc
nderlying implementation now
allows a string as first argument for is_a as well.
Conclusion: it is now consistent, but if you wrongly used is_a with a
string before, it now triggers autoload because it actually accepts
it.
Best,
> --
> Mads Lie Jensen - m...@gartneriet.dk - ICQ #25478403
>
t curious, when I use
> namespaces, but it looks into the global scope first.
>
> Regards,
> Sebastian
>
> Am 06.08.2011 13:15, schrieb Ferenc Kovacs:
>>
>> Hi.
>>
>> I would like to introduce this RFC which would provide function
>> autoloading throu
://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
gt; array(0) {
> }
> array(0) {
> }
>
> array(0) {
> }
> array(0) {
> }
>
>
> Thanks,
>
> -Chris
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
1 - 100 of 273 matches
Mail list logo
