On Sat, Jan 12, 2013 at 7:35 AM, Levi Morrison wrote:
> > Can we re-write PHP with PHP? ;)
>
> Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Just wish
In a semi-joke but oddly real concept. I get that the language proposals
(c++) are half jokes. But if we're going down that road, why don't we
consider rpython and building on top of HippyVM that's already partially
built... It would have a number of advantages over C:
1. It compiles to C, so shou
Not really insane.
PHPPHP is very powerful. Imagine someone that have no idea about C but
would love to propose something.
Just fork the project, add the desired support in PHP and propose here. I
guarantee it'll be easier to understand the caveats and the final patch
easily.
Cheers,
On Sat, Ja
That is seriously funny
On Jan 11, 2013, at 11:35 PM, Levi Morrison wrote:
>> Can we re-write PHP with PHP? ;)
>
> Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.ph
> Can we re-write PHP with PHP? ;)
Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 1/11/2013 1:17 PM, Stas Malyshev wrote:
Hi!
A function that is related to a zend_function struct could be placed
anywhere, in any file and can be named in any way. Finding it is like
looking for a needle in a haystack, then you add macros.
You can do macros in C++ too, and you can have de
I would definitely vote "No" on object oriented. I'd vote for C++ but
SOLELY because templates. I'd stay away from classes as they generally
hurt performance.
Sorry for the off-topic comment :)
On Thu, Jan 10, 2013 at 9:06 PM, Clint Priest wrote:
> Oooh, a rewrite? Can we write it in an object
Hi!
> A function that is related to a zend_function struct could be placed
> anywhere, in any file and can be named in any way. Finding it is like
> looking for a needle in a haystack, then you add macros.
You can do macros in C++ too, and you can have detached functions too.
And it is perfectly
Hi!
> To make sure we are not providing a somewhat cumbersome
> implementation, let’s start tackling named parameters first. It’s
> another long standing feature. We will most likely need named
> parameters for convenient annotations anyway. We have an (really old)
> RFC for that: https://wiki.php
2013/1/11 Clint Priest
>
> Even so, C++ is not the only object oriented language out there.
>
> -Clint
I could not resist the urge to suggest D as an option :) Sorry for this
troll attempt.
Well, there is Quercus out there in the wild, they did it. Sure a total
rewrite will give opportun
It's a pretty decent read, but the major point that his article about
the virtues of C misses a huge mark. Software written in C, when they
become of sufficient size become completely impossible to keep track of.
A function that is related to a zend_function struct could be placed
anywhere, i
Hi Stas,
I think you hit a nail here.
Am 10.01.2013 um 21:36 schrieb Stas Malyshev :
> Another thing is that we're not having some features that are used
> extensively in C# annotations, main being named parameters support.
To make sure we are not providing a somewhat cumbersome implementation
Hi!
> parameters is a great example. I'd also name another one,
> ReflectionNamespace; namespaces are converted to strings and attached to
> their classes during compile time and you can never reflect over them to
> grab for example their names.
I still can't understand why you need ReflectionNam
No. C++ is horrible. Very good read:
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
On Jan 11, 2013 5:06 AM, "Clint Priest" wrote:
> Oooh, a rewrite? Can we write it in an object oriented language this
> time? Please? Pretty Please???
>
> :D
>
> On 1/10/2013 9:49 PM,
Hi,
I suggest you start defining action items in the RFC. After reading what
Stas and others say, this looks like too big a task to discuss in itself,
so it should be definitely be broken down.
You will probably find that as it is broken down, actual development
support will surface by itself.
R
Oooh, a rewrite? Can we write it in an object oriented language this
time? Please? Pretty Please???
:D
On 1/10/2013 9:49 PM, guilhermebla...@gmail.com wrote:
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support req
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
Refl
Hi!
> I strongly suggest to anyone following the (too many) threads about
> annotations to try the C# annotation and see what it allows. It goes
As far as I can see, C# annotations rely on two very important things:
1. Compiler support. Compiler really knows a lot about what annotations do.
2. Ex
On Thu, Jan 10, 2013 at 10:17 AM, Nate Tuganov wrote:
> Hello,
>
> Well, I've been reading internals for years and never replied. But I think
> this time I have to share my thoughts.
>
> First of all I understand Rasmus and Stas position on holding PHP as simple
> as it is. It's great and in the
On Thu, Jan 10, 2013 at 10:17 AM, Nate Tuganov wrote:
> PHP is great for web development, let's stick to it. Give us a chance to
> create frameworks, which can use Annotations, DI, IoC, Factories,
> Decorators and all others patterns to allow regular designer to create a
> simple site with few li
Hello,
Well, I've been reading internals for years and never replied. But I think
this time I have to share my thoughts.
First of all I understand Rasmus and Stas position on holding PHP as simple
as it is. It's great and in the same way it's wrong. As Anthony mentioned
PHP evolves, and PHP is be
21 matches
Mail list logo