On Sat, 2013-07-20 at 10:31 +0100, Arpad Ray wrote:
> I agree this is a largely pointless can of worms, but here's my POC from
> yesterday in case anyone wants to play with it:
> https://gist.github.com/arraypad/6044439
*If* we want to provide a simple function for easy printing for
callbacks and
On Sat, 2013-07-20 at 14:28 +1000, Ryan McCue wrote:
> Sara Golemon wrote:
> > Well, now... to be fair... You could make them functions and use the same
> > parser trick the backtick operator uses. to map the non-parenthesized
> > versions feels messy though. I'd just hate to get stuck with a
On Sat, Jul 20, 2013 at 9:24 AM, Lester Caine wrote:
> Stas Malyshev wrote:
>
>> Is there a reason that echo/print couldn't be implemented as functions
>>> >with some sort of backwards compatibility layer? isset/etc make sense to
>>>
>>
> Yes, the reason is not fixing what isn't broken:)
>>
>
>
Stas Malyshev wrote:
Is there a reason that echo/print couldn't be implemented as functions
>with some sort of backwards compatibility layer? isset/etc make sense to
Yes, the reason is not fixing what isn't broken:)
And perhaps introducing 'black holes' like the one created when stopped work
Hi!
> Is there a reason that echo/print couldn't be implemented as functions
> with some sort of backwards compatibility layer? isset/etc make sense to
Yes, the reason is not fixing what isn't broken :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ex
The danger I see there is the fact that we'd have two different
implementations of the same functionality (leading to potential code-rot),
and worse, it wouldn't be obvious from userspace when one implementation
would be used over the other. (We'd know, but I mean for the average PHP
user, leading
Sara Golemon wrote:
> Well, now... to be fair... You could make them functions and use the same
> parser trick the backtick operator uses. to map the non-parenthesized
> versions feels messy though. I'd just hate to get stuck with a hacky
> workaround like that for the long term.
That's what
Well, now... to be fair... You could make them functions and use the same
parser trick the backtick operator uses. to map the non-parenthesized
versions feels messy though. I'd just hate to get stuck with a hacky
workaround like that for the long term.
On Fri, Jul 19, 2013 at 9:23 PM, Sara G
Lack of parenthesis and the fact that EVERY project out there takes
advantage of this affordance. So BC *nightmare*.
On Fri, Jul 19, 2013 at 9:16 PM, Ryan McCue wrote:
> Johannes Schlüter wrote:
> > So, unfortunately no, language constructs have different semantics which
> > we can't emulate in
Johannes Schlüter wrote:
> So, unfortunately no, language constructs have different semantics which
> we can't emulate inside function semantics (well ok, it is software, so
> it is thinkable .. but nobody,yet, came up with a robust patch which
> doesn't cause maintenance *and* performance penalty)
I think the idea comes from a good place, but the actual, practical
usefulness of it is so low that the availability of workaround negates even
the very small amount of effort it would take to create (and maintain!)
shadow functions for the language constructs.
array_filter($arr, function($val) {
On Sat, Jul 20, 2013 at 1:32 AM, Arpad Ray wrote:
> On Fri, Jul 19, 2013 at 6:28 PM, Daniel Lowrey wrote:
>
> > While it works, it somewhat obscures what you're trying to accomplish in
> > the code. The maintainability nightmare alone may be enough to
> > counterbalance any benefits. Then again,
Hi,
On Fri, 2013-07-19 at 12:36 -0400, Daniel Lowrey wrote:
> I have a simple question about the callability of language constructs and
> whether or not that's something that might change in the future. Consider:
>
> var_dump(is_callable('echo')); // bool(false)
> var_dump(call_user_func('echo',
On Fri, Jul 19, 2013 at 6:28 PM, Daniel Lowrey wrote:
> While it works, it somewhat obscures what you're trying to accomplish in
> the code. The maintainability nightmare alone may be enough to
> counterbalance any benefits. Then again, who needs
> readability/maintainability when you can write h
It would more than likely create some semantic nightmares. I can envision
people doing numpty things like:
array_map('include', $dependencyFilesArr);
While it works, it somewhat obscures what you're trying to accomplish in
the code. The maintainability nightmare alone may be enough to
counterbala
On Fri, Jul 19, 2013 at 5:36 PM, Daniel Lowrey wrote:
> How deeply ingrained into the engine is this behavior? Is there any chance
> of language constructs ever passing the tests for callability or is that
> just a pipe dream that's not worth the implementation effort?
>
It's actually pretty tri
> Oh yeah, I see your point about is_null but not why it makes any more
sense to allow language constructs there.
Yeah I don't know if it even does. I'm not even really sure if there's a
good example use case for it besides the array_filter/isset combo. My
question was really only exploratory in n
On 19 July 2013 18:11, Jelle Zijlstra wrote:
>
>
>
> 2013/7/19 Peter Cowburn
>
>> On 19 July 2013 17:36, Daniel Lowrey wrote:
>>
>> > I have a simple question about the callability of language constructs
>> and
>> > whether or not that's something that might change in the future.
>> Consider:
>
> array_filter([…], 'is_null');
Doesn't work -- `is_null` would return TRUE leaving a result of [NULL]
after the array_filter operation. That's the diametric opposite of what my
example code looks to do.
On Fri, Jul 19, 2013 at 1:07 PM, Peter Cowburn wrote:
>
>
>
> On 19 July 2013 17:36, Daniel
2013/7/19 Peter Cowburn
> On 19 July 2013 17:36, Daniel Lowrey wrote:
>
> > I have a simple question about the callability of language constructs and
> > whether or not that's something that might change in the future.
> Consider:
> >
> > var_dump(is_callable('echo')); // bool(false)
> > var_dum
On 19 July 2013 17:36, Daniel Lowrey wrote:
> I have a simple question about the callability of language constructs and
> whether or not that's something that might change in the future. Consider:
>
> var_dump(is_callable('echo')); // bool(false)
> var_dump(call_user_func('echo', 'foo')); // E_WA
I have a simple question about the callability of language constructs and
whether or not that's something that might change in the future. Consider:
var_dump(is_callable('echo')); // bool(false)
var_dump(call_user_func('echo', 'foo')); // E_WARNING
echo('foo'); // foo
var_dump(is_callable('isset'
22 matches
Mail list logo
