For what it's worth, I'm planning to update the RFC later today with
an updated SPL-less patch and the start of a Q&A section similar to
what we've had in the other RFCs. I'll send an e-mail when it's ready.
On 1 October 2010 04:28, Stas Malyshev wrote:
> It is not clear from the RFC, if the engi
On 1 October 2010 06:26, Stas Malyshev wrote:
>> Can we make it an operator-like (is_a for example) instead? It could
>> be more efficient.
>
> Operator has a downside that you can't pass it as a parameter. We could have
> something like <=> (spaceship operator!) or even cmp though :)
Yeah, I thi
Hi!
The bucket can store 2 types of data - either any random piece of data
(ARPD) or a pointer. When bucket with ARPD is created/deleted, the
memory storing ARPD is allocated/freed. When bucket holding a pointer is
created/freed, nothing special happens since the pointer is stored
inside the
Hi!
Can we make it an operator-like (is_a for example) instead? It could
be more efficient.
Operator has a downside that you can't pass it as a parameter. We could
have something like <=> (spaceship operator!) or even cmp though :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://w
hi,
On Thu, Sep 30, 2010 at 10:13 PM, Stas Malyshev wrote:
> I'd like var_compare().
> Quick search in google reveals cmp() being used in actual code, and
> compare() to some extent too, though mostly as method, so not really
> clashing.
Sounds good.
Can we make it an operator-like (is_a for e
Hi!
The RFC is at http://wiki.php.net/rfc/comparable, and the patch at
http://www.adamharvey.name/patches/comparable.diff.txt. Any and all
feedback welcome, particularly since I'm still learning my way around
the innards of the Zend Engine, and it's entirely possible (indeed,
likely) that I've o
Hi!
If I don't hear kicking and screaming in the next few days, I'll slip
this into trunk. I can provide a patch/RFC in advance if there's
demand, but it'll be about as simple as you imagine. :)
Sounds good.
The one thing that I would like bikeshedding^Wfeedback on is the name:
cmp() makes t
Hi!
Using __call() for this, quite honestly, sucks. You have to define it in
each and every class you write -- leading to code duplication -- or have
all your classes inherit from a common object -- leading to an
inheritance nightmare.
That's why we (will) have traits :)
Additionally, there
On 2010-09-30, Stas Malyshev wrote:
> > feels like this architectural decision -- separating properties and
> > methods into their own hash tables -- should be revisited. Most other
>
> Having properties and methods in the same hash would make zero sense,
> unless we convert all methods into clos
Hi!
feels like this architectural decision -- separating properties and
methods into their own hash tables -- should be revisited. Most other
Having properties and methods in the same hash would make zero sense,
unless we convert all methods into closures - which I currently don't
feel we ne
On Sep 30, 2010, at 7:14 AM, Johannes Schlüter wrote:
> On Thu, 2010-09-30 at 16:37 +0300, Adi Nita wrote:
>> Perhaps a better idea would be to group the ones that we already have
>> under a common namespace. But this is no news, though.
>
> Even then it would be unlikely that we add another spe
On Thu, 30 Sep 2010 16:25:28 +0100, Adam Harvey wrote:
The initial version of the patch actually did just that: it simply
modified zend_std_compare_objects. That's pretty much the cleanest way
you could do it. :)
(...) Additionally, there
are already semantics built into compare_function to ha
Am 30.09.2010 14:20, schrieb Matthew Weier O'Phinney:
On 2010-09-29, Stas Malyshev wrote:
Assigning a closure or
other invokable to a class should "just work" -- developers shouldn't
need to know how the Zend Engine works in order to understand the
behavior and limitations.
Another example is
On 30 September 2010 23:13, Gustavo Lopes wrote:
> That is, you would only modify zend_std_compare_objects (not
> compare_function!) and add there the additional logic where you'd check if
> the objects had the same class (or perhaps one was of a subclass of the
> other, in which case you'd use th
On Thu, 30 Sep 2010 14:33:05 +0100, Adam Harvey wrote:
I've just written an RFC (with a patch against trunk) to implement a
Comparable interface similar to that in Java — in effect, allowing
object instances to be compared with semantics defined in userspace.
This is admittedly at the lower end
On 30 September 2010 15:44, Adam Harvey wrote:
> Well, while I'm sending e-mails...
>
> Unrelated to the Comparable RFC, are there any objections to adding a
> function that simply wraps compare_function()? It's depressingly
> common to end up writing a construct like the following in comparison
>
(Omnibus reply, since Johannes's original e-mail hasn't yet dropped
into my ever-so-flaky mail setup. I have read it in full on
news.php.net, though.)
> On Thu, 30 Sep 2010, Johannes Schlüter wrote:
>> What is this "more interesting stuff to come"?
Nothing that's likely to be ready before the for
2010/9/30 Johannes Schlüter :
> On Thu, 2010-09-30 at 16:08 +0200, Kalle Sommer Nielsen wrote:
>> I think its a great addition, but I think the interface should be
>> defined within ZE like the other base interfaces that interact
>> directly with the language syntax (like Iterator) and not in SPL.
On Thu, 30 Sep 2010, Johannes Schlüter wrote:
> On Thu, 2010-09-30 at 21:33 +0800, Adam Harvey wrote:
> > All,
> >
> > I've just written an RFC (with a patch against trunk) to implement a
> > Comparable interface similar to that in Java — in effect, allowing
> > object instances to be compared wi
Well, while I'm sending e-mails...
Unrelated to the Comparable RFC, are there any objections to adding a
function that simply wraps compare_function()? It's depressingly
common to end up writing a construct like the following in comparison
callbacks, so I think we might as well encapsulate the pat
Completely agree. Adding another specialized string function wouldn't be
worth in this case. I was just trying to divert the attention :) to PHP
(still) not using namespaced functionalities even where it makes sense the
most (text / string, array etc.)
2010/9/30 Johannes Schlüter
> On Thu, 2010
On Thu, 30 Sep 2010 15:26:17 +0100, Johannes Schlüter
wrote:
On Thu, 2010-09-30 at 16:08 +0200, Kalle Sommer Nielsen wrote:
I think its a great addition, but I think the interface should be
defined within ZE like the other base interfaces that interact
directly with the language syntax (like
On Thu, 2010-09-30 at 16:08 +0200, Kalle Sommer Nielsen wrote:
> I think its a great addition, but I think the interface should be
> defined within ZE like the other base interfaces that interact
> directly with the language syntax (like Iterator) and not in SPL.
s/should/has to/
The engine shall
On Thu, 2010-09-30 at 21:33 +0800, Adam Harvey wrote:
> All,
>
> I've just written an RFC (with a patch against trunk) to implement a
> Comparable interface similar to that in Java — in effect, allowing
> object instances to be compared with semantics defined in userspace.
> This is admittedly at
On Thu, 2010-09-30 at 16:37 +0300, Adi Nita wrote:
> Perhaps a better idea would be to group the ones that we already have
> under a common namespace. But this is no news, though.
Even then it would be unlikely that we add another special purpose
function. This would have to be an important featur
Hi Adam
2010/9/30 Adam Harvey :
> All,
>
> I've just written an RFC (with a patch against trunk) to implement a
> Comparable interface similar to that in Java — in effect, allowing
> object instances to be compared with semantics defined in userspace.
> This is admittedly at the lower end of RFC-w
Perhaps a better idea would be to group the ones that we already have under
a common namespace. But this is no news, though.
Adrian
2010/9/30 Johannes Schlüter
> On Thu, 2010-09-30 at 15:11 +0200, Andre Baumeier wrote:
> > Am 05.09.2010 um 15:06 schrieb Johannes Schlüter:
> >
> > > preg_match(
All,
I've just written an RFC (with a patch against trunk) to implement a
Comparable interface similar to that in Java — in effect, allowing
object instances to be compared with semantics defined in userspace.
This is admittedly at the lower end of RFC-worthy proposals, but it's
a good system, and
On Thu, 2010-09-30 at 15:11 +0200, Andre Baumeier wrote:
> Am 05.09.2010 um 15:06 schrieb Johannes Schlüter:
>
> > preg_match('/PHP (.*) swesome/', 'PHP is awesome', $matches);
> >
>
> preg_match should be slower?
Was that a question or a statement?
I doubt it is really measurable and not wort
Am 05.09.2010 um 15:06 schrieb Johannes Schlüter:
> preg_match('/PHP (.*) swesome/', 'PHP is awesome', $matches);
>
preg_match should be slower?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2010-09-29, Stas Malyshev wrote:
> > public function __construct()
> > {
> > $this->a = new A();
> > $this->a();
>
> Here you are calling method a() of object $this. Such method does not
> exist. No bug here. Methods are properties are different things.
I completel
31 matches
Mail list logo
