Fact: Adding a new name for a special kind of function as a syntax
construct is going to cost (possibly unnecessary) time and energy,
because now you have functions, and weird things that look almost like
functions but aren't and can only be used to make generators.
Just to put my oar in too, a
Tony Marston wrote:
> There is no set_up_language() function, and what has SquirrelMail got to do
> with PHP?
>
> Unless you can point to some official documentation on the PHP web site your
> "advice" is totally unsubstantiated and virtually worthless.
>
He was referring to set_up_language()
Tony Marston wrote:
> There is no set_up_language() function, and what has SquirrelMail got to do
> with PHP?
>
> Unless you can point to some official documentation on the PHP web site your
> "advice" is totally unsubstantiated and virtually worthless.
>
>
As for hints in the documentation, s
mathieu.suen wrote:
Sebastian Bergmann wrote:
Am 13.01.2010 12:18, schrieb mathieu.suen:
Because any optimization, even very simple ones, impose a performance
penalty in the default execution model of PHP which does not use a
bytecode cache.
For simple optimization I don't think so.
Richard Lynch wrote:
> For BC, I suppose PHP could have *both* 'a.b' and 'a_b'
+1 as a PHP user. For BC, I guess this should go without changing the
current precedence rules too, annoying though it might be.
At the moment: "?a_b=foo&a.b=bar" gives $_GET === array('a_b' => 'bar')
As I understand it
On 05/25/10 13:05, Thomas Nunninger wrote:
> - If you don't want to distinguish beetween strict and weak hints, create
> some
> ini setting that influences the behavior. (I'm not a fan of that.)
>
My £0.02 as a user: ini settings should NEVER influence the way the core
language works, as they
On 19/08/10 08:51, Stas Malyshev wrote:
> Hi!
>
> I recently noticed this code:
>
> error_reporting(E_ALL | E_STRICT);
>
> class ObjParent {
> public function set($param2 = ''){ }
> }
>
> class ObjChild extends ObjParent {
> public function set(){ }
> }
>
> produces a E_STRICT warning
On 19/08/10 09:13, Stas Malyshev wrote:
> Hi!
>
>> I was under the impression that, in order for inheritance to provide
>> proper polymorphism, overridden methods should share the parent's method
>> signature, although they can have additional optional arguments.
>
> Your impression is wrong. Over
On 10/14/10 12:04, Enrico Weigelt wrote:
> is it already possible to build the sapi modules separately ?
> I'd like to split them off into completely separate packages
> for easier systems maintenance.
Various distros already do this. See for example the Red Hat PHP RPM. It
depends which packagin
On 16/11/10 21:56, Alec wrote:
> [snip]
>
> attribute RestMethod('/do/something', 'Do Stuff', 'Does something.',
> array(
> 'arg1' => 'A cool argument!'
> ));
> public static DoSomething($arg1) {
> ...
>
> or
>
> attribute Example('arg', 'arg2', 3, (time() > 0 ? true : false));
> class Demo {
On 17/11/10 06:38, Will Fitch wrote:
> I like the idea, Alec.
>
> My only question is, syntactically, what difference would using a keyword,
> in this case "attribute", as opposed to brackets "[]"?
I would say that it provides better searchability -- it's easier for
people new to the feature to re
On 01/12/10 10:13, Lester Caine wrote:
> See other post as well
>
> Nathan Nobbe wrote:
>
>> git archive cranks out a single file representing any commit in the
>> repository, it can even format the archive w/ zip for the windows
>> folks ;)
> YES but without any header updates to the files.
> Onc
On 12/01/10 12:21, Lester Caine wrote:
> Dave Ingram wrote:
>>>> git archive cranks out a single file representing any commit in the
>>>> repository, it can even format the archive w/ zip for the windows
>>>> folks ;)
>>> YES but without any header
On 03/15/11 12:41, Ben Schmidt wrote:
> [snip]
>
> Hope this helps,
>
> Ben.
As an outsider in this discussion, I'd just like to applaud you for one
of the best, in-depth, most patient and most thorough explanations I
have ever seen on a mailing list.
Dave
--
PHP Internals - PHP Runtime Develo
On 04/19/11 15:44, Michael Morris wrote:
> watch ($var) -> $var is sent to the console on the line this statement is
> made with the statment "now watching 'var'.. init value "x", and then each
> time it changes it is updated in the console.
Just my 0.02 as a user, but it strikes me that watch() co
On 06/23/11 21:48, John Crenshaw wrote:
>> I think proposed change is extremely counter intuitive to the design
>> of PHP in regard to scoping and would be a very large bc break, PHP is
>> doing exactly what it is suppose to do here and I wouldn't want it any
>> other way.
> Agreed. Although I gene
I still don't see why json_encode ignores protected/private class
members. I mean, why we need this feature.
>>>
>>> Because, in theory, it shouldn't even be able to see those members?
>>
>> Stefan's right. Unless you are in the local scope or inheriting the
>> object you shouldn't be a
>> however changing this at this point would be a huge security issue, so
>> if at all, it would need to be handled by an optional parameter that
>> defaults to false.
>>
>
> That would be unclean. If it's implemented in some way, json_encode should
> look for the implementation of some inte
Ron Rademaker wrote:
> Stefan Walk wrote:
>> That would be unclean. If it's implemented in some way, json_encode
>> should look for the implementation of some interface (JSONEncodable
>> or something) providing encoding/decoding methods (similar to
>> __sleep/__wakeup).
> Looking at our current JSO
marius popa wrote:
> an semisolution would be an php.ini variable
> like
> NAMSPACE_SEPARATOR="::"
> so if you have an issue with your classes can be reset to "\" or
> whatever with ini_set
>
> i think it's easy to be done if i look at the patch that created the
> backslash separator issue
>
So
Dave Ingram wrote:
> marius popa wrote:
>
>> an semisolution would be an php.ini variable
>> like
>> NAMSPACE_SEPARATOR="::"
>> so if you have an issue with your classes can be reset to "\" or
>> whatever with ini_set
>>
>> i
> I only worry it could break BC - people might have used "{SOMETEXT}" in
> strings and not expect it to be interpolated (I've done so myself).
>
I've done that a lot, and I've seen quite a bit of templating code that
does the same.
My personal opinion is that interpolating constants would ju
Josh wrote:
> Dave, how is a variable name any less a bareword than a constant name?
>
A bareword (in my opinion) is a word without a sigil (e.g. a leading $),
so the way that you would write a constant normally in PHP. What I was
trying to say is that having bareword-style interpolation ("{MYCO
educe the number of possibilities
available:
$foo++;
echo $ofo;
if ($oof > 4) break;
I am now very tempted to write something that does this. I can think of
a fairly easy and not-hugely-intensive implementation, too. I'd imagine
the canonical form for each variable would be an anagram
dicti
Nathan Rixham wrote:
> [...]
>
> while I'm here I may as well also ask about further adding type
> hinting for the existing scalars and array.
+1, but I don't know what might have stopped it being implemented before
(time, parsing API changes, etc), so it would be interesting to look
into the histo
> I remember that multiple signatures was said to have a possible very
> difficult implementation. However, a similar behaviour can be achieved by
> some instanceof().
>
I thought it probably would be awkward, but we do already have some type
hinting that can also be accomplished with instanceo
Cristian Rodríguez wrote:
>> class MyTestClass {
>> public function blah(Foo $f);
>> public function blah(Bar $b);
>> public function blah($v);
>> }
>>
>
> Looks like you are using the wrong language, you need JAVA instead.
>
Yes, I'll admit it does look like Java (or any C++-like OO
27 matches
Mail list logo
