On Fri, Aug 3, 2012 at 12:26 AM, Alex Aulbach wrote:
> 2012/8/2 Andrew Faulds :
> > Hi,
> >
> > Also in JavaScript if in strict mode. Legacy non-strict mode JS doesn't
> cause an error though.
> >
> > JS's || operator supresses this error though, which is great for e.g. x
> = x || new Object();
>
2012/8/2 Andrew Faulds :
> Hi,
>
> Also in JavaScript if in strict mode. Legacy non-strict mode JS doesn't cause
> an error though.
>
> JS's || operator supresses this error though, which is great for e.g. x = x
> || new Object();
Could be cool to make this in PHP with the 'or' operator (or not
Hi,
Also in JavaScript if in strict mode. Legacy non-strict mode JS doesn't cause
an error though.
JS's || operator supresses this error though, which is great for e.g. x = x ||
new Object();
--
Sent from Samsung Mobile
Andrew Faulds
http://ajf.me/
Stas Malyshev wrote:
Hi!
> I've looked a
So... I was thinking of proposing that we perhaps leave Arrays as is
w/r/t undefined indices, while fixing up the ArrayObject gaps and
making that the "smart" one (wrap/box in an AO if you want
expanded/overloadable functionality).
That idea was based on my belief that ArrayObject::offsetGet alrea
2012/8/1 Christoph Hochstrasser :
> I'm lately using @$var["key"] a lot (despite it's slowness) and I like it a
> lot. It makes
> most code a lot more readable. I would be +1 for it, if we can make it fast.
>
> I think most people (me included) want only to avoid the notice for accessing
> undefi
Hi,
> Traceback (most recent call last):
> File "", line 1, in
> KeyError: 'a'
>
> And it's just as annoying as in PHP. Actually, probably more annoying
> :). But it has .get() which solves the problem usually, albeit in a bit
> more verbose way. Also, Python has defaultdict which I would usua
Hi!
> I've looked a bit into other languages (Ruby, Python, Go) and
> all of them do not generate an error when an undefined dict/hash/map key is
> accessed.
Python would definitely throw an exception:
>>> a = {}
>>> a
{}
>>> print a['a']
Traceback (most recent call last):
File "", line 1, in
Hi,
> I'd be very happy if we could have something like @$var['foo'] just work
> by not generating any errors, but if not then probably having some
> syntax saying "this variable or null, no notices" will be good - if say
> it's $?foo then we could easily add defaults by doing $?foo ?: 'bar'.
> Ma
2012/7/24 Yahav Gindi Bar :
> Yeah, that's a design decision, but its important because that's one of the
> PHP greatest things - the code is very nice and readable, and it's kind of
> sad to ruin it...
>
> I didn't thought about template engines - I agree, it'll be great there, but
> does a lan
> My feeling is that either more complex expressions for operators with an
> implicit "isset" or "!empty" shouldn't work, or that they should cause
> notices.
That's exactly why I think we're going in the wrong direction by
speaking of an "alternate ternary" operator.
You're saying the basic ter
On 24 ביול 2012, at 20:15, Alex Aulbach wrote:
> 2012/7/24 Yahav Gindi Bar :
>> I don't think global operators is good idea since it can make a script very
>> complex and you'll have to learn many operators in case the one who wrote it
>> decided to make it "operator driven"
>
> On the other h
2012/7/24 Yahav Gindi Bar :
> I don't think global operators is good idea since it can make a script very
> complex and you'll have to learn many operators in case the one who wrote it
> decided to make it "operator driven"
On the other hand: If those operators aren't global, then they are
local
On 24 ביול 2012, at 19:18, Alex Aulbach wrote:
> 2012/7/24 Galen Wright-Watson :
>>> Don't see much difference between
>>>
>>> $a = $b ?: $c;
>>>
>>> and (for example I used "i" for "if")
>>>
>>> $a = _i($b, $c);
>>
>>
>> When $b is defined, there isn't much appreciable difference. However,
2012/7/24 Galen Wright-Watson :
>> Don't see much difference between
>>
>> $a = $b ?: $c;
>>
>> and (for example I used "i" for "if")
>>
>> $a = _i($b, $c);
>
>
> When $b is defined, there isn't much appreciable difference. However, this
> behavior already exists, so there isn't much to debate. In
On Sun, Jul 22, 2012 at 8:12 PM, Alex Aulbach wrote:
> Do we really need that as operator? Why not using new functions for
> special cases.
>
There isn't a need in the sense that such an operator makes things possible
that otherwise aren't possible. There is a need in that there are common
use ca
On Sun, Jul 22, 2012 at 9:08 PM, Sanford Whiteman <
swhitemanlistens-softw...@cypressintegrated.com> wrote:
> [...]
> You do raise (maybe on purpose, not totally clear what you were
> getting at) the question of whether a more complex (expr1) in one of
> these theoretical ternarys w/implicit isset
On Mon, Jul 23, 2012 at 6:19 AM, Alex Aulbach wrote:
> 2012/7/23 Sanford Whiteman <
> swhitemanlistens-softw...@cypressintegrated.com>:
> >> I think that you can compare the situation to the short if syntax ($a >
> $b
> >> ? $c : $d)
> >
> > Not sure I understand... that *is* the situation under d
> Use functions.
I understood your post; I was replying to Yahav.
Anyway, I don't agree with you that (built-in) functions are all we
can add because there'll be too much debate. Other languages still
consider adding operators over time and/or allow overloading. Getting
functions added to the la
2012/7/23 Sanford Whiteman :
>> I think that you can compare the situation to the short if syntax ($a > $b
>> ? $c : $d)
>
> Not sure I understand... that *is* the situation under discussion,
> no?
Use functions. Above case for example:
_greater($a, $b, $c, $d)
where
function _greater($a, $b, $
> I think that you can compare the situation to the short if syntax ($a > $b
> ? $c : $d)
Not sure I understand... that *is* the situation under discussion,
no?
$a > $b ? ...
and
$a ? ...
both use the ternary operator.
You do raise (maybe on purpose, not totally clear what you were
getting a
On Mon, Jul 23, 2012 at 6:12 AM, Alex Aulbach wrote:
> Do we really need that as operator? Why not using new functions for
> special cases.
> Don't see much difference between
>
> $a = $b ?: $c;
>
> and (for example I used "i" for "if")
>
> $a = _i($b, $c);
>
> Just a manner of getting accustomed
Do we really need that as operator? Why not using new functions for
special cases.
Don't see much difference between
$a = $b ?: $c;
and (for example I used "i" for "if")
$a = _i($b, $c);
Just a manner of getting accustomed to it.
A little bit more thinking: This could be implemented directly i
Hi!
> Top-posting, as not sure where to snip. :)
>
> I think either "??" "??:" as an operator makes sense, and would be
> readable and easy to learn, and resolve any BC concerns people have. I'd
> love to see this in, as the current behavior is basically useless for me
> I don't think I've once h
Top-posting, as not sure where to snip. :)
I think either "??" "??:" as an operator makes sense, and would be
readable and easy to learn, and resolve any BC concerns people have. I'd
love to see this in, as the current behavior is basically useless for me
I don't think I've once had code where I c
On Wed, Jul 18, 2012 at 12:21 PM, Galen Wright-Watson wrote:
>
>
> On Wed, Jul 18, 2012 at 7:20 AM, Anthony Ferrara wrote:
>
>>
>> On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms > >wrote:
>>
>> > [...]
>>
>> >
>> > This is basically because the ternary operator does not do a internal
>> > implicit
It changes the semantics. If the variable is set to a falsey value and ?:
uses an implicit isset, the value of the expression will be the falsey
value.
$config['width'] = ''
$width = $config['width'] ?: 300
# $width == ''
If !empty were used instead of isset, you could preserve semantic
On Wed, Jul 18, 2012 at 7:20 AM, Anthony Ferrara wrote:
>
> On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms >wrote:
>
> > [...]
> >
> > This is basically because the ternary operator does not do a internal
> > implicit isset, only an empty.
> >
>
> It does not do an empty. Empty would avoid notice
Sounds good. CoffeeScript (a lightweight language with JS semantics that
compiles to JS) has a existential operator, "?", and this looks similar and
would be very nice. It's not the same thing, of course. It also reminds me
of JavaScript's || behaviour.
On Jul 18, 2012 3:24 PM, "Rafael Dohms" wrot
On Wed, 18 Jul 2012 16:15:44 +0200, Rafael Dohms wrote:
With the syntax improvements for 5.4 and some of the de-referencing
work,
code looks so much sleeker then before, but there is still one use
case
that really bugs me.
Given this code:
$width = (isset($config['width']))? $config['width']
On Wed, Jul 18, 2012 at 4:20 PM, Anthony Ferrara wrote:
>
> Does this seem like a possible improvement we can work on? Anyone
>> interested in championing the change?
>>
>
> I like it in principle. My only concern is *why* wasn't it done this way
> in the first place... Is there a reason?
>
>
I do
Rafael,
One point of clarity:
On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms wrote:
> Hey Everyone,
>
> With the syntax improvements for 5.4 and some of the de-referencing work,
> code looks so much sleeker then before, but there is still one use case
> that really bugs me.
>
> Given this code:
Hey Everyone,
With the syntax improvements for 5.4 and some of the de-referencing work,
code looks so much sleeker then before, but there is still one use case
that really bugs me.
Given this code:
$width = (isset($config['width']))? $config['width'] : 300;
The code is pretty straight forward,
32 matches
Mail list logo
