Re: [PHP-DEV] Add runkit to PHP Runtime

[Yahav Gindi Bar]

On Fri, Aug 3, 2012 at 10:23 AM, Lester Caine  wrote:

> Yahav Gindi Bar wrote:
>
>> Maybe I'm wrong when comparing with other languages and mainly with
>> ASP.NET(C#) since they've used it for web proposes but I did saw many
>>
>> classes that used this feature and personally really like it.
>>
>
> If ASP is so good why is it loosing market share?
> Personally I'm pulling all the ASP sites I've inherited to PHP simply
> because the basic work flow in them is so bad.
> And on some of the inherited PHP sites we have this peculiar concept of
> having to write a 'controller' for a new page, and then another PHP file
> with the content. But then am I 'old fashioned' using smarty, templating
> and storing all the content in a database? This idea of 'controllers' and
> 'interfaces' does not seem to produce a viable work flow to me, and
> certainly unravelling the code is a pain :(
>
> You may understood me in the wrong way - I'm not try to say that ASP.NETis so 
> good and make comparison in the negative way or something like that,
PHP is a different language with its own great pros and that's why I've
decided to join these discussions and try to help improving it to be even
better. I just saw a feature in C# which exists in other languages (I've
used Objective-C which got it, and I read that Python and Ruby also got it)
so I think it'll be great to have this ability too built-in in PHP, that's
all. As I've said earlier - without this ability built-in
many potential developers, and of course frameworks and software developers
can't relay on this feature.


>  I've suggested to improve the language itself with some of the features in
>> runkit, not to copy and use it as is.
>>
>
> People don't use half of the facilities that PHP already has so why start
> introducing concepts that make that even more difficult. Once again ... we
> need to explain a lot better how to write 'good programs' using what is
> currently available without loading the core down with even more eye candy
> that few people will ever understand fully. I'm still for stripping more
> stuff back to PECL and coming up with a good 'old fashioned' simple
> beginners version of PHP to which the eye candy only needs adding once one
> understands the basics ...
>
> I don't think we can, even if we want, to teach beginners how to write
"good programs" or good-practice programs - there'll always be beginners
who'll create programs using bad-practice approaches and they'll improve by
the time, I guess... We can make the documentation better, but that's
a different thing (though take into account that many beginners even don't
know how to understand the documentation and point their questions to
support forums). For example, I know many beginners who don't know about
many built-in functions in PHP (even basic ones, array_map, strpos etc.), I
don't think that if we got an idea of function that can be useful for the
majority of the PHP community that we shouldn't include it because
beginners won't know about it or how to use it - being a beginner always
result in not know or understand features...

I think that the result of this way of thinking is restricting advance
programmers while beginners could stick with the basic features of PHP,
leaving the advance concepts until they'll be ready to learn them.

Re: [PHP-DEV] Add runkit to PHP Runtime

[Etienne Kneuss]

On Fri, Aug 3, 2012 at 1:03 AM, Sara Golemon  wrote:
> For my vote: I think keeping this in pecl is fine, because they're all
> things which can be done from the extension space.

+1

> Yes, I've
> abandoned the package, but nothing is stopping someone else from
> taking it over.

It seems it has already been taken over: https://github.com/zenovich/runkit

-- 
Etienne Kneuss

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[Lester Caine]

Andrew Faulds wrote:

Lester, you complain about practically everything being complicated/breaking
compatibility/not working with PHP 5.2. Why complain here? It doesn't help the
signal:noise ratio to moan about something which has no direct effect on you.


When there is no negative responses it is taken that nobody objects to something 
being added. And currently even if we do object it still gets railroaded through 
on the basis we do not have to use it. Currently my main incomeis derived from 
using PHP so ALL of these changes have a direct effect on me ...


I've been put in touch with two major projects that are in the same boat as me 
currently and are now having to manage their transition from 5.2 to 5.4 on user 
sites so perhaps we can produce some usable documentation between us.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[Andrew Faulds]

Lester, you complain about practically everything being complicated/breaking 
compatibility/not working with PHP 5.2. Why complain here? It doesn't help the 
signal:noise ratio to moan about something which has no direct effect on you.


--
Sent from Samsung Mobile
Andrew Faulds
http://ajf.me/

Lester Caine  wrote:

Yahav Gindi Bar wrote:
> Maybe I'm wrong when comparing with other languages and mainly with
> ASP.NET(C#) since they've used it for web proposes but I did saw many
> classes that used this feature and personally really like it.

If ASP is so good why is it loosing market share?
Personally I'm pulling all the ASP sites I've inherited to PHP simply because 
the basic work flow in them is so bad.
And on some of the inherited PHP sites we have this peculiar concept of having 
to write a 'controller' for a new page, and then another PHP file with the 
content. But then am I 'old fashioned' using smarty, templating and storing all 
the content in a database? This idea of 'controllers' and 'interfaces' does not 
seem to produce a viable work flow to me, and certainly unravelling the code is 
a pain :(

> I've suggested to improve the language itself with some of the features in
> runkit, not to copy and use it as is.

People don't use half of the facilities that PHP already has so why start 
introducing concepts that make that even more difficult. Once again ... we need 
to explain a lot better how to write 'good programs' using what is currently 
available without loading the core down with even more eye candy that few 
people 
will ever understand fully. I'm still for stripping more stuff back to PECL and 
coming up with a good 'old fashioned' simple beginners version of PHP to which 
the eye candy only needs adding once one understands the basics ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[Lester Caine]

Yahav Gindi Bar wrote:

Maybe I'm wrong when comparing with other languages and mainly with
ASP.NET(C#) since they've used it for web proposes but I did saw many
classes that used this feature and personally really like it.


If ASP is so good why is it loosing market share?
Personally I'm pulling all the ASP sites I've inherited to PHP simply because 
the basic work flow in them is so bad.
And on some of the inherited PHP sites we have this peculiar concept of having 
to write a 'controller' for a new page, and then another PHP file with the 
content. But then am I 'old fashioned' using smarty, templating and storing all 
the content in a database? This idea of 'controllers' and 'interfaces' does not 
seem to produce a viable work flow to me, and certainly unravelling the code is 
a pain :(



I've suggested to improve the language itself with some of the features in
runkit, not to copy and use it as is.


People don't use half of the facilities that PHP already has so why start 
introducing concepts that make that even more difficult. Once again ... we need 
to explain a lot better how to write 'good programs' using what is currently 
available without loading the core down with even more eye candy that few people 
will ever understand fully. I'm still for stripping more stuff back to PECL and 
coming up with a good 'old fashioned' simple beginners version of PHP to which 
the eye candy only needs adding once one understands the basics ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[Yahav Gindi Bar]

On Fri, Aug 3, 2012 at 5:46 AM, Sherif Ramadan wrote:

> >
> > I don't see why this is not a good programming practice, lets get the
> > following example:
> > class Member {
> > public static function create(...) { }
> > public function update(...) { }
> > public function remove(...) { }
> > // ...
> > }
> >
> > now you wish to add, for example, a ban functionally to this member
> class -
> > I don't see a good reason to extend this class - it doesn't answer on the
> > OO concept and just make things complex and even wrong in OOP aspect.
> >
> > Another example I thought of is Reflection class - for example, the Zend
> > Framework got reflection classes that add more features to the built-in
> > Reflection classes - why shall the base Reflection classes has to be
> > extended (talking about the concept aspect)? the extending doesn't answer
> > on the OO concept and the programmers had to extend it only because they
> > can't add more features to class without extending it.
> >
>
>
> This was about as poor of an example as you could have picked. This is
> not a problem you should be looking to solve at runtime. It is
> certainly easier to solve this problem correctly via extending or
> coupling the class.

I can't agree with you, and you can see that other languages such I've
described take advantage of this idea. you can always solve ideas with many
ways - we're looking for making things easier and I think that this ability
can answer that.

Okay, so my examples is one of the basic things I thought about as a
frameworks and CMS developer.. but I do see other pros to this - such as no
need to cast returned object to your own type if you should not extend it
(because of OO concept), or for example it'll make easier to create hooks
for MVC controllers, or for example you got an HtmlHelper class that you're
using in your views - you can't add your own helper function unless you're
providing a logic with __call that loading a third-party classes from a
directory / looking for registered classes and then searching for the
method and invoking it - I think that the extension feature is really
useful in cases like that.


> I don't understand why you believe digging into the guts of a class at
> runtime and adding new methods to it is a good idea or why extending a
> class in order to add to or alter its functionality in some way is not
> an Object Oriented concept. Classes should be closed for modification
> but open for (From SOLID OOP principle Open/Closed principle:
> http://en.wikipedia.org/wiki/Open/closed_principle). How this makes
> things *more* complicated is beyond me and you offer no compelling
> reason to believe that it is.
>
> Because extending and inheritance in OO is not something that should be
done when you wish to add methods to the same object but add methods and/or
properties to new object - if you're only create, fore example, your own
ReflectionClass just to add some new methods that could be added to the
same base class without change its meaning - it's not follows
the inheritance concept.


> I'm sorry, I see no viable argument to agree with you that any of this
> is a reason to put runkit (which was -- as stated by the original
> author of the extension -- nothing more than an experiment that was
> never meant to be complete for production) into PHP core.
>
It's okay :) that's why I've started that discussion before starting to
integrate runkit within the language and create a wiki page for the feature.


>
> I think runkit has some nice uses in situations that relate to unit
> testing or other special cases, but I see no reason to believe it will
> prove useful in a production environment, which appears to your
> primary motive. Since you stated that you would intend for this to be
> used in framework development and deployment such as in the case of
> deploying on a shared hosting environment where the user may not have
> super user rights to install new PHP extensions. This is simply going
> to indulge users to attempt solving their problems the wrong way.
> That's a poor approach.
>
Users could solve their way anytime using wrong approach and we can't stop
extending the language because user may use a feature in the "wrong way"...
for example, I saw many times that users use static and encapsulation
concept wrong - we can't do anything about it, I don't think this is a good
point... My point of view is - "if the user do know how, and in which cases
to use it" - will he/she'll benefit from it enough to add it into the core"
- I think that in this case yes.


> I would support further work on the runkit extension in PECL. Sara
> hasn't done any work on it lately, but I can see how furthering that
> extension will benefit the community. Just not to the extent that I
> believe it belongs in PHP core. At least not until its features prove
> to solve problems for the majority of users that they can not
> otherwise solve easily with the given language features. None of the
>

Re: [PHP-DEV] Add runkit to PHP Runtime

[Sara Golemon]

On Aug 2, 2012, at 17:16, Ángel González  wrote:

> On 03/08/12 01:22, Sara Golemon wrote:
>> In all seriousness, I'd love to hear how you'd do Sandboxing without
>> using the tsrm context hack I used in runkit.  That approach had
>> nothing to do with being in PECL, it had to do with that being the
>> only mechanism available to swap globals in and out at will.
> Actually, you could replace the whole EG() struct. It'd be slower, but
> it should work flawlessly.
> 
What about FG, EX, PG, MYSQLG, etc...  God forbid you have an extension loaded 
which won't react well to having some globals replaced, but not its own.

Give me some credit, I considered that option some half a decade ago. :p
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[Sean Coates]

> For my vote: I think keeping this in pecl is fine, because they're all
> things which can be done from the extension space.

If my vote still counts (I was somehow involved in the creation of runkit at 
one point (-: ), I say the same: extension is fine. Don't monkeypatch 
production.

S

Re: [PHP-DEV] Add runkit to PHP Runtime

[Sherif Ramadan]

>
> I don't see why this is not a good programming practice, lets get the
> following example:
> class Member {
> public static function create(...) { }
> public function update(...) { }
> public function remove(...) { }
> // ...
> }
>
> now you wish to add, for example, a ban functionally to this member class -
> I don't see a good reason to extend this class - it doesn't answer on the
> OO concept and just make things complex and even wrong in OOP aspect.
>
> Another example I thought of is Reflection class - for example, the Zend
> Framework got reflection classes that add more features to the built-in
> Reflection classes - why shall the base Reflection classes has to be
> extended (talking about the concept aspect)? the extending doesn't answer
> on the OO concept and the programmers had to extend it only because they
> can't add more features to class without extending it.
>


This was about as poor of an example as you could have picked. This is
not a problem you should be looking to solve at runtime. It is
certainly easier to solve this problem correctly via extending or
coupling the class.

I don't understand why you believe digging into the guts of a class at
runtime and adding new methods to it is a good idea or why extending a
class in order to add to or alter its functionality in some way is not
an Object Oriented concept. Classes should be closed for modification
but open for (From SOLID OOP principle Open/Closed principle:
http://en.wikipedia.org/wiki/Open/closed_principle). How this makes
things *more* complicated is beyond me and you offer no compelling
reason to believe that it is.

I'm sorry, I see no viable argument to agree with you that any of this
is a reason to put runkit (which was -- as stated by the original
author of the extension -- nothing more than an experiment that was
never meant to be complete for production) into PHP core.

I think runkit has some nice uses in situations that relate to unit
testing or other special cases, but I see no reason to believe it will
prove useful in a production environment, which appears to your
primary motive. Since you stated that you would intend for this to be
used in framework development and deployment such as in the case of
deploying on a shared hosting environment where the user may not have
super user rights to install new PHP extensions. This is simply going
to indulge users to attempt solving their problems the wrong way.
That's a poor approach.

I would support further work on the runkit extension in PECL. Sara
hasn't done any work on it lately, but I can see how furthering that
extension will benefit the community. Just not to the extent that I
believe it belongs in PHP core. At least not until its features prove
to solve problems for the majority of users that they can not
otherwise solve easily with the given language features. None of the
aforementioned reasons in your reply indicate this thus far.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[Yahav Gindi Bar]

On Fri, Aug 3, 2012 at 3:07 AM, Anthony Ferrara  wrote:

> Yahav,
>
>
> On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar wrote:
>
>> I do think that some of  the runkit features should not be included in PHP
>> core but I wish to focus on extending classes with extension methods,
>> constants, traits and members.
>>
>> Just like all other complicated and powerful features in PHP, one should
>> use them with a good reason and when he/she knows exacly what he/she is
>> doing - but we should provide the tools and ability to do that - that's
>> what I think..
>>
>> I see the main usage for extension methods within frameworks and other big
>> applications that allows third-party integration such as CMS, forums
>> software etc. - in such kind of applications, extension methods can be
>> very
>> useful, and you can take for example the many usage of this in
>> ASP.NET applications
>>
>> that uses this concept (even if we'll take Objective-C, you can find on
>> the
>> net many implementation of features for UI controls that was added via
>> extension method since there's no OO based reason to create a child class
>> -
>> for example, many added method for setting background image to UIView type
>> object as an extension method).
>>
>> I don't think that this features should remain in PECL package (that's the
>> reason I've created this discussion) since frameworks and software that
>> third-party users will use should not relay on PECL packages... many users
>> who use frameworks and CMS use shared hosting enviorment and don't have
>> permissions to install PECL packages - if we want to bring this feature
>> and
>> give such scripts to use this features we shall deeply integrate it to the
>> core of PHP - just like I've suggested above, I think that a new keyword
>> or
>> syntax should be introduced for this usage.
>>
>
>

> I wholeheartedly disagree towards this line of thinking. The ability to
> add and rename functions/methods dynamically to already defined constructs
> is going to do nothing but cause problems. For example, let's say that
> you're working with a class, and using it in one area of your application.
> Then you want to go re-use it in another application. All of a sudden, it
> stops working for non-obvious reasons. As it turns out, it was because the
> class was modified in some corner of the code elsewhere on the page. And
> the only real way to find that out is to step through it in xdebug to see
> where the trace goes (or dig through reflection to try to take a stab in
> the dark)...
>
>
I didn't mentioned renaming or removing methods - only the ability to add
new methods, constants and class members into existsing classes. If we're
only talking about adding methods - such problem won't be occur since if
you're calling an extension method you should know that it exists. for
example - I can get the same problem if I'm using the magic methods - you
could say that because the magic method work in some way that invoke a
method one should run xdebug and trace where the method goes and why it's
work the way it's work.


> Now, I know you brought up other languages. I'm glad you did. PHP is not
> other languages. Other languages have first-class meta-classes that let you
> directly do things like this to. But they also don't have support for
> contract based programming (interfaces) or things like autoloading (both
> which are problematic with this approach). So unless we wanted to drop
> interfaces (big -1 from my book) or implement a first-class meta-class
> structure for all classes (huge +1, if done right), then this is only going
> to hurt things.
>

I've brought up other languages because I think that this is a pro when
comparing them to PHP that we should integrate into PHP too - for example,
if we're talking about C# "lock" keyword - although it's quite helpful I
don't think it should be implemented in PHP. Both languages I've brought
for comprasion - C# and Objective-C got interfaces (C# got very rich OO).
Yes, as long as I know they don't support autoloading but I don't see any
problem with that because the autoload should remain the same.


So I'm against adding functionality that makes implementing architectural
> flaws easier while doing nothing for good programming practices...
>
> Anthony
>

I don't see why this is not a good programming practice, lets get the
following example:
class Member {
public static function create(...) { }
public function update(...) { }
public function remove(...) { }
// ...
}

now you wish to add, for example, a ban functionally to this member class -
I don't see a good reason to extend this class - it doesn't answer on the
OO concept and just make things complex and even wrong in OOP aspect.

Another example I thought of is Reflection class - for example, the Zend
Framework got reflection classes that add more features to the built-in
Reflection classes - why shall the base Reflection classes has to be
extended (talking about

Re: [PHP-DEV] Add runkit to PHP Runtime

[Ángel González]

On 03/08/12 01:22, Sara Golemon wrote:
> In all seriousness, I'd love to hear how you'd do Sandboxing without
> using the tsrm context hack I used in runkit.  That approach had
> nothing to do with being in PECL, it had to do with that being the
> only mechanism available to swap globals in and out at will.
Actually, you could replace the whole EG() struct. It'd be slower, but
it should work flawlessly.

Regards


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[Anthony Ferrara]

Yahav,

On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar  wrote:

> I do think that some of  the runkit features should not be included in PHP
> core but I wish to focus on extending classes with extension methods,
> constants, traits and members.
>
> Just like all other complicated and powerful features in PHP, one should
> use them with a good reason and when he/she knows exacly what he/she is
> doing - but we should provide the tools and ability to do that - that's
> what I think..
>
> I see the main usage for extension methods within frameworks and other big
> applications that allows third-party integration such as CMS, forums
> software etc. - in such kind of applications, extension methods can be very
> useful, and you can take for example the many usage of this in
> ASP.NET applications
> that uses this concept (even if we'll take Objective-C, you can find on the
> net many implementation of features for UI controls that was added via
> extension method since there's no OO based reason to create a child class -
> for example, many added method for setting background image to UIView type
> object as an extension method).
>
> I don't think that this features should remain in PECL package (that's the
> reason I've created this discussion) since frameworks and software that
> third-party users will use should not relay on PECL packages... many users
> who use frameworks and CMS use shared hosting enviorment and don't have
> permissions to install PECL packages - if we want to bring this feature and
> give such scripts to use this features we shall deeply integrate it to the
> core of PHP - just like I've suggested above, I think that a new keyword or
> syntax should be introduced for this usage.


I wholeheartedly disagree towards this line of thinking. The ability to add
and rename functions/methods dynamically to already defined constructs is
going to do nothing but cause problems. For example, let's say that you're
working with a class, and using it in one area of your application. Then
you want to go re-use it in another application. All of a sudden, it stops
working for non-obvious reasons. As it turns out, it was because the class
was modified in some corner of the code elsewhere on the page. And the only
real way to find that out is to step through it in xdebug to see where the
trace goes (or dig through reflection to try to take a stab in the dark)...

Now, I know you brought up other languages. I'm glad you did. PHP is not
other languages. Other languages have first-class meta-classes that let you
directly do things like this to. But they also don't have support for
contract based programming (interfaces) or things like autoloading (both
which are problematic with this approach). So unless we wanted to drop
interfaces (big -1 from my book) or implement a first-class meta-class
structure for all classes (huge +1, if done right), then this is only going
to hurt things.

Besides, there are ways to solve this problem today. You can implement
decorators and bridges to solve this problem in a reusable and easy to
understand way. Sure, it makes it hard to do dirty things (like insert a
function in a parent of an inherited object), but you shouldn't be doing
those things anyway (if you find a need for something like that, you have a
*major* architectural flaw).

So I'm against adding functionality that makes implementing architectural
flaws easier while doing nothing for good programming practices...

Anthony

Re: [PHP-DEV] Add runkit to PHP Runtime

[Yahav Gindi Bar]

I do think that some of  the runkit features should not be included in PHP
core but I wish to focus on extending classes with extension methods,
constants, traits and members.

Just like all other complicated and powerful features in PHP, one should
use them with a good reason and when he/she knows exacly what he/she is
doing - but we should provide the tools and ability to do that - that's
what I think..

I see the main usage for extension methods within frameworks and other big
applications that allows third-party integration such as CMS, forums
software etc. - in such kind of applications, extension methods can be very
useful, and you can take for example the many usage of this in
ASP.NET applications
that uses this concept (even if we'll take Objective-C, you can find on the
net many implementation of features for UI controls that was added via
extension method since there's no OO based reason to create a child class -
for example, many added method for setting background image to UIView type
object as an extension method).

I don't think that this features should remain in PECL package (that's the
reason I've created this discussion) since frameworks and software that
third-party users will use should not relay on PECL packages... many users
who use frameworks and CMS use shared hosting enviorment and don't have
permissions to install PECL packages - if we want to bring this feature and
give such scripts to use this features we shall deeply integrate it to the
core of PHP - just like I've suggested above, I think that a new keyword or
syntax should be introduced for this usage.

On Fri, Aug 3, 2012 at 2:22 AM, Sara Golemon  wrote:

> On Thu, Aug 2, 2012 at 4:17 PM, Leigh  wrote:
> >> Sandboxing: Complicated by the fact that it only works in a threaded
> >> build, can't transfer all types (e.g. resource, complex objects), and
> >> can't run concurrently.  Until/unless these problems can be
> >> meaningfully solved, I wouldn't consider it a functional
> >> implementation.
> >
> > To me the "thread thing" feels like the dirty hack workaround
> > _because_ it's in PECL, and this is the only option available.
> >
> In all seriousness, I'd love to hear how you'd do Sandboxing without
> using the tsrm context hack I used in runkit.  That approach had
> nothing to do with being in PECL, it had to do with that being the
> only mechanism available to swap globals in and out at will.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Add runkit to PHP Runtime

[Sara Golemon]

On Thu, Aug 2, 2012 at 4:17 PM, Leigh  wrote:
>> Sandboxing: Complicated by the fact that it only works in a threaded
>> build, can't transfer all types (e.g. resource, complex objects), and
>> can't run concurrently.  Until/unless these problems can be
>> meaningfully solved, I wouldn't consider it a functional
>> implementation.
>
> To me the "thread thing" feels like the dirty hack workaround
> _because_ it's in PECL, and this is the only option available.
>
In all seriousness, I'd love to hear how you'd do Sandboxing without
using the tsrm context hack I used in runkit.  That approach had
nothing to do with being in PECL, it had to do with that being the
only mechanism available to swap globals in and out at will.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[Leigh]

> Sandboxing: Complicated by the fact that it only works in a threaded
> build, can't transfer all types (e.g. resource, complex objects), and
> can't run concurrently.  Until/unless these problems can be
> meaningfully solved, I wouldn't consider it a functional
> implementation.

To me the "thread thing" feels like the dirty hack workaround
_because_ it's in PECL, and this is the only option available.

chroot() isn't available everywhere. chrooting with php-fpm requires
an additional amount of configuration (and forethought), and running
both a chrooted and non-chrooted pool even more so.

I did originally pose it as a potential v6 feature, and that's where
I'll leave it. In the "wouldn't it be nice" pile.

There's always going to be cases where products want to use
user-generated code, and isolating in a way that prevents it breaking
things is desirable. Having the right tools to do that instead of
requiring clunky workarounds "would be nice" when the engine can
support it.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[Sara Golemon]

"For all those things you probably shouldn't have been doing anyway"
That description is on the package because you... probably shouldn't
be doing these things.

Further, any discussion of runkit should focus on individual features of it.

Custom Superglobals: I consider these fairly harmless so long as
developers follow strict rules about naming them, but if you want
superglobals, you probably need to rethink some part of your
architecture.

Monkeypatching: Several good use-cases for this (unit tests, among
others), but like all powerful features, must be used with care.

Sandboxing: Complicated by the fact that it only works in a threaded
build, can't transfer all types (e.g. resource, complex objects), and
can't run concurrently.  Until/unless these problems can be
meaningfully solved, I wouldn't consider it a functional
implementation.

For my vote: I think keeping this in pecl is fine, because they're all
things which can be done from the extension space.  Yes, I've
abandoned the package, but nothing is stopping someone else from
taking it over.

-Sara

On Thu, Aug 2, 2012 at 2:28 PM, dukeofgaming  wrote:
>
> This is a great idea (the runkit, not the rootkit).
>
> On Thu, Aug 2, 2012 at 1:12 PM, Kris Craig  wrote:
>
> > >
> > > What do you think?
> > >
> >
> > I think I need to get my lens prescription updated.  I thought the subject
> > line read, "Add *rootkit *to PHP Runtime" and was already sharpening my
> > pitchfork before I realized my error.
> >
> > For the record, I am firmly opposed to adding a rootkit to the PHP runtime.
> >  A runkit sounds pretty cool, though.  ;)
> >
> > --Kris
> >

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add runkit to PHP Runtime

[dukeofgaming]

This is a great idea (the runkit, not the rootkit).

On Thu, Aug 2, 2012 at 1:12 PM, Kris Craig  wrote:

> >
> > What do you think?
> >
>
> I think I need to get my lens prescription updated.  I thought the subject
> line read, "Add *rootkit *to PHP Runtime" and was already sharpening my
> pitchfork before I realized my error.
>
> For the record, I am firmly opposed to adding a rootkit to the PHP runtime.
>  A runkit sounds pretty cool, though.  ;)
>
> --Kris
>

Re: [PHP-DEV] Add runkit to PHP Runtime

[Kris Craig]

>
> What do you think?
>

I think I need to get my lens prescription updated.  I thought the subject
line read, "Add *rootkit *to PHP Runtime" and was already sharpening my
pitchfork before I realized my error.

For the record, I am firmly opposed to adding a rootkit to the PHP runtime.
 A runkit sounds pretty cool, though.  ;)

--Kris

Re: [PHP-DEV] Add runkit to PHP Runtime

[Yahav Gindi Bar]

On Thu, Aug 2, 2012 at 7:56 PM, Leigh  wrote:

>
> On Aug 2, 2012 5:44 PM, "Yahav Gindi Bar"  wrote:
> >
> > Hi,
> >
> > I don't know how to tag this kind of discussion (because it's not RFC
> > request).
> > I've interested in runkit PECL extension and think that it should be part
> > of the PHP core runtime.
> >
> > I do think that the implementation should be different and don't mind to
> > suggest my implementation as RFC, but firstly I wish to know if you think
> > that the core idea to be able to add extension methods to classes is good
> > idea, so I won't start to implement a new feature without a reason (I'd
> > start it but since I've saw runkit I think that we can discuss the idea
> > first).
> >
> > I think that a code similier to this will be great:
> >
> > class Foo {
> >  public function foo() { }
> > }
> >
> > class Bar extensionfor Foo {
> > public function bar() { }
> > }
> >
> > (new Foo())->bar(); // execute Bar method
> >
> > I see many pros about this feature, and you can see it in C# and ObjC
> too.
> > Shall I open for it a wiki page and start RFC discussion?
> > What do you think?
>
> I think a lot of runtime features could be useful, but require tight
> integration to be "done right". Maybe a candidate for 6.0 features?
>
> I'd personally be interested in the ability to hook built-in functions and
> sandboxing.
>

I agree, the runkit is excellent but has to be deeply integrated to the
language - for example, add methods to the Reflection extension to find out
which methods added by extension methods etc.

Regard the implementation - I saw and used several ways of implementing it,
and do think that because one of the important pros of PHP is the language
writing style which is nice and clean - we should think of good syntax.

for example, C# request to add "this" keyword before each extension method,
and require the class and methods to be static - for instance:
public static class Bar {
 public static void bar(this Foo obj) { }
 public static int baz(this Foo obj, int bar);
}

new Foo().baz(1);

On Thu, Aug 2, 2012 at 7:56 PM, Leigh  wrote:

>
> On Aug 2, 2012 5:44 PM, "Yahav Gindi Bar"  wrote:
> >
> > Hi,
> >
> > I don't know how to tag this kind of discussion (because it's not RFC
> > request).
> > I've interested in runkit PECL extension and think that it should be part
> > of the PHP core runtime.
> >
> > I do think that the implementation should be different and don't mind to
> > suggest my implementation as RFC, but firstly I wish to know if you think
> > that the core idea to be able to add extension methods to classes is good
> > idea, so I won't start to implement a new feature without a reason (I'd
> > start it but since I've saw runkit I think that we can discuss the idea
> > first).
> >
> > I think that a code similier to this will be great:
> >
> > class Foo {
> >  public function foo() { }
> > }
> >
> > class Bar extensionfor Foo {
> > public function bar() { }
> > }
> >
> > (new Foo())->bar(); // execute Bar method
> >
> > I see many pros about this feature, and you can see it in C# and ObjC
> too.
> > Shall I open for it a wiki page and start RFC discussion?
> > What do you think?
>
>  I think a lot of runtime features could be useful, but require tight
> integration to be "done right". Maybe a candidate for 6.0 features?
>
> I'd personally be interested in the ability to hook built-in functions and
> sandboxing.
>

Re: [PHP-DEV] Add runkit to PHP Runtime

[Leigh]

On Aug 2, 2012 5:44 PM, "Yahav Gindi Bar"  wrote:
>
> Hi,
>
> I don't know how to tag this kind of discussion (because it's not RFC
> request).
> I've interested in runkit PECL extension and think that it should be part
> of the PHP core runtime.
>
> I do think that the implementation should be different and don't mind to
> suggest my implementation as RFC, but firstly I wish to know if you think
> that the core idea to be able to add extension methods to classes is good
> idea, so I won't start to implement a new feature without a reason (I'd
> start it but since I've saw runkit I think that we can discuss the idea
> first).
>
> I think that a code similier to this will be great:
>
> class Foo {
>  public function foo() { }
> }
>
> class Bar extensionfor Foo {
> public function bar() { }
> }
>
> (new Foo())->bar(); // execute Bar method
>
> I see many pros about this feature, and you can see it in C# and ObjC too.
> Shall I open for it a wiki page and start RFC discussion?
> What do you think?

I think a lot of runtime features could be useful, but require tight
integration to be "done right". Maybe a candidate for 6.0 features?

I'd personally be interested in the ability to hook built-in functions and
sandboxing.