On Aug 31, 2016, at 11:49, Yasuo Ohgaki wrote:
>
> I remember an argument that "function" is useful to "grep functions".
> This is true, but we have tokenizer and tokenizer does better job.
> e.g. It excludes functions inside comments.
>
> It may be time to consider simplifying things.
Perhaps,
This would be great if everyone just wanted to state their stance and be done
with it. It reminds me of the election pamphlets that my state sends out to
inform voters of what the upcoming ballet measures are and what various folks’
for/against arguments are. But those arguments are collected i
> On Sep 18, 2015, at 10:27, Lester Caine wrote:
>
> All I am saying is that 'exists()' is simply part of the toolkit that
> goes WITH extract(). There is a suitable tool in arrays and in objects
> so why not complete the toolkit in straight variables. The names are a
> mess between the three for
> On Sep 16, 2015, at 14:57, Stanislav Malyshev wrote:
>
>> I’ll refer again to the above documentation:
>>
>> "A variable is considered to be null if […] it has been unset().”
>
> You are confusing two things.
>
> 1. The variable has value of null.
> 2. The variable does not exist, so when yo
On Sep 16, 2015, at 14:09, Rowan Collins wrote:
> I can certainly sympathise with wanting to run without any notices - they are
> generally hints for writing better code. In the vast majority of cases,
> though, that means working out *why* the variable is undefined, otherwise you
> might as we
On Sep 16, 2015, at 11:28, Stanislav Malyshev wrote:
>
>> 1 PHP defines null to include variables that have "not been set" 2
>
> No, not really, PHP does not define that.
It does according to the docs:
"A variable is considered to be null if […] it has not been set to any value
yet."
http://
On Sep 16, 2015, at 11:14, Rowan Collins wrote:
>
> Robert Williams wrote on 16/09/2015 18:37:
>> The docs suggest that uninitialized variables are null, and the above makes
>> it sound like that’s what you’re stating, too. But they’re not: they don’t
>> exist at al
On Sep 16, 2015, at 06:54, Rowan Collins wrote:
>
> I want to pull this out for a bit more attention: one of the crucial
> questions in this thread is whether the language is wrong, or just the
> documentation. There's one particularly wonky passage someone found in the
> manual that makes it
On Sep 16, 2015, at 06:44, Rowan Collins wrote:
>
> Can you give an example of code where you do not know this until the code
> runs - i.e. where "is this variable set?" is something you can hang business
> logic on?
>
> Somewhere where it would make sense to write something like this, if the
On Sep 16, 2015, at 06:00, Rowan Collins wrote:
>
> Absolutely. However, in order to need a dynamic check of variable existence,
> you must also be using non-existence as a second sentinel value. You must be
> saying "if the variable has never been assigned to, that means state X; if
> it's be
On Sep 14, 2015, at 16:06, Stanislav Malyshev wrote:
>
>>> No. There's no reason for null to exist if isset returns true on
>>> null. If one doesn't understand that, one should not be using
>>> null at all.
>>
>> Nonsense.
>
> Oh, thank you! That's a good start for a polite argument.
Apologie
On Sep 14, 2015, at 13:23, Stanislav Malyshev wrote:
>
> No. There's no reason for null to exist if isset returns true on null.
> If one doesn't understand that, one should not be using null at all.
Nonsense. It just means that one isn’t using null the way you do. You’re saying
people shouldn’
I really don’t understand the resistance to this type of change, other than
knowing that a fix will necessarily be messy. The fact is, PHP distinguishes
between a variable that has been declared but defined to null and one that
hasn’t been declared. The value of the first may safely be assigned,
On Jan 30, 2015, at 12:05, Patrick Schaaf mailto:p...@bof.de>>
wrote:
> % php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";} gethostbyname($e);’
What a funny way to say gethostbyname(str_repeat("0", 2501));
Wow, I somehow missed the interpolation of $e into the value… .
Guess I was too focused on
A PHP one-liner is being bandied about as one test of the recently discovered
Ghost vulnerability in gethostbyname(). Taken from:
http://ma.ttias.be/quick-tests-ghost-gethostbyname-vulnerability-cve-2015-0235/
Here it is:
% php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";} gethostbyname($e);’
W
On Dec 14, 2014, at 23:50, Leon Sorokin wrote:
>
> On 12/14/2014 10:45 PM, Robert Williams wrote:
>
>> I strongly suspect far more code would be *fixed* if the ternary operator
>> were changed to match what other languages do.
>
> If you have 'incorrectly' f
Some thoughts from user land…
On the concern of breaking code out there that relies on the current behavior,
I strongly suspect far more code would be *fixed* if the ternary operator were
changed to match what other languages do. I hate to admit it, but my own shop
is a good example. We have a
If the syntax of heredocs/nowdocs is to be loosened, the biggest aspect I’d
like to see addressed is indentation. I can certainly see how it would be nice
to loosen the restrictions around the post-closing-token newline to allow
easier use in places like array definitions, but, I’ve never run in
They don’t necessarily need to be symbols. Pascal, for example, uses ‘/' for
floating-point division, ‘div' for integer division, ‘mod' for modulus, and
‘rem' for remainder. For example:
20 / 8 = 2.5
20 mod 8 = 4
In PHP, we already have precedence for non-symbol in operators like ‘and',
‘or',
On Jul 23, 2014, at 11:37, Andrea Faulds wrote:
> Aliases mean inconsistency. We shouldn’t unnecessarily have multiple names
> for the same thing, just one. Also, for every alias we support, another
> reserved word is added. Hence we only allow one set of names. This is also
> Facebook’s appro
On Jul 14, 2014, at 10:13, Andrea Faulds wrote:
> We are using hack’s syntax (int, float, bool, string, no
> integer/double/boolean aliases).
On 20 Jul 2014, at 14:11, Andrea Faulds wrote:
> The patch actually warns you if you try to do this now:
>
>function foo(double $foo) {}
>foo(1.
On Sep 2, 2013, at 15:54, "Lester Caine" wrote:
> Parameter hashes are what we have been converting everything TO because it was
> supposed to be the 'proper way to do it' a few years back.
If you have lots of parameters to pass in, the better solution is to use an
object, which lets you formal
On Aug 25, 2012, at 17:24, "Guillaume Rossolini" wrote:
> What you say is true, versions get old. But as Lester pointed out, they
> work. that is why some computer systems that have been outdated for years
> are still functioning today. It is hard to make a case for rewriting code
> that already
On Jul 14, 2012, at 22:58, "Stas Malyshev" wrote:
> The question is - should we apply it to 5.3/5.4? It is a behavior
> change, even though current code behavior does not match documented
> behavior.
I understand the concerns of BC, but I don't understand our general reluctance
to break BC to f
On 4/17/12 08:17, "Nikita Popov" wrote:
>The last one is more problematic. It is explicitly documented as
>accepting hexadecimal numbers. In my eyes it too should not accept
>them, but I could imagine that people rely on this.
This always struck me as mistaken design. Why accept hex or decimal,
On Apr 17, 2012, at 5:39, "Hartmut Holzgraefe"
mailto:hartmut.holzgra...@gmail.com>> wrote:
Same here, i never even knew that this worked in a string context
until recently. Autocast/comparison rules are already complicated
enough as they are documented now, and i failed to find anything
in the m
On 4/12/12 10:09, "Anthony Ferrara" wrote:
>I'm not against the idea, I just don't see a strong use-case for it.
>It's not like your injecting the scoped vars into an existing
>function, you're writing the function fresh. So why not just use the
>existing var names?
I can see this being occasi
On 12/23/11 13:34, "Will Fitch" wrote:
>There's still the matter of whether allowing null to be returned,
>regardless of the situation, or using another token to identify that
>it could return null. I'd like to know what others think. I see Stas'
>argument that you'll still have to check, but I'
On Dec 22, 2011, at 18:59, "Will Fitch" wrote:
> Would you prefer to allow methods with type hinted return values to return
> null at will, or add a marker noting that it *may* return null?
My preference would be to have a marker, and when null is not allowed, if the
function tries to return i
29 matches
Mail list logo
