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?
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.
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);
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.
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
This is a great idea (the runkit, not the rootkit).
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
"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
This is a great idea (the runkit, not the rootkit).
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
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.
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.
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.NEThttp://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.
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.
Yahav,
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.NEThttp://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
Yahav,
On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar g.b.yahav@gmail.comwrote:
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.NEThttp://asp.net/ applicationsthat 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 classfor 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 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.
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.
On Fri, Aug 3, 2012 at 5:46 AM, Sherif Ramadan theanomaly.is@gmail.comwrote:
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
aforementioned reasons in your reply indicate this thus far.
It's remind me the discussion of Generators...
Lets take for example the lambda functions - you can solve your problem
easily enough in the given language (using create_function, eval..) but
it's still a great feature in the language (This is my opinion though...)
Although I can't say for sure that it can help for the majority of the PHP
developers, I can say that there's many developers who use frameworks in
order to develop their applications and I think that these frameworks will
take advantage of this feature and will result in that these many developer
will use them too - for example, like I've suggested above - extending
controllers, adding their own function to existing classes without
overriding them etc.
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 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.
I've suggested to improve the language itself with some of the features in
runkit, not to copy and use it as is.
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
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 manyclasses 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.
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
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
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
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