Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethinking Zephir #201

Open
phalcon opened this issue Feb 17, 2014 · 37 comments

Comments

@ghost
Copy link
Collaborator

commented Feb 17, 2014

After several months working on Zephir, we are very happy with the progress so far, in a few months we will reach a beta version and then we'll enjoy all its potential. We have reached over 1000 commits and counting and there's a lot to do. This project has allowed us to do a little more CS research and it has been very interesting for us.

Moreover, we must admit that we're not sure what will happen with PHP in the future, despite this, we are creating a tool which allows to take advantage of one the less exploited PHP features by the community at large (C extensions) and for a long time it has been reserved to experienced C programmers or advanced users.

Also in Zephir, we have found the opportunity to implement features that we have always dreamed of PHP but for one or another reason they are not a reality today:

We believe they will help us to build a better framework and it can help you to build your own tools in a new interesting way. Not everyone needs these features and not all may agree with them. However, we hope that one day these features will considered in the official PHP so we all can enjoy them. No matter what happens, we are sure that PHP will continue evolving regardless of the path taken.

Zephir was initially conceived as a high-level language that abstracts low-level details and allows you to compile your code. Currently based on a high-level representation it generates C code that can be compiled by leading compilers such as gcc/clang/vc with all the advantages that this brings to the table.

Nevertheless, we know that Zephir, being a high-level language, it could also function as a meta-language rather than just a DSL (domain specific language).

After thinking a bit on this I'm creating this thread to discuss an idea with you guys.

If we could restructure Zephir so that it can generate code in both PHP and C, this could make Zephir a much more powerful tool than ever before.

Generating C:

  • The code can be compiled, improving performance and reducing resource consumption
  • Some important level of code protection
  • Code is exported as a C-extension (shared library or Windows DLL)
zephir generate c

Generating PHP:

  • PHP code can run everywhere where the language is available (shared hostings, servers with restrictions, other PHP implementations, etc)
  • Code is exported as a PHP library (phar, standard PHP library installable via composer, etc)
zephir generate php

Using C-extensions:

  • Production environments, when more performance is required and install c-extensions is feasible

Using PHP libraries:

  • Development/Testing environments, other restricted environments, other PHP implementations, etc.

Possible cons:

  • C code blocks cannot be exported to PHP
  • Integrations with low level C libraries couldn't be exported to PHP
  • Introduce incompatibilities due to the different runtimes (can be solved with enough tests)

With regard to this we can:

a) Implement this now
b) Release Zephir 1.0 (aka stable) and implement this after that
c) Do not implement it at all

Looking forward to your comments,

@Swader

This comment has been minimized.

Copy link

commented Feb 18, 2014

If time permits, I vote a), do it. This would allow Phalcon to exist on shared hosts that have a PHP version that's modern enough, enhancing reach greatly. It would also let people use Phalcon on GAE, and then simply keep their code intact when GAE finally does adopt Phalcon as a proper extension (at least in theory, right?).

How much would this implementation slow down Zephir's development? If by a lot, I vote b).

Regarding not being able to export C blocks and integrations with low level C libs, not sure how to approach that other than devs declaring their project for export to C, PHP or both.

@DavertMik

This comment has been minimized.

Copy link

commented Feb 18, 2014

This idea looks great. For instance, when I develop a library I want it to be available to all the PHP community and not only to those who can install extensions. As you said, extensions are not so widely adopted. So it would be cool if a PHP library can be used, and replaced with C-library in production. If that's possible to keep the complete compatibility that would be awesome. If a library can be distributed in both ways... Yeah, cool

Also I think PHP comes to era where it will get some metalanguages, as there was CoffeeScript for JS. If you can't deal with all the old dirty stuff with PHP and you need better structure, better syntax, etc, you can choose this metalanguage and not wait for PHP 5.XXX to have static typing, or short function calls. There are already few coffee-script-like projects for PHP but they are not so widely popular, just because they do not provide any benefits nor build tools for smooth development.

So I think that is really good direction to move on. I can't insist, I'm not sure that as a library developer I will use Zephir in nearest future. But I really like the ideas!

@nkt

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2014

Right now - I'm against.
Zephir really good make one thing - it creates php C-extensions. But it could be better!
inline-keyword, exception-handling, simple c/c++ code-wrapping.
If it's a simple library, for example router, string-type library or DI - ok. But if it is a big project, like Phalcon - you inevitably would lose some functionality. Volt template language, for example.
So I vote b

@wlejon

This comment has been minimized.

Copy link

commented Feb 18, 2014

I love the idea.

In the near term, I think it's more important to become a DSL than a new scripting language.

The likelihood of adoption for a better programming language that runs in existing environments is much higher than a completely new language. Languages have been solved. Competing in that realm would be difficult.

Tool support will already be a long task to complete, adding another layer of compilation (including existing libraries in PHP) will only slow down potential adoption.

I vote B.

@nkt

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2014

And about other php implementations, I think you means hhvm. I do not sure, but hhvm should has some extension-system, and may be more important translate zephir into hhvm-extension, instead of PHP.

@nkt

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2014

I've translate this post into Russian, and create voting.

@ywliu

This comment has been minimized.

Copy link

commented Feb 18, 2014

I am thinking about short-, middle- and long-term scenarios.

Our ambition decides its future. But so far, Zephir is still at its infancy. It's hard to decide to what or how it will grow.

In the short term, Zephir is definitely the coolest tool available in the PHP world. Now the threshold to create a C-extension is lowered dramatically. It's where it started.

In the middle and long terms, I cannot envision how it will evolve.

But in terms of "parents' hopes", maybe it can replace PHP as a new platform, with the PHP compatible syntax but as fast as C. Who knows (BTW, wasn't this HipHop supposed to do ? :) Or a PHP with steroids, like Scala, Groovy on JVM ? A new PHP with all the language beauties borrowed from Python or Ruby ?

I suggest we focus on the short term and near future, to make Zephir the coolest tool for PHP ever. Keep our brainstorming here and let's see how it will grow. Then we will know how to restructure our code base.

As for now, I vote B.

@jimmycdinata

This comment has been minimized.

Copy link

commented Feb 18, 2014

I vote B.

We need test Zephir first in real world. Adding more time to add 'cool' feature, doesn't change the current situation.

IMHO, launch Zephir, launch Zephir, launch Zephir.

@ikandars

This comment has been minimized.

Copy link

commented Feb 18, 2014

I vote b

First thing first. Make Zaphir stable then go to next feature.

@dioramayuanito

This comment has been minimized.

Copy link

commented Feb 18, 2014

i vote b

@ovr

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2014

d) Release 0.4 after few months start developing it, not 1.0. stupid numbering versions on phalcon and zephir. See for example nginx after 8 years it = 1.0 stable! we don't need marketing way like chrome browser.

@asp24

This comment has been minimized.

Copy link

commented Feb 18, 2014

I vote C.

@mruz

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2014

Release stable Zephir, stable Phalcon 2 versions and focus on them. After few months start thinking on this.

For me the biggest advantage is performance. I vote C.

@carlosbuenosvinos

This comment has been minimized.

Copy link

commented Feb 18, 2014

Release and the ask again :)

@SliceOfLife

This comment has been minimized.

Copy link

commented Feb 18, 2014

I vote C.

@alekciy

This comment has been minimized.

Copy link

commented Feb 18, 2014

I vote C.

P.S. habr.ru same (nkt comment link).

@Agent-J

This comment has been minimized.

Copy link

commented Feb 18, 2014

My vote for B.
You should focus on stable version first.

@ValeriySelitskiyViber

This comment has been minimized.

Copy link

commented Feb 18, 2014

Stabilize it for production use first. its a great aim for a major update, though.

@jodator

This comment has been minimized.

Copy link

commented Feb 18, 2014

Delivering working stuff earlier is better then polishing stuff to the finest and releasing it later. So I think that main concern should be releasing stable Zephir & Phalcon 2.0. Don't see any use for generating PHP code for shared hosting. Cool feature as a bonus but not obligatory in my opinion.

My vote for C (or later on B if this kind of features are desired by others).

ps.: option A is a worst case scenario - Zephir & Phalcon 2.0 should be released as soon as possible

@swen100

This comment has been minimized.

Copy link

commented Feb 18, 2014

vote B
first we need stability, completion and speed

@xavierleune

This comment has been minimized.

Copy link

commented Feb 18, 2014

I vote B
We really need to see phalcon and zephir 2 live.
I think you have to be focused on the first goal : have a way to write php extensions easily.

@levani

This comment has been minimized.

Copy link

commented Feb 18, 2014

I vote C.

Zephir is great but not for writing php code. My personal opinion.

@kkamkou

This comment has been minimized.

Copy link

commented Feb 18, 2014

@DavertMik the PHP avg. level is really low, almost like JS community. I think that It is not a good idea to allow such developers to code extensions on C. Besides of that, try to code normal JS after the CoffeeScript. And if you know it very well I'm pretty sure you know that a more complex application looks ugly.

You are absolutely right about a library distribution. ZF3, Sf and other frameworks can be "packed" to native extensions. Great!

@phalcon, the community is huge. The idea is perfect. Voting for B, because I think you have to have a clear picture about your solution and the future of it. And it is all about ideas/help and proposals you can gather after release.

p.s. @ovr tabs are less important than spaces and print is faster than echo. or what do you think?

@oleg578

This comment has been minimized.

Copy link

commented Feb 18, 2014

I vote C . And only C. Better develop the main functionality. Good luck!

@ovr

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2014

@kkamkou
1 tabs are better
2 echo is more faster because it has 3 opcodes vs 4 opcodes (print)
I think the best way for coding style is creating a new standard for Zephir extending from PSR2 with some fixes (tabs case with no enters and etc)

@ghost

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 18, 2014

Thank you all for your comments, suggestions, time and votes!

It is clear that the majority of votes are for B and C. Of course, implementing this now would delay the development and this is not desirable. I personally vote for B, however, it's important to know that Zephir will probably offer this feature at some point in the future. Adding a second backend (PHP) would change the current identity of the project and it's for that reason that I wanted to discuss this with all of you.

Complete the generation and creation of extensions is obviously our priority. Both achieve a stable version of Zephir as Phalcon 2 are also priorities, however, with an open mind and for multiple reasons, it would be good to have the ability to use PHP as backend sooner or later.

For those who contribute to Zephir: Keep in mind that this could be implemented later and it would be interesting (if possible) prepare the future changes for this.

Thanks!

@niden

This comment has been minimized.

Copy link
Member

commented Feb 18, 2014

Thank you all for the votes and the feedback.

For the record my vote was going to be B :)

@racklin

This comment has been minimized.

Copy link
Contributor

commented Feb 19, 2014

I vote B.

Stable Zephir and Stable Phalcon2 and implemented more userland php functions to c for better performance.

@xboston

This comment has been minimized.

Copy link

commented Feb 20, 2014

I vote B =)

@damienalexandre

This comment has been minimized.

Copy link

commented Feb 20, 2014

Do not know if the choice is made already but I vote c;
I do not see any valid use-case for a Zephir to PHP translation, framework like Phalcon are chosen because of the extension mode and speed in the first place,
and having both PHP mode & C extensions will introduce a lot of new bugs (I do not think relying on unit test will be enough).

What I want for the future of Zephir is more tooling for a PHP to Zephir rewrite: that's how we can help the community: allowing fast extension creation for PHP librairies and frameworks.

My 2cts 🤘

@marciopaiva

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2014

I vote B

Maybe one tool to convert php to c extension :)

@brandonlamb

This comment has been minimized.

Copy link

commented Mar 8, 2014

Also B (I think).

I am loving zephir so far. Already released a php hal library (https://github.com/brandonlamb/hal-1) and am now working on converting Spot ORM to zephir.

I really like the idea of just having this sort-of like php meta language, I am finding it pretty easy and trivial to write in. I would love to see more features added like returning references, static::method() and overall stabilization.

A CoffeeScript for PHP project seems like (to me) it should be its own project, keep zephir a metalanguage to build c code and optimize the hell out of it.

@nkt nkt added the discussion label Mar 29, 2014
@darkgaro

This comment has been minimized.

Copy link

commented Mar 29, 2014

I love what you guys are doing and I would love to see more of zephir bugs fixed and more functionality built out first, so I vote for B.

@ghost

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 18, 2014

@flip111 Zephir FUD?

@nkt

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2014

@phalcon for now I changed my opinion. I think we should split Zephir into parser, AST-builder and code-printer. If we do it, we can easily implement any compiler: Zephir -> extension, Zephir -> PHP, PHP -> extension, PHP -> Zephir(very helpful for big projects), PHP -> PHP (5.4 to 5.3), Zephir -> hhvm extension, etc.

@rushmorem

This comment has been minimized.

Copy link

commented Aug 1, 2014

@nkt I like this idea. Breaking Zephir into loosely coupled components that do one thing well will make it more flexible and trivial to implement additional features later.

Once we proceed with that mindset, we can then concentrate on bringing out a stable version knowing that our effort will pay off later on when we decide to add other features, including those that we would not have conceptualised now.

Zephir is an awesome project and a dream language come true.

@nkt nkt referenced this issue Aug 4, 2014
@boussou

This comment has been minimized.

Copy link

commented Aug 18, 2014

Then, if you decided to go in that direction, why not thinking in implementing a new cleaner & consistent version of the language itself? & producing a spec of what the language should be?

I mean for example get rid of array() and use [] only, native utf-8, allow dot instead of this wierd "" for namespaces. Remove the use directive. And the nice features of Hack.

And remove all of the useless features or weird syntax of PHP that makes it inconsistent.

@phalcon phalcon locked and limited conversation to collaborators Aug 22, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.