oint is that I don't believe parent:: should be considered
'fully established' to use Etienne's terminology.
-Mike Lively
> On Sun, 2007-11-18 at 14:21 +0100, "Etienne Kneuss" wrote:
>
>> Hello,
>>
>> this very subject was already discussed in a
Stanislav Malyshev wrote:
>> I realize that instance calls are a completely different ball game than
>> static calls but LSB was supposed to give us the same flexibility.
>
> Actually, I don't think it was. If you want objects, why not use the
> real thing? LSB was created to solve just one parti
Jochem Maas wrote:
> Stanislav Malyshev wrote:
>
>>> Rest assured that this is not the bad kind of 'more complex' I believe
>>>
>> I'm afraid I must disagree. The feature that was missing was to know the
>> true calling class name. That was implemented. You can build from it,
>> there's n
Lukas Kahwe Smith wrote:
>
> On 19.11.2007, at 14:24, Alexey Zakhlestin wrote:
>
>> On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
>>>
>>> On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:
>>>
On 11/19/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> I think the point of
Lukas Kahwe Smith wrote:
>
> actually i do not think this is obviously more intuitive than what we
> currently have. also that would introduce BC issues. so i think adding
> some new magic constants (if they are not yet added) would probably
> solve the situation more or less, plus you have self:
Stanislav Malyshev wrote:
>> in that situation A::find(); would not be able to know it was being
>> called by B::find() because parent:: is considered an explicit class
>> name reference.
>
> It will be, just not by means of parent::.
I am missing somethingthen by what means?
--
PHP Interna
Stanislav Malyshev wrote:
in that situation A::find(); would not be able to know it was being
called by B::find() because parent:: is considered an explicit class
name reference.
>>> It will be, just not by means of parent::.
>> I am missing somethingthen by what means?
>
> By me
Stanislav Malyshev wrote:
>>parent::test();
>
> What do you want parent::test() to mean?
>
>> This will echo 'A'. So like I said you have no way here of telling that
>> B:: was used.
>
> Because it wasn't. parent::test() means A::test(). 'parent::' means
> 'parent class of the class where t
Jingcheng Zhang wrote:
> Well, yes, "private" denies accessing from other class(including its child
> class), this is what "encapsulation" means. But when refering to
> inheritance, why forbids private properties/methods being *extended* to
> child classes? This is what I mean, as the following exa
ional type hinting would actually be solved by just introducing
type hints for 'scalar' (read string or int) and 'resource'.
- Mike Lively
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, 2008-01-05 at 21:35 -0500, Sam Barrow wrote:
> On Sat, 2008-01-05 at 15:59 -0800, Mike Lively wrote:
> > > Because type hinting is supposed to limit what kind of variable type
> > > is
> > > allowed for a parameter. When you magically convert you kill the
On Sun, 2008-01-06 at 10:55 -0500, Sam Barrow wrote:
> function requireFile(string $file, bool $getOutput = false, array $args
> // ...
> This function will not be called using input data.
>
So is there some way you are ensuring that users of your code NEVER pass
a value that trickled down from
On Thu, Mar 6, 2008 at 10:10 AM, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> recently there were quite a few proposals about stuff for 5.3. If we
> implement
> them all we won't finish in a "soonish" time and we get new ideas
> postponing
> the 5.3 release therefore the following:
On Mon, Mar 10, 2008 at 9:49 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > One thing that never really was resolved were the patches I submitted as
> a
> > compromise to some of the early disagreements about late static binding.
>
> I don't think it's a good ideas as it changes the
On Mon, Mar 10, 2008 at 6:41 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> I must be misunderstanding the patch then - doesn't it change behavior
> of the engine so that parent:: doesn't mean "parent of __CLASS__"
> anymore? If so, could you explain again what it does?
Of course parent:: s
On Tue, Mar 11, 2008 at 4:31 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> IMO, better solution would be to have all :: calls change
> called_class, but have also some way to call it without changing
> called_class. Something like your forward_static_call, but I'm not sure
> not using callba
On Tue, Mar 11, 2008 at 8:42 PM, Mike Lively <[EMAIL PROTECTED]> wrote:
> If this could be overcame I think it would be relatively easy to
> consolidate this code internally. I will look at it this evening and
> tomorrow.
>
New patches can be found at
http://www.digitalsa
On Thu, Mar 13, 2008 at 6:48 AM, Mike Lively <[EMAIL PROTECTED]> wrote:
>
> New patches can be found at
> http://www.digitalsandwich.com/Patches/index.html
>
> I have fixed the forward_static_call (I am not attached to the name and am
> open to suggestions) patch to use a
On Tue, Mar 18, 2008 at 4:04 PM, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
> Hello,
>
> the forward_static_call looks like a decent non-intrusive solution,
> and your patch looks
> good from what I can tell! I guess you should commit it so it can be
> documented and all.
If by 'you' you mean me.
committed before a 5.3 beta.
The parent forwarding patch can also still be looked at here:
http://ds-o.com/Patches/index.html
- Mike Lively
On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena <[EMAIL PROTECTED]> wrote:
> - PHP types
>
> function (string) foo(...) { } // Unicode string too
> function (object) foo(...) { } // Strict
> function (array) foo(...) { } // Strict
> function (bool) foo(...) { } // Strict
> function(int) foo(...
Maintenance on runkit/classkit. I've talked with pollita and she seems happy
about it ;)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Apr 18, 2008 at 10:40 AM, Kalle Sommer Nielsen <[EMAIL PROTECTED]>
wrote:
> Hey Internals
>
> I've been wondering for quite some time why PHP doesn't allow you to
> access
> arrays when you assign it to a value like in Javascript:
My opinion on features such as this is that they provide
ations belong there.
I agree with you in that I don't think the speed really matters much in this
case (though maybe I am wrong?). I am looking at this issue purely from the
usability and expectation standpoint.
-Mike Lively
On Fri, Jun 20, 2008 at 5:51 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>
> Didn't we discuss that already?
It was discussed but there was never any kind of agreement nor was there
ever any kind of vote. The only reason the discussion stopped is that I
wanted to be sure SOME way of forward
On Mon, Jun 23, 2008 at 2:16 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:
> and the same is not true of parent::? besides which I doubt any same code
> would actually break if the semantics of self:: changed, much less than
> if parent:: changed at any rate.
>
The behavior of the parent:: as it rel
-- Forwarded message --
From: Mike Lively <[EMAIL PROTECTED]>
Date: Tue, Jul 8, 2008 at 6:23 AM
Subject: Re: [PHP-DEV] Re: parent:: forwarding
To: Dmitry Stogov <[EMAIL PROTECTED]>
On Tue, Jul 8, 2008 at 4:39 AM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
>
Antony,
I don't at all disagree about the inappropriateness of this not triggering
an error but I did want to point out that this behavior is not consistent
with how __get() works. It seems like they should all behave similarly when
dealing with overriding methods or properties of different access
for an existing
one. No changes were made to self:: or parent:: so the change should be
pretty transparent. The only thing that I see remotely causing any
issues would be the new function (get_caller_class().) I added that just
to complete the set so to speak.
--
Mike Lively (ds- on irc.
creep into php I would be very sad.
--
Mike Lively (ds- on irc.efnet.org)
On Fri, 2006-02-24 at 14:05 +, [EMAIL PROTECTED] wrote:
> Hi all.
>
> I'm using php 5.1.2 compiled from source, with Apache 2.2.0
> and MySQL 5.0.18 on SuSE Linux 9.2 pro.
>
> I really
Hallo,
Firstly thanks for the comments. In regards to storing caller_scope in
op_array: the arguments against this make perfect sense. I am still
figuring out all of the nuances of the zend engine...so, equate it to
rookie mistake :P.
I've tried rewriting the patch to use zend_execute_data to sto
Hello,
On Thu, 2006-03-02 at 14:21 -0500, Jeff Moore wrote:
> On Mar 2, 2006, at 11:33 AM, Mike Lively wrote:
>
> Hi Mike,
>
> > In regards to naming: 'static' wasn't my first choice either. In fact I
> > was originally using 'this::' due to me
I am guessing he is referring to the fact that it becomes increasingly
likely that you will have more interfaces declaring __construct. If any
two interfaces declare construct with a different signature then by
definition those two interfaces will be incompatible.
It just means that interface auth
Just a silly little brainstorm
What about moving those functions to a separate php extension where they
can eventually be phased out? At least at that point you can get it all
out of the core but still provide an easy way for people who need the BC
to have it. (is there already a deprec extens
On Tue, 2006-03-07 at 12:28 +0300, Dmitry Stogov wrote:
> Hi,
>
> Because of some confused people I reverted "break label" patch and post it
> for discussion once again together with GOTO patch.
>
> Please reviw and vote.
>
> 1) goto and break label
> 2) goto only (like C)
> 3) break label only
On Wed, 2006-03-01 at 17:37 +0300, Dmitry Stogov wrote:
> 1) I would very like to see some real example where "static" is necessary?
>
> 2) "static" is really bad name. I suggest "caller", Marcus thought about
> "class".
>
> 3) I COMPLETELY DISAGREE TO ADD RUNTIME DATA INTO
> zend_function/zend_o
till support for it among
the core developers I would be interested in taking up the issue again,
reviewing and ensuring the most recent patch is still adequate as it
relates to head, and determining the performance impact of the patch.
--
Mike Lively
http://www.digitalsandwich.com
--
PH
37 matches
Mail list logo
