Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

[Alexander Moskalev]

Thanks to all for feedback!

Let's try to integrate new feature to old class.
We have constructor in CURLFile with one required parameter: $filename .
To avoid BC break we cannot replace this parameter. So  I suggest to do it
optional and add setBuffer() method.

So we can create CURLFile with empty parameters in constructor and fill it
with setters.
Have two more questions:
1) If we not fill all options or fille not compatible options, when we must
throw error? ? And what level of this error? (Sorry, I'm just php coder and
know about C language and php source so little)
For file from disk(or other source) required $filename. For file from
buffer required $buffer and $postname.
2) Curently CURLFile cannot be unserialized, because it contains $filename
(see source code). How it compatible with our dicussion?


Jakub, I think about static factory methods, but not sure if it will be
great.
 I think using empty constructor more clear.

[PHP-DEV] request priviledges to create an RFC or at least submit a suggestion

[Dmitri Goosens]

Hi PHP-fellows
or whoever reads this…

I’m a Belgian PHP addict and feel I’ve got a suggestion that might be of
interest for PHP7.
I’d more than glad to write it down completely in an RFC if you grant me
access, otherwise, maybe someone can do it.
My username is *dgoosens*.

I feel, a natural evolution of the scalar type hinting would be the
possibility to type hint arrays as well…
That means, not the array itself, obviously, but the items that are in the
array.

Right now we have

array $foo = array();

What I’d like to see is something like this:

string[] $foo = array(); // an array that can only contain
stringsarray[string[]] $foo = array(); // an array that can only
contain arrays that contain stringsBar[] $foo = array(); // an array
that can only contain instances of Bar

There probably are some side effects to this and maybe I’m not aware enough
about PHP’s internals, but I think this implementation would have a series
of benefits…

*1. function attributes type hinting*

public function bar(string[] $foo = array()){
/*No need to validate the data in $foo as we already know that
it will only contain strings*/}

*2. class attributes*

class foo
{
public $foo = string[];
}
$bar = new foo();$bar->foo[] = 'only strings are allowed here';

etc. etc.

I feel this would be a very nice improvement in PHP…

Thanks

dgoosens

[PHP-DEV] PDO Oracle driver

[Stelian Mocanita]

Hello internals,

I would like to ask what on your thoughts on removing the Oracle drive for
PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
at least since it's been experimental for a long time now, and it has long
standing open bugs, such as:

https://bugs.php.net/bug.php?id=37706
https://bugs.php.net/bug.php?id=46728
https://bugs.php.net/bug.php?id=60994

I know that the extension is marked as experimental already but based on
the current status, it's not even that and a significant amount of basic
functionality is broken.

Regards,
Stelian

Re: [PHP-DEV] PDO Oracle driver

[Marco Pivetta]

Absolutely +1 - most developers are dragged into using the PDO Oracle
driver by "hope" (since they find the docs), and then they get to know the
sad truth about it...

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 22 April 2015 at 10:40, Stelian Mocanita 
wrote:

> Hello internals,
>
> I would like to ask what on your thoughts on removing the Oracle drive for
> PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
> at least since it's been experimental for a long time now, and it has long
> standing open bugs, such as:
>
> https://bugs.php.net/bug.php?id=37706
> https://bugs.php.net/bug.php?id=46728
> https://bugs.php.net/bug.php?id=60994
>
> I know that the extension is marked as experimental already but based on
> the current status, it's not even that and a significant amount of basic
> functionality is broken.
>
> Regards,
> Stelian
>

Re: [PHP-DEV] LDAP module enhancements

[Andreas Heigl]

Hi Côme.

According to the gophp7-ext project the LDAP module isn't maintained.
(I've just looked it up this morning). See
https://github.com/gophp7/gophp7-ext/wiki/extensions-catalog. Would you
want or consider thinking about taking over?

Cheers

Andreas

Am 21.04.15 um 09:18 schrieb Côme BERNIGAUD:
> Hello,
> 
> I opened a few bugs on https://bugs.php.net/ about improvements for the
> LDAP module.
> In this one I’ve put a patch: https://bugs.php.net/bug.php?id=69471
> I’m writing here because I’m not sure of the right way of submitting
> patches,
>  either here, the bug tracker, or github PR.
> 
> I’m also a bit worried because there are bugs opened since a long time
> with no update
>  while they contain patches on similar subjects:
> https://bugs.php.net/bug.php?id=61853
> Also, on github, https://github.com/php/php-src/pull/652 is related to
>  https://bugs.php.net/bug.php?id=69437 and never had any response (it is
> a year old).
> 
> In the EXTENSIONS file in php-src git, the LDAP module is noted as
>  «MAINTENANCE: Maintained» which is defined as «Maintained: Someone
> actually looks after it.».
> Is that still the case? I’m sending people listed as maintainers a copy
> of this email to be sure.
> 
> Côme
> 


-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PHP-DEV] PDO Oracle driver

[Paul Dragoonis]

+1 from me. If nobody is maintaining it then it's a big risk. It should be
brought back in when there's people to maintain it.

On Wed, Apr 22, 2015 at 10:42 AM, Marco Pivetta  wrote:

> Absolutely +1 - most developers are dragged into using the PDO Oracle
> driver by "hope" (since they find the docs), and then they get to know the
> sad truth about it...
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 22 April 2015 at 10:40, Stelian Mocanita 
> wrote:
>
> > Hello internals,
> >
> > I would like to ask what on your thoughts on removing the Oracle drive
> for
> > PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php
> )
> > at least since it's been experimental for a long time now, and it has
> long
> > standing open bugs, such as:
> >
> > https://bugs.php.net/bug.php?id=37706
> > https://bugs.php.net/bug.php?id=46728
> > https://bugs.php.net/bug.php?id=60994
> >
> > I know that the extension is marked as experimental already but based on
> > the current status, it's not even that and a significant amount of basic
> > functionality is broken.
> >
> > Regards,
> > Stelian
> >
>

Re: [PHP-DEV] PDO Oracle driver

[Chris Wright]

On 22 April 2015 at 10:40, Stelian Mocanita 
wrote:

> Hello internals,
>
> I would like to ask what on your thoughts on removing the Oracle drive for
> PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
> at least since it's been experimental for a long time now, and it has long
> standing open bugs, such as:
>
> https://bugs.php.net/bug.php?id=37706
> https://bugs.php.net/bug.php?id=46728
> https://bugs.php.net/bug.php?id=60994
>
> I know that the extension is marked as experimental already but based on
> the current status, it's not even that and a significant amount of basic
> functionality is broken.
>
> Regards,
> Stelian
>

It shouldn't just be undocumented and the src left in core, it should
probably be moved to PECL .

Also, it would be good to know what those who have worked on this in the
past consider the state of this extension to be. The last commit I can see
that was directly related to it (as opposed to project-wide fixes like
find/replace for new macros, big blobs of typo fixes etc) was in 2011, but
it looks like a few people have put a fair amount of work in prior to
that... are there any technical blockers on progress, or is it simply that
there's not enough demand for it/people haven't had the time to work on it?

Re: [PHP-DEV] PDO Oracle driver

[Peter Cowburn]

cc-ing doc list

On 22 April 2015 at 10:40, Stelian Mocanita 
wrote:

> Hello internals,
>
> I would like to ask what on your thoughts on removing the Oracle drive for
> PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
> at least since it's been experimental for a long time now, and it has long
> standing open bugs, such as:
>
> https://bugs.php.net/bug.php?id=37706
> https://bugs.php.net/bug.php?id=46728
> https://bugs.php.net/bug.php?id=60994
>
> I know that the extension is marked as experimental already but based on
> the current status, it's not even that and a significant amount of basic
> functionality is broken.
>
> Regards,
> Stelian
>

Re: [PHP-DEV] PDO Oracle driver

[Benjamin Eberlei]

On Wed, Apr 22, 2015 at 12:24 PM, Peter Cowburn 
wrote:

> cc-ing doc list
>
> On 22 April 2015 at 10:40, Stelian Mocanita 
> wrote:
>
> > Hello internals,
> >
> > I would like to ask what on your thoughts on removing the Oracle drive
> for
> > PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php
> )
> > at least since it's been experimental for a long time now, and it has
> long
> > standing open bugs, such as:
> >
> > https://bugs.php.net/bug.php?id=37706
> > https://bugs.php.net/bug.php?id=46728
> > https://bugs.php.net/bug.php?id=60994
> >
> > I know that the extension is marked as experimental already but based on
> > the current status, it's not even that and a significant amount of basic
> > functionality is broken.
>

When working on Doctrine support for Oracle we quickly realized that a lot
of bugfixes are done in oci8, but PDO_OCI doesnt get them.

A big +1 from me for removing this extension from core, given its critical
bugs/segfaults with simple features like CLOBs i cannot recommend it to
anyone.


> >
> > Regards,
> > Stelian
> >
>

Re: [PHP-DEV] PDO Oracle driver

[Matteo Beccati]

/cc cjones

On 22/04/2015 11:40, Stelian Mocanita wrote:

Hello internals,

I would like to ask what on your thoughts on removing the Oracle drive for
PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
at least since it's been experimental for a long time now, and it has long
standing open bugs, such as:

https://bugs.php.net/bug.php?id=37706
https://bugs.php.net/bug.php?id=46728
https://bugs.php.net/bug.php?id=60994

I know that the extension is marked as experimental already but based on
the current status, it's not even that and a significant amount of basic
functionality is broken.

Regards,
Stelian




--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

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

Re: [PHP-DEV] PDO Oracle driver

[Peter Cowburn]

On 22 April 2015 at 11:24, Peter Cowburn  wrote:

> cc-ing doc list
>
> On 22 April 2015 at 10:40, Stelian Mocanita 
> wrote:
>
>> Hello internals,
>>
>> I would like to ask what on your thoughts on removing the Oracle drive for
>> PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
>> at least since it's been experimental for a long time now, and it has long
>> standing open bugs, such as:
>>
>
>From the documentation point of view:

Just because an extension is considered experimental, or indeed
unmaintained, is no reason to remove the extension from the manual.  We
have a bunch of extensions marked as experimental [1] or dead [2] and I
don't see why pdo_oci should be any different.


>
>> https://bugs.php.net/bug.php?id=37706
>> https://bugs.php.net/bug.php?id=46728
>> https://bugs.php.net/bug.php?id=60994
>>
>> I know that the extension is marked as experimental already but based on
>> the current status, it's not even that and a significant amount of basic
>> functionality is broken.
>>
>
Let's mark the extension as "dead" in the manual, as we do with other dead
extensions.


>
>> Regards,
>> Stelian
>>
>
>
[1] bcompiler, blenc, dbplus, haru, memtrack, ming, paradox, pdo_4d,
pdo_oci, sca, sdodasrel, spl_types, svn, swish, vpopmail, xmlrpc
[2] classkit, fam, fdf, iisfunc, msession, nis, session_pgsql

Re: [PHP-DEV] PDO Oracle driver

[Stelian Mocanita]

Peter,

I did not know about the documentation part, thanks for clearing that out.

I would like to ask though, what is the benefit of having the dead
extensions there?
>From my point of view, it does more harm than good having them in the
manual
(I am only referring here to extensions that never got to a production
grade).

On marking the extension as dead, how would we proceed in this case?

Thank you,
Stelian

On Wed, Apr 22, 2015 at 12:34 PM, Peter Cowburn 
wrote:

>
>
> On 22 April 2015 at 11:24, Peter Cowburn  wrote:
>
>> cc-ing doc list
>>
>> On 22 April 2015 at 10:40, Stelian Mocanita 
>> wrote:
>>
>>> Hello internals,
>>>
>>> I would like to ask what on your thoughts on removing the Oracle drive
>>> for
>>> PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php
>>> )
>>> at least since it's been experimental for a long time now, and it has
>>> long
>>> standing open bugs, such as:
>>>
>>
> From the documentation point of view:
>
> Just because an extension is considered experimental, or indeed
> unmaintained, is no reason to remove the extension from the manual.  We
> have a bunch of extensions marked as experimental [1] or dead [2] and I
> don't see why pdo_oci should be any different.
>
>
>>
>>> https://bugs.php.net/bug.php?id=37706
>>> https://bugs.php.net/bug.php?id=46728
>>> https://bugs.php.net/bug.php?id=60994
>>>
>>> I know that the extension is marked as experimental already but based on
>>> the current status, it's not even that and a significant amount of basic
>>> functionality is broken.
>>>
>>
> Let's mark the extension as "dead" in the manual, as we do with other dead
> extensions.
>
>
>>
>>> Regards,
>>> Stelian
>>>
>>
>>
> [1] bcompiler, blenc, dbplus, haru, memtrack, ming, paradox, pdo_4d,
> pdo_oci, sca, sdodasrel, spl_types, svn, swish, vpopmail, xmlrpc
> [2] classkit, fam, fdf, iisfunc, msession, nis, session_pgsql
>

Re: [PHP-DEV] PDO Oracle driver

[Peter Cowburn]

On 22 April 2015 at 11:40, Stelian Mocanita  wrote:

> Peter,
>
> I did not know about the documentation part, thanks for clearing that out.
>
> I would like to ask though, what is the benefit of having the dead
> extensions there?
> From my point of view, it does more harm than good having them in the
> manual
> (I am only referring here to extensions that never got to a production
> grade).
>
> On marking the extension as dead, how would we proceed in this case?
>

We have boilerplate text for marking PECL extensions as dead, and we would
use that again here.

However, I'd hold off on that until a decision (if any) has been made on
what to do with the extension itself, like moving it (back) to PECL. We
shouldn't be distributing a "dead" extension in the main php-src tree, nor
proclaiming an extension "dead" in the manual when that hasn't been
"officially" decided yet.


>
> Thank you,
> Stelian
>
>
> On Wed, Apr 22, 2015 at 12:34 PM, Peter Cowburn 
> wrote:
>
>>
>>
>> On 22 April 2015 at 11:24, Peter Cowburn  wrote:
>>
>>> cc-ing doc list
>>>
>>> On 22 April 2015 at 10:40, Stelian Mocanita 
>>> wrote:
>>>
 Hello internals,

 I would like to ask what on your thoughts on removing the Oracle drive
 for
 PDO from the documentation (
 http://us1.php.net/manual/en/ref.pdo-oci.php)
 at least since it's been experimental for a long time now, and it has
 long
 standing open bugs, such as:

>>>
>> From the documentation point of view:
>>
>> Just because an extension is considered experimental, or indeed
>> unmaintained, is no reason to remove the extension from the manual.  We
>> have a bunch of extensions marked as experimental [1] or dead [2] and I
>> don't see why pdo_oci should be any different.
>>
>>
>>>
 https://bugs.php.net/bug.php?id=37706
 https://bugs.php.net/bug.php?id=46728
 https://bugs.php.net/bug.php?id=60994

 I know that the extension is marked as experimental already but based on
 the current status, it's not even that and a significant amount of basic
 functionality is broken.

>>>
>> Let's mark the extension as "dead" in the manual, as we do with other
>> dead extensions.
>>
>>
>>>
 Regards,
 Stelian

>>>
>>>
>> [1] bcompiler, blenc, dbplus, haru, memtrack, ming, paradox, pdo_4d,
>> pdo_oci, sca, sdodasrel, spl_types, svn, swish, vpopmail, xmlrpc
>> [2] classkit, fam, fdf, iisfunc, msession, nis, session_pgsql
>>
>
>

Re: [PHP-DEV] PDO Oracle driver

[Lester Caine]

On 22/04/15 11:29, Benjamin Eberlei wrote:
> When working on Doctrine support for Oracle we quickly realized that a lot
> of bugfixes are done in oci8, but PDO_OCI doesnt get them.
> 
> A big +1 from me for removing this extension from core, given its critical
> bugs/segfaults with simple features like CLOBs i cannot recommend it to
> anyone.

It's not just PDO_OCI that is not getting as much love as other parts of
the database driver interface. The generic drivers are still preferred
over PDO which only provide a subset of engines. and PHP7 is going to
affect other areas of the database infrastructure so perhaps we just
need a review of all aspects?

-- 
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

[PHP-DEV] Re: PDO Oracle driver

[Christoph Becker]

Stelian Mocanita wrote:
>
> I would like to ask what on your thoughts on removing the Oracle drive for
> PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
> at least since it's been experimental for a long time now, and it has long
> standing open bugs, such as:
> 
> https://bugs.php.net/bug.php?id=37706
> https://bugs.php.net/bug.php?id=46728
> https://bugs.php.net/bug.php?id=60994
> 
> I know that the extension is marked as experimental already but based on
> the current status, it's not even that and a significant amount of basic
> functionality is broken.

The removal of pdo_oci had been suggested as part of the "Removal of
dead or not yet PHP7 ported SAPIs and extensions" RFC, but there has
been feedback from Christopher Jones, that the extension will be
supported by Oracle.[1]

[1]


-- 
Christoph M. Becker


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

[PHP-DEV] Re: request priviledges to create an RFC or at least submit a suggestion

[Christoph Becker]

Dmitri Goosens wrote:

> I’m a Belgian PHP addict and feel I’ve got a suggestion that might be of
> interest for PHP7.
> I’d more than glad to write it down completely in an RFC if you grant me
> access, otherwise, maybe someone can do it.

Information about creating an RFC can be found on

  

> My username is *dgoosens*.

If you already have registered with that name for a Wiki account, one of
the admins would have to approve it.  Otherwise you'd have to register
yourself at first.

> I feel, a natural evolution of the scalar type hinting would be the
> possibility to type hint arrays as well…
> That means, not the array itself, obviously, but the items that are in the
> array.

Note that there has been a related RFC a while ago, which has been
declined: .  It might be a good idea
to read the respective mailing list discussion:




-- 
Christoph M. Becker


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

[PHP-DEV] Re: request priviledges to create an RFC or at least submit a suggestion

[Dmitri Goosens]

Thanks a lot Christoph
Vielen Dank !


On Wed, Apr 22, 2015 at 1:51 PM, Christoph Becker  wrote:

> Dmitri Goosens wrote:
>
> > I’m a Belgian PHP addict and feel I’ve got a suggestion that might be of
> > interest for PHP7.
> > I’d more than glad to write it down completely in an RFC if you grant me
> > access, otherwise, maybe someone can do it.
>
> Information about creating an RFC can be found on
>
>   
>
> > My username is *dgoosens*.
>
> If you already have registered with that name for a Wiki account, one of
> the admins would have to approve it.  Otherwise you'd have to register
> yourself at first.
>
> > I feel, a natural evolution of the scalar type hinting would be the
> > possibility to type hint arrays as well…
> > That means, not the array itself, obviously, but the items that are in
> the
> > array.
>
> Note that there has been a related RFC a while ago, which has been
> declined: .  It might be a good idea
> to read the respective mailing list discussion:
>
>
> <
> http://grokbase.com/t/php/php-internals/141f1kzdm8/introducing-array-of-rfc
> >
>
> --
> Christoph M. Becker
>
>

Re: [PHP-DEV] LDAP module enhancements

[Côme BERNIGAUD]

On 2015-04-22 12:12, Andreas Heigl wrote:

Hi Côme.

According to the gophp7-ext project the LDAP module isn't maintained.
(I've just looked it up this morning). See
https://github.com/gophp7/gophp7-ext/wiki/extensions-catalog. Would you
want or consider thinking about taking over?


Sure, I’m ok to take over if possible.
Which actions are needed on my part?



Cheers

Andreas




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Closure::call() to access private data, really ?

[Julien Pauli]

On Mon, Apr 20, 2015 at 12:21 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > Just a simple use case showing how dangerous that is :
> >
> >  > $p = function($p) { $this->$p = new Stdclass; };
> > $p->call($e = new Exception, 'trace');
> > throw $e;
>
> Yes, this is not good, and this is the consequence of allowing to rebind
> closures. I'm not sure though how to fix it except for banning closures
> from assuming scope of internal classes. If you assigned the scope of
> Exception to it, it should have access to Exception - that's how the
> scope works.
>
> > For User classes, this could lead to information leaks or bad behaviors,
>
> I'm not sure what you mean by "information leaks", but the behavior is
> on whoever wrote that code. People can write bad code, we can't disallow
> this. We can restrict things that would really break (like segfault) but
> I'm not sure what else we can do here. If you have the scope of the
> class, that implies access to the private members of the class. So we
> either have to not let the closure have the scope, or invent some
> additional term of scope' that is not like real scope. I don't think
> it'd be good.
>


Yup Stas.

Perhaps the best thing to do is to forbid rebinding a Closure to an
internal class ?

I'm sure we could find segfaulting behaviors using such a trick on most of
our internals classes, aka mysqli, simplexmlelement, PDO or SPL classes.

Thoughts ?

Julien.P

[PHP-DEV] Re: PDO Oracle driver

[Stelian Mocanita]

>
> The removal of pdo_oci had been suggested as part of the "Removal of
> dead or not yet PHP7 ported SAPIs and extensions" RFC, but there has
> been feedback from Christopher Jones, that the extension will be
> supported by Oracle.[1]
> [1]
> <
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8
> >


Thanks for the info. Having Oracle supporting the extensions would be
great,
but I still feel like they should be re-released or something when they are
done.
While the OCI8 ext works with current versions, pdo_oci has been
experimental
for a long time and never reached maturity.

Maybe Christopher Jones can jump in here and shed some light on the matter.

Regards,
Stelian

On Wed, Apr 22, 2015 at 1:13 PM, Christoph Becker  wrote:

> Stelian Mocanita wrote:
> >
> > I would like to ask what on your thoughts on removing the Oracle drive
> for
> > PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php
> )
> > at least since it's been experimental for a long time now, and it has
> long
> > standing open bugs, such as:
> >
> > https://bugs.php.net/bug.php?id=37706
> > https://bugs.php.net/bug.php?id=46728
> > https://bugs.php.net/bug.php?id=60994
> >
> > I know that the extension is marked as experimental already but based on
> > the current status, it's not even that and a significant amount of basic
> > functionality is broken.
>
> The removal of pdo_oci had been suggested as part of the "Removal of
> dead or not yet PHP7 ported SAPIs and extensions" RFC, but there has
> been feedback from Christopher Jones, that the extension will be
> supported by Oracle.[1]
>
> [1]
> <
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8
> >
>
> --
> Christoph M. Becker
>
>

Re: [PHP-DEV] Re: PDO Oracle driver

[Pasindu De Silva]

On Wed, Apr 22, 2015 at 4:43 PM, Christoph Becker  wrote:
>
> [1]
> <
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8
> >


As of this RFC we probably can document that these extensions and sapis
are removed as of PHP 7.

-- 

*Pasindu De Silva**ppasin...@gmail.com *

Re: [PHP-DEV] Re: PDO Oracle driver

[Rowan Collins]

Pasindu De Silva wrote on 22/04/2015 14:44:

On Wed, Apr 22, 2015 at 4:43 PM, Christoph Becker  wrote:

[1]
<
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8


As of this RFC we probably can document that these extensions and sapis
are removed as of PHP 7.



I think you've misread that page. These extensions were not voted on for 
removal, because a maintainer stepped forward.


The current status in PHP 7 is therefore the same as the status in PHP 5.

Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Re: PDO Oracle driver

[Jonah H. Harris]

On Wed, Apr 22, 2015 at 9:39 AM, Stelian Mocanita <
stelian.mocan...@gmail.com> wrote:

> >
> > The removal of pdo_oci had been suggested as part of the "Removal of
> > dead or not yet PHP7 ported SAPIs and extensions" RFC, but there has
> > been feedback from Christopher Jones, that the extension will be
> > supported by Oracle.[1]
> > [1]
> > <
> >
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8
> > >
>
>
> Thanks for the info. Having Oracle supporting the extensions would be
> great,
> but I still feel like they should be re-released or something when they are
> done.
> While the OCI8 ext works with current versions, pdo_oci has been
> experimental
> for a long time and never reached maturity.
>
> Maybe Christopher Jones can jump in here and shed some light on the matter.
>

I'd prefer to keep it in the tree. Let me talk to the people I know at
Oracle and see. If they won't maintain it, my company will.

-- 
Jonah H. Harris
Blog: http://www.oracle-internals.com/

Re: [PHP-DEV] Re: PDO Oracle driver

[Christoph Becker]

Rowan Collins wrote:

> Pasindu De Silva wrote on 22/04/2015 14:44:
>> On Wed, Apr 22, 2015 at 4:43 PM, Christoph Becker 
>> wrote:
>>> [1]
>>> <
>>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8
>>>
>>
>> As of this RFC we probably can document that these extensions and sapis
>> are removed as of PHP 7.
>>
> 
> I think you've misread that page. These extensions were not voted on for
> removal, because a maintainer stepped forward.
> 
> The current status in PHP 7 is therefore the same as the status in PHP 5.

I assume Pasindu is referring to the other extensions and sapis subject
to the RFC that will be removed, e.g. ext/mssql.  For these
extensions/sapis the respective documentation has to be adjusted.

-- 
Christoph M. Becker


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

Re: [PHP-DEV] Re: PDO Oracle driver

[Pasindu De Silva]

That's right.

On Wed, Apr 22, 2015 at 9:42 PM, Christoph Becker  wrote:

> Rowan Collins wrote:
>
> > Pasindu De Silva wrote on 22/04/2015 14:44:
> >> On Wed, Apr 22, 2015 at 4:43 PM, Christoph Becker 
> >> wrote:
> >>> [1]
> >>> <
> >>>
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8
> >>>
> >>
> >> As of this RFC we probably can document that these extensions and sapis
> >> are removed as of PHP 7.
> >>
> >
> > I think you've misread that page. These extensions were not voted on for
> > removal, because a maintainer stepped forward.
> >
> > The current status in PHP 7 is therefore the same as the status in PHP 5.
>
> I assume Pasindu is referring to the other extensions and sapis subject
> to the RFC that will be removed, e.g. ext/mssql.  For these
> extensions/sapis the respective documentation has to be adjusted.
>
> --
> Christoph M. Becker
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 

*Pasindu De Silva**ppasin...@gmail.com *

Re: [PHP-DEV] PDO Oracle driver

[Pierre Joye]

+1, and need RFC.
On Apr 22, 2015 4:41 PM, "Stelian Mocanita" 
wrote:

> Hello internals,
>
> I would like to ask what on your thoughts on removing the Oracle drive for
> PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
> at least since it's been experimental for a long time now, and it has long
> standing open bugs, such as:
>
> https://bugs.php.net/bug.php?id=37706
> https://bugs.php.net/bug.php?id=46728
> https://bugs.php.net/bug.php?id=60994
>
> I know that the extension is marked as experimental already but based on
> the current status, it's not even that and a significant amount of basic
> functionality is broken.
>
> Regards,
> Stelian
>

Re: [PHP-DEV] Closure::call() to access private data, really ?

[Andrea Faulds]

Hey Julien,

> On 22 Apr 2015, at 13:18, Julien Pauli  wrote:
> 
> Perhaps the best thing to do is to forbid rebinding a Closure to an internal 
> class ?
> 
> I'm sure we could find segfaulting behaviors using such a trick on most of 
> our internals classes, aka mysqli, simplexmlelement, PDO or SPL classes.
> 
> Thoughts ?

Sounds good to me! There’s already a precedent for having internal classes 
special with respect to Closure binding, as you can’t bind a method of an 
internal class to an object not of that class.

Thanks.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] Re: PDO Oracle driver

[christopher jones]

On 4/22/15 6:39 AM, Stelian Mocanita wrote:


The removal of pdo_oci had been suggested as part of the "Removal of dead or not yet 
PHP7 ported SAPIs and extensions" RFC, but there has been
feedback from Christopher Jones, that the extension will be supported by 
Oracle.[1] [1] <
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8





Thanks for the info. Having Oracle supporting the extensions would be great, 
but I still feel like they should be re-released or something when
they are done. While the OCI8 ext works with current versions, pdo_oci has been 
experimental for a long time and never reached maturity.

Maybe Christopher Jones can jump in here and shed some light on the matter.

Regards, Stelian

On Wed, Apr 22, 2015 at 1:13 PM, Christoph Becker  wrote:


Stelian Mocanita wrote:


I would like to ask what on your thoughts on removing the Oracle drive

for

PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php

)

at least since it's been experimental for a long time now, and it has

long

standing open bugs, such as:

https://bugs.php.net/bug.php?id=37706 https://bugs.php.net/bug.php?id=46728 
https://bugs.php.net/bug.php?id=60994

I know that the extension is marked as experimental already but based on the 
current status, it's not even that and a significant amount of
basic functionality is broken.


The removal of pdo_oci had been suggested as part of the "Removal of dead or not yet 
PHP7 ported SAPIs and extensions" RFC, but there has been
feedback from Christopher Jones, that the extension will be supported by 
Oracle.[1]

[1] < 
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8




-- Christoph M. Becker






The current state is that we will be looking at PDO_OCI and OCI8 for
PHP 7 in a short while.  Our good intentions got delayed as we have
been working on drivers for other languages
(https://github.com/oracle/node-oracledb and
https://bitbucket.org/anthony_tuininga/cx_oracle/).

I think the 'experimental' tag is unwarranted.  It has some bugs -
probably fewer than the rest of PHP, but is usable.

Yes, we do recommend using OCI8 over PDO_OCI.  This is partly due to
some inherent design and performance weaknesses of the overall PDO
architecture.

So, lets not mark PDO_OCI as dead just yet.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd

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

Re: [PHP-DEV] PDO Oracle driver

[christopher jones]

On 4/22/15 2:40 AM, Stelian Mocanita wrote:

Hello internals,

I would like to ask what on your thoughts on removing the Oracle drive for
PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
at least since it's been experimental for a long time now, and it has long
standing open bugs, such as:

https://bugs.php.net/bug.php?id=37706
https://bugs.php.net/bug.php?id=46728
https://bugs.php.net/bug.php?id=60994

I know that the extension is marked as experimental already but based on
the current status, it's not even that and a significant amount of basic
functionality is broken.

Regards,
Stelian




For the record, only one of those bugs is open.  The other may already have 
been fixed.  But I get your point.

Chris


--
christopher.jo...@oracle.com  http://twitter.com/ghrd

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

Re: [PHP-DEV] Re: PDO Oracle driver

[christopher jones]

On 4/22/15 9:10 AM, Jonah H. Harris wrote:

On Wed, Apr 22, 2015 at 9:39 AM, Stelian Mocanita mailto:stelian.mocan...@gmail.com>> wrote:

>
> The removal of pdo_oci had been suggested as part of the "Removal of
> dead or not yet PHP7 ported SAPIs and extensions" RFC, but there has
> been feedback from Christopher Jones, that the extension will be
> supported by Oracle.[1]
> [1]
> <

>https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8
> >


Thanks for the info. Having Oracle supporting the extensions would be
great,
but I still feel like they should be re-released or something when they are
done.
While the OCI8 ext works with current versions, pdo_oci has been
experimental
for a long time and never reached maturity.

Maybe Christopher Jones can jump in here and shed some light on the matter.


I'd prefer to keep it in the tree. Let me talk to the people I know at Oracle 
and see. If they won't maintain it, my company will.

--
Jonah H. Harris
Blog: http://www.oracle-internals.com/


Hi Jonah,

Patches are most welcome.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd

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