Hi,
why are we discussing this again?
get the RFC's fixed up (though I would assume by now they are already) and do a
vote and of story
without a vote the status quo from the last release should be maintained for
such a controversial feature, aka if there is no consensus then the strict type
ch
+1. Strict typing will only prevent PHP from being itself, while not
providing the advantages of a real statically types language (as Stas
Malyshev has mentioned in another thread of discussion).
2010/8/11 Arvids Godjuks :
> Completly agree with Zeev, most russian comunity is for the weak type
> h
Completly agree with Zeev, most russian comunity is for the weak type
hinting. Many would like strict, but most of the pro strict type
hinters understand that PHP and strict type hinting not match and vote
for type hints with auto converting.
--
PHP Internals - PHP Runtime Development Mailing Lis
Hi!
I'm sorry but I have no idea what you're talking about there =\ PHP
has a bunch of different types, the current type hinting (typechecking
"int" is a different kind of type from Zend_Controller_Factory and
SimpleXML - the same kind of types are "int" and "object". The former
are engine t
Zeev Suraski wrote:
Strict typing should go away before any 'official' package comes out of
php.net.
+1 from me as well.
And it is nice to hear that I'm not on my own in that ...
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Ele
On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski wrote:
> At 01:47 11/08/2010, Stas Malyshev wrote:
>
>> Hi!
>>
>> For the record: I consider the current implementation as (one of) the
>>> biggest mistakes in the last ten years.
>>>
>>
>> I agree completely. The fact that obvious absence of consens
At 01:47 11/08/2010, Stas Malyshev wrote:
Hi!
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
I agree completely. The fact that obvious absence of consensus is
ignored and we are releasing feature that clearly has no consensus
be
On Aug 10, 2010, at 10:42 PM, Michael Wallner wrote:
> On 08/11/2010 12:03 AM, Kalle Sommer Nielsen wrote:
>> Greetings hackers
>>
>> I spoke with Derick today, and we both agreed on releasing an alpha of
>> PHP 5.4 to show the public what we have been working since 5.3. We are
>> going to relea
On 08/11/2010 12:03 AM, Kalle Sommer Nielsen wrote:
Greetings hackers
I spoke with Derick today, and we both agreed on releasing an alpha of
PHP 5.4 to show the public what we have been working since 5.3. We are
going to release an alpha at september 2nd, which meaning packaging is
going to happ
On 10-08-11 12:03 AM, Josh Davis wrote:
On 11 August 2010 02:50, Stas Malyshev wrote:
Hi!
First of all, I am talking about the typehinting syntax and mechanism
here. As Derick pointed out, current typehints are strict.
Talking about "strict" vs. "non-strict" for class types is meaningless.
On 11 August 2010 02:50, Stas Malyshev wrote:
> Hi!
>
>> First of all, I am talking about the typehinting syntax and mechanism
>> here. As Derick pointed out, current typehints are strict.
>
> Talking about "strict" vs. "non-strict" for class types is meaningless.
By "strict" typehints I meant th
On Tue, Aug 10, 2010 at 5:25 PM, Derick Rethans wrote:
> Yes, and that's why I want 5.4 alpha1 out soonish...
s,want,would like to,
Even if you were the RM, that's not your call. Tired of seeing doing
the same thing again and again.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | h
On Tue, Aug 10, 2010 at 5:20 PM, Sebastian Bergmann wrote:
> Am 10.08.2010 17:14, schrieb Derick Rethans:
>> I think our current way work pretty well. There is 5.2 which is
>> security-fix supported, 5.3 that is supported and trunk/5.4 that's on
>> the way to alpha.
>
> This only works if manage
Sascha,
Does this mean @group authorizes use of "NoPHP" as a name for a
derivative PHP version (gotta ask according to the license) ? ;-)
On Tue, Aug 10, 2010 at 7:04 PM, Sascha Schumann wrote:
>> They aren't hints. It is strict typing and in its current form I would
>> ask you guys not to call
Sounds like a reasonable name change. PHP never really had
"type-hinting" since even array or Object type "hints" would throw out
any value that didn't precisely match the requested type by the
method/function declaration.
On Tue, Aug 10, 2010 at 8:53 PM, Stas Malyshev wrote:
> Hi!
>
>> Might be
Hi!
Might be the time to rename what we currently call "type hinting" then.
Because what we currently have is strict typing as well.
Maybe. The term "hint" was inexact from the start, as hint means
(Collins English Dictionary):
1. a suggestion or implication given in an indirect or subtle m
Hi!
First of all, I am talking about the typehinting syntax and mechanism
here. As Derick pointed out, current typehints are strict.
Talking about "strict" vs. "non-strict" for class types is meaningless.
You can consider them non-strict if you want - they convert if the
conversion is availa
On 11 August 2010 02:13, Arvids Godjuks wrote:
> Remember the main PHP principle? KISS. So keep it, blody hell, simple!
Please try to realize that what you find simple may not appear as
simple to everybody else. To me, typechecking is very simple: if type
equals typehint then ok else error. Very
On 11 August 2010 01:50, Stas Malyshev wrote:
> Hi!
>
>> Derick's point was about consistency. The approach described in his
>> mail is consistent with current syntax and mechanism(s). Current
>
> No it is not. There's no functions that produce errors when fed 1 instead of
> boolean "true" - all i
Yes, I understand the point of his post. But as you know - the perfect
world and the real world rearly meat together.
Just read the prevoius themes - majority was on the typecasting hints
for the primitive types. We even layed the rules quite in detail.
The thing is it will be pain in the ass to us
hi,
Announcing what?
I do not know where and when you talked to Derick but seriously, it
does not matter. At all.
For one, there is no release decision yet. No need to say that there
is no RM either. Not you, and certainly not Derick (no offense meant,
but what is happening right now is the perf
Hi!
Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current
No it is not. There's no functions that produce errors when fed 1
instead of boolean "true" - all internal functions convert.
typehints do not apply any
Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current
typehints do not apply any kind of conversion, so treating scalar
hints the same way is consistent with the current mechanism.
Reusing the typecasting syntax for typ
Having two similar syntaxes that work differently - would make the
situation even worse that it is now - I beleive. And I totally agree
with Rasmus - strict typed language mustnt be called PHP. (Just a poor
user's notice to all of you internals' geeks out there)
2010/8/11 Stas Malyshev :
> Hi!
>
>
> They aren't hints. It is strict typing and in its current form I would
> ask you guys not to call the 5.4 release PHP. Because it won't be.
Fully agreed.
I'd suggest "NoPHP". "AntiPHP" might also work.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
Well, the thing is objects and arrays are complex types, so you can't
pass anything exept array to an array type hint, it just dosen't make
sence. Not everything can be converted to array and vice-versa. Same
with objects - every object is it's own type.
But the primitive types behave differently.
On Aug 10, 2010, at 3:11 PM, Johannes Schlüter wrote:
> On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
>> type hinting
>
> For the record: I consider the current implementation as (one of) the
> biggest mistakes in the last ten years.
>
> johannes
I'm happy to see a more strict
Hi!
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
I agree completely. The fact that obvious absence of consensus is
ignored and we are releasing feature that clearly has no consensus
behind it as a part of an official release -
Hi!
1. right now we *have* strict type checks for classes and arrays in the
form of "classname" or "array"
Because classes and arrays were never intechangeable types and there was
never implicit or explicit conversion between SplRecursiveTreeIterator
and Zend_Pdf_Generator - it doesn't e
Hi!
With Traits, interned strings/hash table optimizations, array deref.,
type hinting, and more we both (me and Derick) belive we are ready for
Please do not call strict typing "type hinting".
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On 8/10/10 3:30 PM, Brian Moon wrote:
>> 2010/8/11 Johannes Schlüter:
>>> On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
type hinting
>>>
>>> For the record: I consider the current implementation as (one of) the
>>> biggest mistakes in the last ten years.
>
> Is there a summar
On Wed, 11 Aug 2010, Johannes Schlüter wrote:
> On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
> > type hinting
>
> For the record: I consider the current implementation as (one of) the
> biggest mistakes in the last ten years.
I will try to sum up my view point once more:
1. ri
2010/8/11 Johannes Schlüter:
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
type hinting
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
Is there a summary of what we ended up with? I got so tired of all the
compl
Total thumbs up on that.
http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html
just tells it all. A total epic fail.
2010/8/11 Johannes Schlüter :
> On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
>> type hinting
>
> For the record: I consider the current implem
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
> type hinting
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.ne
Greetings hackers
I spoke with Derick today, and we both agreed on releasing an alpha of
PHP 5.4 to show the public what we have been working since 5.3. We are
going to release an alpha at september 2nd, which meaning packaging is
going to happen on 1st September (SVN tag, Windows binaries, etc.)
Hello Christian
2010/8/10 Christian Kaps :
> Hi,
>
> is there any reason why no namespace separator constant exists in PHP. I
> have many cases where I concatenate strings to a namespace. This ends up
> with many class constants like const NS_SEPARATOR = '\\'. A default PHP
> constant would be a
Woops, sorry. Here's the file renamed to .txt. Thanks for the tip!
--Kris
On Tue, Aug 10, 2010 at 12:50 PM, Michael Maclean wrote:
> On 10/08/10 20:28, Kris Craig wrote:
>
>> Sorry, I guess it would help if I actually attached the patch. Here
>> it is.
>>
>
> The list strips attachment
Am 10.08.2010 22:07, schrieb Brian Moon:
> On 8/10/10 3:03 PM, Ferenc Kovacs wrote:
>> like DIRECTORY_SEPARATOR I guess
>>
>> Tyrael
>
> but, DIRECTORY_SEPARATOR is system dependent. The namespace separator
> is not. It is is always \.
>
OK. This is clear.
--
PHP Internals - PHP Runtime Develop
On 8/10/10 3:03 PM, Ferenc Kovacs wrote:
like DIRECTORY_SEPARATOR I guess
Tyrael
but, DIRECTORY_SEPARATOR is system dependent. The namespace separator is
not. It is is always \.
--
Brian.
http://brian.moonspot.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
On Tue, Aug 10, 2010 at 9:59 PM, Daniel Egeberg wrote:
> On Tue, Aug 10, 2010 at 21:56, Christian Kaps
> wrote:
> > Hi,
> >
> > is there any reason why no namespace separator constant exists in PHP. I
> > have many cases where I concatenate strings to a namespace. This ends up
> > with many clas
On Tue, Aug 10, 2010 at 21:56, Christian Kaps wrote:
> Hi,
>
> is there any reason why no namespace separator constant exists in PHP. I
> have many cases where I concatenate strings to a namespace. This ends up
> with many class constants like const NS_SEPARATOR = '\\'. A default PHP
> constant w
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a namespace. This ends up
with many class constants like const NS_SEPARATOR = '\\'. A default PHP
constant would be a better way to handle such cases.
Greetings,
Christian
On 10/08/10 20:28, Kris Craig wrote:
Sorry, I guess it would help if I actually attached the patch. Here
it is.
The list strips attachments with filenames ending in something other
than .txt - resend or perhaps put it online somewhere?
--
Cheers,
Michael
--
PHP Internals - PHP Runtime
Sorry, I guess it would help if I actually attached the patch. Here it
is.
--Kris
2010/8/10 Kris Craig
> Of course! Here's a patch of php_date.c (currently based off 5.3.2; I'll
> need to rebase off 5.3.3 of course) showing the seasonal equinox support
> I've added thus far. The formul
Of course! Here's a patch of php_date.c (currently based off 5.3.2; I'll
need to rebase off 5.3.3 of course) showing the seasonal equinox support
I've added thus far. The formulas in there took quite a bit of research to
find, but ultimately I was able to find them in an old book titled,
"Astrono
Ferenc Kovacs wrote:
2010/8/10 Johannes Schlüter
On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some oth
Hi,
On Tue, 2010-08-10 at 18:43 +0200, Bostjan Skufca wrote:
>
> Interesting idea. Didn't think about that. But it isn't
> reliable either:
> If an auto prepend file is set this will be in the list first.
>
> So simple thing, so easy to overlook...
> But I believe
On Tue, Aug 10 2010, Derick Rethans wrote
> On Mon, 9 Aug 2010, Kalle Sommer Nielsen wrote:
>
> > With the recent additions to 5.4, aren't we getting closer to have a
> > public alpha release, or just a development test as we have many
> great
> > additions and changes to the current trunk or at
2010/8/10 Johannes Schlüter
> Hi,
>
> On Tue, 2010-08-10 at 17:24 +0200, Bostjan Skufca wrote:
> > I've been digging a little deeper and have figured out that I probably
> > could retrieve what I want (realpath of first executed file) from
> > included_files hash (first entry, obviously). Unfortu
Hi,
On Tue, 2010-08-10 at 17:24 +0200, Bostjan Skufca wrote:
> I've been digging a little deeper and have figured out that I probably
> could retrieve what I want (realpath of first executed file) from
> included_files hash (first entry, obviously). Unfortunately, doing it
> like this (sampled fro
On Tue, 2010-08-10 at 16:14 +0100, Derick Rethans wrote:
> On Tue, 10 Aug 2010, Johannes Schlüter wrote:
>
> > On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
> > > Is LTS really something we need to provide? Seems to me like this is
> > > something the linux vendors take care of for t
2010/8/10 Derick Rethans
> On Tue, 10 Aug 2010, Johannes Schlüter wrote:
>
> > On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
> > > Is LTS really something we need to provide? Seems to me like this is
> > > something the linux vendors take care of for the most part. Of course
> > > t
Am 10.08.2010 17:25, schrieb Derick Rethans:
> Yes, and that's why I want 5.4 alpha1 out soonish...
Exactly.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime De
On Tue, 10 Aug 2010, Sebastian Bergmann wrote:
> Am 10.08.2010 17:14, schrieb Derick Rethans:
> > I think our current way work pretty well. There is 5.2 which is
> > security-fix supported, 5.3 that is supported and trunk/5.4 that's on
> > the way to alpha.
>
> This only works if manage to ke
On 10.08.2010, at 17:20, Sebastian Bergmann wrote:
> Am 10.08.2010 17:14, schrieb Derick Rethans:
>> I think our current way work pretty well. There is 5.2 which is
>> security-fix supported, 5.3 that is supported and trunk/5.4 that's on
>> the way to alpha.
>
> This only works if manage to k
I've been digging a little deeper and have figured out that I probably could
retrieve what I want (realpath of first executed file) from included_files
hash (first entry, obviously). Unfortunately, doing it like this (sampled
from get_included_files() implementation):
char *hentry;
zend_ha
Am 10.08.2010 17:14, schrieb Derick Rethans:
> I think our current way work pretty well. There is 5.2 which is
> security-fix supported, 5.3 that is supported and trunk/5.4 that's on
> the way to alpha.
This only works if manage to keep the time between "new code is
committed to trunk" and "n
On Tue, 10 Aug 2010, Johannes Schlüter wrote:
> On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
> > Is LTS really something we need to provide? Seems to me like this is
> > something the linux vendors take care of for the most part. Of course
> > this leaves windows, OSX (and maybe som
2010/8/10 Johannes Schlüter
> On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
> > Is LTS really something we need to provide? Seems to me like this is
> > something the linux vendors take care of for the most part. Of course
> > this leaves windows, OSX (and maybe some others).
>
> We
On 10.08.2010, at 10:45, Johannes Schlüter wrote:
> On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote:
>
> Yes. Release early, release often is a good thing. What I'd also like is
> to have a Ubuntu-like support model. Where we have one LTS (long term
> supported) version (now for instance 5.
On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
> Is LTS really something we need to provide? Seems to me like this is
> something the linux vendors take care of for the most part. Of course
> this leaves windows, OSX (and maybe some others).
Well, I don't see it as loo
2010/8/10 Lukas Kahwe Smith :
>
> On 10.08.2010, at 10:45, Johannes Schlüter wrote:
>
>> On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote:
>>
>> Yes. Release early, release often is a good thing. What I'd also like is
>> to have a Ubuntu-like support model. Where we have one LTS (long term
>> s
2010/8/10 Derick Rethans :
> That's exactly what we have now: 5.2, 5.3 and trunk. I think your LTS
> idea is way too optimistic. I really don't care about porting bug fixes
> back to 5.2 because it is *four* years old. PHP 5.3 has been out for a
> year. Right now there are not many API differences,
On Mon, 9 Aug 2010, Kalle Sommer Nielsen wrote:
> With the recent additions to 5.4, aren't we getting closer to have a
> public alpha release, or just a development test as we have many great
> additions and changes to the current trunk or atleast set up some sort
> of roadmap for what we all l
On Mon, 9 Aug 2010, Kris Craig wrote:
> Currently, I'm working on several parallel feature additions to the
> date extension. Specifically with regard to accurate calculation of
> seasonal equinox, an added paremeter character to display the current
> season in the date() function, limited hem
On Tue, 10 Aug 2010, Johannes Schlüter wrote:
> So we'd always have three branches, while two only receive bug fixes,
> plus one branch for the next milestone.
That's exactly what we have now: 5.2, 5.3 and trunk. I think your LTS
idea is way too optimistic. I really don't care about porting bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/10/2010 11:47 AM, Hannes Magnusson wrote:
> On Tue, Aug 10, 2010 at 11:38, Matti Bickel wrote:
>>
>> As an PHP developer: Providing manuals based on version sounds like a
>> good idea. But I'm not sure about the amount of additional work involve
2010/8/10 Johannes Schlüter :
> On Tue, 2010-08-10 at 17:25 +0800, Adam Harvey wrote:
>> – The LTS branch is going to become more and more difficult to
>> backport fixes to as it diverges from the other two branches, and I
>> can see developers not bothering after a certain point, which may be
>> c
On Tue, Aug 10, 2010 at 11:38, Matti Bickel wrote:
>
> As an PHP developer: Providing manuals based on version sounds like a
> good idea. But I'm not sure about the amount of additional work involved
> and the willingness of docs contributors to do this..
Thats a heckofamore work then we have man
On Tue, 2010-08-10 at 17:25 +0800, Adam Harvey wrote:
> – The LTS branch is going to become more and more difficult to
> backport fixes to as it diverges from the other two branches, and I
> can see developers not bothering after a certain point, which may be
> counter productive.
Except for thing
hi,
On Tue, Aug 10, 2010 at 4:19 AM, Adam Harvey wrote:
> On 10 August 2010 07:28, Pierre Joye wrote:
>> On Mon, Aug 9, 2010 at 11:56 PM, Kalle Sommer Nielsen wrote:
>>> With the recent additions to 5.4, aren't we getting closer to have a
>>> public alpha release, or just a development test as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/10/2010 11:25 AM, Adam Harvey wrote:
> We might end up needing
> to rethink how we structure the manual by looking at something like
> the Python approach of having separate manuals for separate versions,
> which would require a not-insignificant
2010/8/10 Johannes Schlüter :
> Yes. Release early, release often is a good thing. What I'd also like is
> to have a Ubuntu-like support model. Where we have one LTS (long term
> supported) version (now for instance 5.3) which will get bug fixes for
> quite some time and an "early access" version (
>
>
> So we'd always have three branches, while two only receive bug fixes,
> plus one branch for the next milestone.
>
> johannes
>
>
+1 for the new release cycle, and +1 for making 5.3 for the next LTS.
Tyrael
Sebastian Bergmann wrote:
So we'd always have three branches, while two only receive bug fixes,
> plus one branch for the next milestone.
+1
And currently 5.2.x is still the preferred base as there is still a lot of third
party stuff that has to make the transition to 5.3.x ... Pushing new
Am 10.08.2010 10:45, schrieb Johannes Schlüter:
> So we'd always have three branches, while two only receive bug fixes,
> plus one branch for the next milestone.
+1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote:
> I could not disagree more. I think one of the key lessons we should
> have learned out of the whole 6.0 saga was that "release early,
> release often" is a good thing
I will no support the release of trunk overly actively as long as the
"type
On Mon, 2010-08-09 at 18:19 -0700, Kris Craig wrote:
> Currently, I'm working on several parallel feature additions to the date
> extension.
Can you please send some patches first? We like to see some work before
handing out accounts.
johannes
--
PHP Internals - PHP Runtime Development Maili
79 matches
Mail list logo
