Re: [PHP-DEV] Randomize hash-function in php

[Sam]

On 17/03/12 23:17, Simon Schick wrote:

Hi, All

I just came around that talk a couple of days ago ..
http://www.youtube.com/watch?v=R2Cq3CLI6H8

I don't know much about hash-maps and internal php-stuff at all, but
they say that the fix provided in 5.3.9 (and 5.4.0) is more a
work-around than a fix ...
Would it be an option to provide a real fix in PHP 6.0? They got the
feedback that this will take some time and is not trivial, but we have
a good time before PHP6 and can also break backwards compatibility for
php-plugins if really necessary.

As they said in the movie, PHP seems to have the algorithm DJBX33A
implemented as Ruby. So as they're so proud of the fix provided by the
Ruby-Team, may we can use that for PHP as well :)
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815

This is not much because some attacker can do something, but what if
you have a real-world-application that (for some reason) build up an
array that just will blow up because of that? I haven't experienced
that until now, but it's possible ...

Bye
Simon



Hi,

Fairly new to this list so go easy :P..

Anyway I was looking at the hash function in PHP the other week, and was 
playing around with some different implementations.  DJBX33A is fast, 
which I guess is why PHP uses it as it is hit so many times in the 
execution.


However I tried and benchmarked a few different algorithms, I didn't try 
the patch you mentioned, however the only algorithm that came anywhere 
close to matching the DJBX33A method is Paul Hseih's Super Fast Hash 
algorithm: http://www.azillionmonkeys.com/qed/hash.html


I benchmarked the DJBX33A against Hseih's algorithm and compared the 
results using an Intel x86 architecture and an AMD 64 machine and both 
algorithms performed similarly.  The benchmarks weren't robust as they 
were only quick, 'let's hack and see' tests.  Would be interesting if 
anyone else has had a go.


If I can find it I'll post a patch so you could?

Cheers

Sam

Re: [PHP-DEV] Function type hinting

[sam]

Are you interested in working together on some patches? I am trying to
write a patch for function return value type hinting as well as class
property type hinting. Maybe even regular variable type hinting if
possible.

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> I'm monitoring this subject closely because for me and my inner Zen,
> having type hint next to namespaces is one of *the* things I'm looking
> forward.
>
> Now the current subject was only about return values, for me I'm looking
> for the big picture, having scalar type hints every where possible.
>
> I was using Sam's patch for some tests and was very satisfied with.
>
> Besides type hinting for all types, my only left wish is a more
> integrated usage of Exception (UnknownMethod, InvalidArgument, etc.)
>
> - - Markus
>
> Marcus Boerger wrote:
>> Hello Sam,
>>
>>   we actually thought of doing it, yes. And apparently I wanted to do
>> something but I didn't find any time in the past year to be honest.
>>
>> marcus
>>
>> Thursday, December 27, 2007, 7:17:16 PM, you wrote:
>>
>>> I read that type hinting for function return values was going to be
>>> implemented, is this true? If not, is it something that could be
>>> implemented if I were to write a patch?
>>
>>
>>
>>
>> Best regards,
>>  Marcus
>>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHeW4x1nS0RcInK9ARAqo+AJkBABGAww7cPP2mwdAMYBf2rIyrXgCfRhR2
> pr1v9Nm3QcAGRBHdXUFT1wc=
> =xjjT
> -END PGP SIGNATURE-
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[PHP-DEV] [PATCH] Optional scalar type hinting

[Sam Barrow]

I found a patch by Derick online to allow for scalar type hinting, and
made it work with the newest snapshot of PHP 5.3. I also added the
ability to type hint for resources. I would like to ask that it be added
to the next PHP release. It allows type hinting for int, float, bool,
string, resource, and object, I also added the ability to use the
secondary keywords for all of these types (such as double, real, long,
etc.).

It will maintain 100% backwards compatibility, as the type hinting is
100% optional, implemented in the same way as array/class type hinting.

I have the patch on my PC, please let me know where and when i can
submit it. I'd be happy to do the patching and submission myself, just
asking for permission here.

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

[PHP-DEV] Question about superglobals

[Sam Barrow]

I am trying to develop a patch for personal use to enable custom
superglobals.

I seemed to have had it working, but am I allowed to specify
superglobals in my script, or do they have to be specified in an ini
file or statically in the PHP code? 

I created a superglobal keyword and a function that calls
zend_register_auto_global upon the use of this keyword, but it doesn't
work. It calls zend_register_auto_global correctly and passes the
variable name and length of the variable name, but when i try to access
the variable inside a function in my PHP script, it is undefined.
However I am able to hard code my superglobal into the PHP source files
and it works.

Is there some type of restriction on setting superglobals at runtime, or
does the structure of the PHP interpreter not allow this, or am I doing
something wrong?

Thanks in advanced for your help.

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

Thanks everyone, I knew this, but I didn't want to use runkit because it
is a beta, and i don't want all that other stuff, just superglobals.
Also, runkit only allows you to use php.ini, but my patch allows you to
specify superglobals in your script with the keyword "superglobal" by
saying:

superglobal $var1, $var2 ;

Thanks for your help though, if anyone else is interested in the patch
send me a message. 

This isn't something the developers would want to implement I assume,
but it would be useful if they would, at a very small cost too (the
patch probably under 50 lines, very simple code too). If anyone would
like the patch to be implemented in CVS, let me know.

On Fri, 2007-11-16 at 22:58 +0100, Johannes Schlüter wrote:
> Hi Sam,
> 
> you could use pecl/runkit for registering your own super globals. See
> example 2071 on http://de3.php.net/manual/en/ref.runkit.php
> 
> johannes
> 
> On Fri, 2007-11-16 at 15:53 -0500, Sam Barrow wrote:
> > I am trying to develop a patch for personal use to enable custom
> > superglobals.
> > 
> > I seemed to have had it working, but am I allowed to specify
> > superglobals in my script, or do they have to be specified in an ini
> > file or statically in the PHP code? 
> > 
> > I created a superglobal keyword and a function that calls
> > zend_register_auto_global upon the use of this keyword, but it doesn't
> > work. It calls zend_register_auto_global correctly and passes the
> > variable name and length of the variable name, but when i try to access
> > the variable inside a function in my PHP script, it is undefined.
> > However I am able to hard code my superglobal into the PHP source files
> > and it works.
> > 
> > Is there some type of restriction on setting superglobals at runtime, or
> > does the structure of the PHP interpreter not allow this, or am I doing
> > something wrong?
> > 
> > Thanks in advanced for your help.
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

Yes, and in even larger scale applications it can become even more
useful. I have a web framework I'm working on, it's about 9,500 lines of
code now with hundreds of functions/classes. Every function/method has
to specify global for my 3 universal variables which contain large
arrays of configuration information. With this, I can say "superglobal
$mod, $sec, $cfg" in my root include file, and not worry about it again.

On Fri, 2007-11-16 at 17:23 -0700, Michael McGlothlin wrote:
> I think the superglobal keyword is a great idea. I have a custom class 
> that implements a custom interface to memcache with a MySQL backend for 
> data that drops out of memcache or is to big to be stored easily in 
> memcache. I get annoyed at needing to include a global statement in 
> every place I want to use memcache.
> > Thanks everyone, I knew this, but I didn't want to use runkit because it
> > is a beta, and i don't want all that other stuff, just superglobals.
> > Also, runkit only allows you to use php.ini, but my patch allows you to
> > specify superglobals in your script with the keyword "superglobal" by
> > saying:
> >
> > superglobal $var1, $var2 ;
> >
> > Thanks for your help though, if anyone else is interested in the patch
> > send me a message. 
> >
> > This isn't something the developers would want to implement I assume,
> > but it would be useful if they would, at a very small cost too (the
> > patch probably under 50 lines, very simple code too). If anyone would
> > like the patch to be implemented in CVS, let me know.
> >
> > On Fri, 2007-11-16 at 22:58 +0100, Johannes Schlüter wrote:
> >   
> >> Hi Sam,
> >>
> >> you could use pecl/runkit for registering your own super globals. See
> >> example 2071 on http://de3.php.net/manual/en/ref.runkit.php
> >>
> >> johannes
> >>
> >> On Fri, 2007-11-16 at 15:53 -0500, Sam Barrow wrote:
> >> 
> >>> I am trying to develop a patch for personal use to enable custom
> >>> superglobals.
> >>>
> >>> I seemed to have had it working, but am I allowed to specify
> >>> superglobals in my script, or do they have to be specified in an ini
> >>> file or statically in the PHP code? 
> >>>
> >>> I created a superglobal keyword and a function that calls
> >>> zend_register_auto_global upon the use of this keyword, but it doesn't
> >>> work. It calls zend_register_auto_global correctly and passes the
> >>> variable name and length of the variable name, but when i try to access
> >>> the variable inside a function in my PHP script, it is undefined.
> >>> However I am able to hard code my superglobal into the PHP source files
> >>> and it works.
> >>>
> >>> Is there some type of restriction on setting superglobals at runtime, or
> >>> does the structure of the PHP interpreter not allow this, or am I doing
> >>> something wrong?
> >>>
> >>> Thanks in advanced for your help.
> >>>   
> >
> >   
> 
> 
> -- 
> Michael McGlothlin
> Southwest Plumbing Supply
> 
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

Well this is very common with PHP, it's very flexible and it's easy for
a bad programmer to create chaotic code and get away with it, but this
can happen with many features of PHP. For serious developers however,
this could prove to be very useful when used appropriately. People will
do what they will and make sloppy programs, but that's completely up to
them. No point in holding stuff back from people who could benefit from
it just to protect inexperienced them from their own sloppiness. You
know what I mean?

On Fri, 2007-11-16 at 16:28 -0800, Stanislav Malyshev wrote:
> > I think the superglobal keyword is a great idea. I have a custom class 
> > that implements a custom interface to memcache with a MySQL backend for 
> > data that drops out of memcache or is to big to be stored easily in 
> > memcache. I get annoyed at needing to include a global statement in 
> > every place I want to use memcache.
> 
> I don't think it's a good idea. Superglobals are special for a reason - 
> if everybody would just add stuff into global space and make it 
> superglobal because they can't type a couple of keystrokes, it would be 
> a mess. Just declare a class and use statics or singletons.

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

If anyone wants the patch, you can get it from my blog at
http://www.sambarrow.com/. Keep in mind however I only tried it with PHP
5.3, I don't know if it will work on 5.2, as I am trying to transition
to 5.3 completely because it has namespaces.

On Fri, 2007-11-16 at 17:23 -0700, Michael McGlothlin wrote:
> I think the superglobal keyword is a great idea. I have a custom class 
> that implements a custom interface to memcache with a MySQL backend for 
> data that drops out of memcache or is to big to be stored easily in 
> memcache. I get annoyed at needing to include a global statement in 
> every place I want to use memcache.
> > Thanks everyone, I knew this, but I didn't want to use runkit because it
> > is a beta, and i don't want all that other stuff, just superglobals.
> > Also, runkit only allows you to use php.ini, but my patch allows you to
> > specify superglobals in your script with the keyword "superglobal" by
> > saying:
> >
> > superglobal $var1, $var2 ;
> >
> > Thanks for your help though, if anyone else is interested in the patch
> > send me a message. 
> >
> > This isn't something the developers would want to implement I assume,
> > but it would be useful if they would, at a very small cost too (the
> > patch probably under 50 lines, very simple code too). If anyone would
> > like the patch to be implemented in CVS, let me know.
> >
> > On Fri, 2007-11-16 at 22:58 +0100, Johannes Schlüter wrote:
> >   
> >> Hi Sam,
> >>
> >> you could use pecl/runkit for registering your own super globals. See
> >> example 2071 on http://de3.php.net/manual/en/ref.runkit.php
> >>
> >> johannes
> >>
> >> On Fri, 2007-11-16 at 15:53 -0500, Sam Barrow wrote:
> >> 
> >>> I am trying to develop a patch for personal use to enable custom
> >>> superglobals.
> >>>
> >>> I seemed to have had it working, but am I allowed to specify
> >>> superglobals in my script, or do they have to be specified in an ini
> >>> file or statically in the PHP code? 
> >>>
> >>> I created a superglobal keyword and a function that calls
> >>> zend_register_auto_global upon the use of this keyword, but it doesn't
> >>> work. It calls zend_register_auto_global correctly and passes the
> >>> variable name and length of the variable name, but when i try to access
> >>> the variable inside a function in my PHP script, it is undefined.
> >>> However I am able to hard code my superglobal into the PHP source files
> >>> and it works.
> >>>
> >>> Is there some type of restriction on setting superglobals at runtime, or
> >>> does the structure of the PHP interpreter not allow this, or am I doing
> >>> something wrong?
> >>>
> >>> Thanks in advanced for your help.
> >>>   
> >
> >   
> 
> 
> -- 
> Michael McGlothlin
> Southwest Plumbing Supply
> 
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

I agree, I wouldn't want to create a class just for one variable to be
in it. It works, yes, but it's just not the clean way to do things. Why
not allow maximum flexibility?

On Fri, 2007-11-16 at 20:26 -0700, Michael McGlothlin wrote:
> So the idea now is to inappropriately force everything to be a class?
> >> Yes, and in even larger scale applications it can become even more
> >> useful. I have a web framework I'm working on, it's about 9,500 lines of
> >> code now with hundreds of functions/classes. Every function/method has
> >> to specify global for my 3 universal variables which contain large
> >> arrays of configuration information. With this, I can say "superglobal
> >> $mod, $sec, $cfg" in my root include file, and not worry about it again.
> >
> > class Config {
> > const FOO = "Bar";
> > }
> >
> > function oink() {
> > if (Config::FOO == 'Bar') {
> > echo "OINK";
> > }
> > }
> >
> > etc.
> > IMO, you really don't need more superglobals.
> >
> > S
> 
> 
> -- 
> Michael McGlothlin
> Southwest Plumbing Supply
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

However, if you're a programmer with a 10,000 line application, are you
going to just forget that you've used your $cfg variable a hundred
times, and accidentally make a new one? And the error is detectable.

Maybe all superglobals could be required to start with an underscore,
like _GET and _POST, to decrease confusion. I personally don't think
this would be necessary, but it is a compromise.

But what you're saying applies to the php superglobals too, what if
someone makes a variable called _GET? It will have the same problem. And
you can say, yeah but _GET is an obscure name, to that I would say we
can require superglobals to start with underscores or something.

But regardless, if someone specifies a superglobal it's on them to
remember, it's not our job to protect a sloppy programmer who does
stupid things in his coding. This feature would maybe be a disadvantage
to a couple people who abuse the flexibility we give them, but it would
benefit many more people.

Flexibility does not hurt anyone except the people who abuse it. If
they're going to make mistakes like this, they're going to make mistakes
regardless. We don't have to hold back new features and flexibiltiy in
order to prevent a couple of people from messing up. If everyone went by
this logic then PHP would not even have functions, because people might
use them wrongly.

On Fri, 2007-11-16 at 18:00 -0800, Stanislav Malyshev wrote:
> > Well this is very common with PHP, it's very flexible and it's easy for
> > a bad programmer to create chaotic code and get away with it, but this
> > can happen with many features of PHP. For serious developers however,
> 
> Right. This is why I don't think it's a good idea to add one more 
> feature with very high potential for abuse. Code that changes behaviour 
> of unrelated other code is usually very bad idea - think about what 
> happens if some of your functions somewhere among 10K lines of code used 
> $cfg as local variable and then you added $cfg as superglobal.
> 
> > them. No point in holding stuff back from people who could benefit from
> > it just to protect inexperienced them from their own sloppiness. You
> > know what I mean?
> 
> Yes, there is a point in not implementing features that would promote 
> bad coding and unnecessary surprises for the users. Especially when the 
> same function can be achieved with existing functionality in a much 
> better way.
> -- 
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED]   http://www.zend.com/
> (408)253-8829   MSN: [EMAIL PROTECTED]
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

That's a good point too, usually when globals are used at all they are
used in numerous functions It's very rare to see a variable that's used
as a global in one or two functions.

> This assumes there is never a good reason for a super global which makes 
> me wonder why PHP has super globals at all then? What if, because I use 
> it so often and want to differentiate it, it just works better for me to 
> make it a super global? I could always name it with the standard $_ 
> naming scheme so as to not run into accidental use. I don't often use 
> globals but when I do it's usually because it's something I'll use a 
> lot. It doesn't benefit code readability to have the same thing repeated 
> hundreds of times. It's not a big issue but I do like the idea of making 
> super globals easy to do.

On Fri, 2007-11-16 at 20:44 -0700, Michael McGlothlin wrote:
> Stanislav Malyshev wrote:
> >> Well this is very common with PHP, it's very flexible and it's easy for
> >> a bad programmer to create chaotic code and get away with it, but this
> >> can happen with many features of PHP. For serious developers however,
> >
> > Right. This is why I don't think it's a good idea to add one more 
> > feature with very high potential for abuse. Code that changes 
> > behaviour of unrelated other code is usually very bad idea - think 
> > about what happens if some of your functions somewhere among 10K lines 
> > of code used $cfg as local variable and then you added $cfg as 
> > superglobal.
> >
> >> them. No point in holding stuff back from people who could benefit from
> >> it just to protect inexperienced them from their own sloppiness. You
> >> know what I mean?
> >
> > Yes, there is a point in not implementing features that would promote 
> > bad coding and unnecessary surprises for the users. Especially when 
> > the same function can be achieved with existing functionality in a 
> > much better way.
> This assumes there is never a good reason for a super global which makes 
> me wonder why PHP has super globals at all then? What if, because I use 
> it so often and want to differentiate it, it just works better for me to 
> make it a super global? I could always name it with the standard $_ 
> naming scheme so as to not run into accidental use. I don't often use 
> globals but when I do it's usually because it's something I'll use a 
> lot. It doesn't benefit code readability to have the same thing repeated 
> hundreds of times. It's not a big issue but I do like the idea of making 
> super globals easy to do.
> 
> All this forcefulness of writing pristine code from the people that 
> teach people that it's okay to inline their HTML, Javascript, CSS, SQL, 
> and who knows what else into their PHP? Talk about a recipe for 
> disaster. Oh well, at least you didn't refuse to add a switch statement 
> like Python.

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

But why not have maximum flexibility? A language should provide as many
tools to the user as possible, a tool doesn't hurt. If you don't want to
do it, don't, who cares? But an extra tool never hurts in any situation,
real life or a programming language. Any language and any features of a
language can be abused horribly by someone who doesn't know what they're
doing.

On Fri, 2007-11-16 at 20:44 -0700, Michael McGlothlin wrote:
> Stanislav Malyshev wrote:
> >> Well this is very common with PHP, it's very flexible and it's easy for
> >> a bad programmer to create chaotic code and get away with it, but this
> >> can happen with many features of PHP. For serious developers however,
> >
> > Right. This is why I don't think it's a good idea to add one more 
> > feature with very high potential for abuse. Code that changes 
> > behaviour of unrelated other code is usually very bad idea - think 
> > about what happens if some of your functions somewhere among 10K lines 
> > of code used $cfg as local variable and then you added $cfg as 
> > superglobal.
> >
> >> them. No point in holding stuff back from people who could benefit from
> >> it just to protect inexperienced them from their own sloppiness. You
> >> know what I mean?
> >
> > Yes, there is a point in not implementing features that would promote 
> > bad coding and unnecessary surprises for the users. Especially when 
> > the same function can be achieved with existing functionality in a 
> > much better way.
> This assumes there is never a good reason for a super global which makes 
> me wonder why PHP has super globals at all then? What if, because I use 
> it so often and want to differentiate it, it just works better for me to 
> make it a super global? I could always name it with the standard $_ 
> naming scheme so as to not run into accidental use. I don't often use 
> globals but when I do it's usually because it's something I'll use a 
> lot. It doesn't benefit code readability to have the same thing repeated 
> hundreds of times. It's not a big issue but I do like the idea of making 
> super globals easy to do.
> 
> All this forcefulness of writing pristine code from the people that 
> teach people that it's okay to inline their HTML, Javascript, CSS, SQL, 
> and who knows what else into their PHP? Talk about a recipe for 
> disaster. Oh well, at least you didn't refuse to add a switch statement 
> like Python.

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

You say that superglobals were not designed to be user defined, think
about it, the concept of a superglobal is present in C and C++, two of
the maturest and strictest languages around.

On Fri, 2007-11-16 at 22:34 -0500, Sean Coates wrote:
> > So the idea now is to inappropriately force everything to be a class?
> >>
> 
> It is appropriate. That's how it was designed. Obviously superglobals  
> were not designed to be user-definable.
> 
> If configuration is defined in a class, then as a maintainer, you can  
> easily determine where the data was defined (unless you do things are  
> even less appropriate), but simply looking up the class.
> 
> Globals (and superglobals) can be defined _anywhere_. This makes them  
> a maintenance nightmare, and a very inappropriate place to store data  
> such as configuration information.
> 
> S
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

I disagree, although you do have a very good point. But simple logic
flaws can cause huge bugs regardless, whether it would be because of a
superglobal or any other programmer error. Although you have a point,
the only place where we disagree is that I think the benefits outweigh
the risks.

On Fri, 2007-11-16 at 20:34 -0800, Rasmus Lerdorf wrote:
> Sam Barrow wrote:
> > You say that superglobals were not designed to be user defined, think
> > about it, the concept of a superglobal is present in C and C++, two of
> > the maturest and strictest languages around.
> 
> The concept of having to declare your globals is unique to PHP, true.
> It is one of the oldest features in PHP too.  So, a little history...
> 
> Back in 1989 I spent at least a month chasing a bug at a company in
> Canada called Bell Northern Research.  It was a weird crash bug in a
> rather complicated system.  It was mostly written in C and after pouring
> through reams and reams of code printouts day after day, I finally found
> that it was due to a side effect of some obscure function overwriting a
> global variable that was used in a completely different area of the
> code.  That particular feature of the C language was not popular with me
> for a long time after that, and when it came time to work out function
> scoping of variables in PHP, I made sure to not make that same mistake.
> 
> And yes, because PHP is a web language and there are common aspects of a
> web request that many functions will need to act on, it makes sense to
> have a finite number of clearly labeled global arrays like _GET, _POST,
> etc.  And later on, being able to access any global via $_GLOBALS was
> added, but again, it is a very descriptive name and not likely to result
> in someone mistaking it for something else and ending up with strange
> side effects.
> 
> I am definitely not in favor of destroying what I consider a rather good
> design decision just to avoid a couple of keystrokes here and there.  So
> yes, you will have to keep adding "global $cfg;" to your functions, or
> accessing it via $_GLOBALS['cfg'], and when you forget, it won't work.
> And yes, you will grumble a bit at that, but that is nothing compared to
> trying to find a bug caused by a global side effect in someone else's
> code.  Trust me, you will grumble a lot more at that.
> 
> -Rasmus
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

As i said you guys do have a point. But when you say leave custom
superglobals to runkit, you might as well leave them to my patch.

You have to specifically declare superglobals, just like in runkit. No
difference between this and using runkit except ease of use.

On Fri, 2007-11-16 at 23:54 -0600, Larry Garfield wrote:
> As a predecessor of mine at work devised not one but two systems that used 
> global variables as their primary means of internal communication, and I got 
> to sit next to the guy who had to debug and maintain both of them for a year 
> before finally going insane and quitting, I have to agree with Rasmus.  
> Typing "global" isn't just an extra six characters.  It's being polite to the 
> people who will have to maintain your code after you're gone.  Undeclared 
> globals are a form of extreme sadism, no matter how much documentation you 
> think you've provided.  Declared globals are merely ordinary, run-of-the-mill 
> sadism. :-)  I don't see a benefit in the first place.
> 
> Singletons, collector functions, or as a last resort the global keyword are 
> all viable alternatives.  Leave extra superglobals to runkit where such weird 
> edge cases belong.
> 
> On Friday 16 November 2007, Sam Barrow wrote:
> > I disagree, although you do have a very good point. But simple logic
> > flaws can cause huge bugs regardless, whether it would be because of a
> > superglobal or any other programmer error. Although you have a point,
> > the only place where we disagree is that I think the benefits outweigh
> > the risks.
> >
> > On Fri, 2007-11-16 at 20:34 -0800, Rasmus Lerdorf wrote:
> > > Sam Barrow wrote:
> > > > You say that superglobals were not designed to be user defined, think
> > > > about it, the concept of a superglobal is present in C and C++, two of
> > > > the maturest and strictest languages around.
> > >
> > > The concept of having to declare your globals is unique to PHP, true.
> > > It is one of the oldest features in PHP too.  So, a little history...
> > >
> > > Back in 1989 I spent at least a month chasing a bug at a company in
> > > Canada called Bell Northern Research.  It was a weird crash bug in a
> > > rather complicated system.  It was mostly written in C and after pouring
> > > through reams and reams of code printouts day after day, I finally found
> > > that it was due to a side effect of some obscure function overwriting a
> > > global variable that was used in a completely different area of the
> > > code.  That particular feature of the C language was not popular with me
> > > for a long time after that, and when it came time to work out function
> > > scoping of variables in PHP, I made sure to not make that same mistake.
> > >
> > > And yes, because PHP is a web language and there are common aspects of a
> > > web request that many functions will need to act on, it makes sense to
> > > have a finite number of clearly labeled global arrays like _GET, _POST,
> > > etc.  And later on, being able to access any global via $_GLOBALS was
> > > added, but again, it is a very descriptive name and not likely to result
> > > in someone mistaking it for something else and ending up with strange
> > > side effects.
> > >
> > > I am definitely not in favor of destroying what I consider a rather good
> > > design decision just to avoid a couple of keystrokes here and there.  So
> > > yes, you will have to keep adding "global $cfg;" to your functions, or
> > > accessing it via $_GLOBALS['cfg'], and when you forget, it won't work.
> > > And yes, you will grumble a bit at that, but that is nothing compared to
> > > trying to find a bug caused by a global side effect in someone else's
> > > code.  Trust me, you will grumble a lot more at that.
> > >
> > > -Rasmus
> 
> 
> -- 
> Larry GarfieldAIM: LOLG42
> [EMAIL PROTECTED] ICQ: 6817012
> 
> "If nature has made any one thing less susceptible than all others of 
> exclusive property, it is the action of the thinking power called an idea, 
> which an individual may exclusively possess as long as he keeps it to 
> himself; but the moment it is divulged, it forces itself into the possession 
> of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
> Jefferson
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

Just to make sure you understand me correctly, these are not at all
undeclared globals (as you said). You have to specifically turn on the
variables you want to be superglobals.

On Sat, 2007-11-17 at 01:01 -0500, Sam Barrow wrote:
> As i said you guys do have a point. But when you say leave custom
> superglobals to runkit, you might as well leave them to my patch.
> 
> You have to specifically declare superglobals, just like in runkit. No
> difference between this and using runkit except ease of use.
> 
> On Fri, 2007-11-16 at 23:54 -0600, Larry Garfield wrote:
> > As a predecessor of mine at work devised not one but two systems that used 
> > global variables as their primary means of internal communication, and I 
> > got 
> > to sit next to the guy who had to debug and maintain both of them for a 
> > year 
> > before finally going insane and quitting, I have to agree with Rasmus.  
> > Typing "global" isn't just an extra six characters.  It's being polite to 
> > the 
> > people who will have to maintain your code after you're gone.  Undeclared 
> > globals are a form of extreme sadism, no matter how much documentation you 
> > think you've provided.  Declared globals are merely ordinary, 
> > run-of-the-mill 
> > sadism. :-)  I don't see a benefit in the first place.
> > 
> > Singletons, collector functions, or as a last resort the global keyword are 
> > all viable alternatives.  Leave extra superglobals to runkit where such 
> > weird 
> > edge cases belong.
> > 
> > On Friday 16 November 2007, Sam Barrow wrote:
> > > I disagree, although you do have a very good point. But simple logic
> > > flaws can cause huge bugs regardless, whether it would be because of a
> > > superglobal or any other programmer error. Although you have a point,
> > > the only place where we disagree is that I think the benefits outweigh
> > > the risks.
> > >
> > > On Fri, 2007-11-16 at 20:34 -0800, Rasmus Lerdorf wrote:
> > > > Sam Barrow wrote:
> > > > > You say that superglobals were not designed to be user defined, think
> > > > > about it, the concept of a superglobal is present in C and C++, two of
> > > > > the maturest and strictest languages around.
> > > >
> > > > The concept of having to declare your globals is unique to PHP, true.
> > > > It is one of the oldest features in PHP too.  So, a little history...
> > > >
> > > > Back in 1989 I spent at least a month chasing a bug at a company in
> > > > Canada called Bell Northern Research.  It was a weird crash bug in a
> > > > rather complicated system.  It was mostly written in C and after pouring
> > > > through reams and reams of code printouts day after day, I finally found
> > > > that it was due to a side effect of some obscure function overwriting a
> > > > global variable that was used in a completely different area of the
> > > > code.  That particular feature of the C language was not popular with me
> > > > for a long time after that, and when it came time to work out function
> > > > scoping of variables in PHP, I made sure to not make that same mistake.
> > > >
> > > > And yes, because PHP is a web language and there are common aspects of a
> > > > web request that many functions will need to act on, it makes sense to
> > > > have a finite number of clearly labeled global arrays like _GET, _POST,
> > > > etc.  And later on, being able to access any global via $_GLOBALS was
> > > > added, but again, it is a very descriptive name and not likely to result
> > > > in someone mistaking it for something else and ending up with strange
> > > > side effects.
> > > >
> > > > I am definitely not in favor of destroying what I consider a rather good
> > > > design decision just to avoid a couple of keystrokes here and there.  So
> > > > yes, you will have to keep adding "global $cfg;" to your functions, or
> > > > accessing it via $_GLOBALS['cfg'], and when you forget, it won't work.
> > > > And yes, you will grumble a bit at that, but that is nothing compared to
> > > > trying to find a bug caused by a global side effect in someone else's
> > > > code.  Trust me, you will grumble a lot more at that.
> > > >
> > > > -Rasmus
> > 
> > 
> > -- 
> > Larry Garfield  AIM: LOLG42
> > [EMAIL PROTECTED]   ICQ: 6817012
> > 
> > "If nature has made any one thing less susceptible than all others of 
> > exclusive property, it is the action of the thinking power called an idea, 
> > which an individual may exclusively possess as long as he keeps it to 
> > himself; but the moment it is divulged, it forces itself into the 
> > possession 
> > of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
> > Jefferson
> > 
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

Not a bad idea, however in my case (don't know about others) I have very
deep arrays i use for my configuration. This would be more of a pain to
use with these get and set functions. Also, the performance would
probably be worse than just directly accessing the variable.

Good point about not fixing what's not broken, but I think in this
context it couldn't hurt to fix it. I have already fixed it, my patch is
already written and I will continue testing it but I haven't come across
any problems using it.

On Sat, 2007-11-17 at 01:05 -0500, Carl P. Corliss wrote:
> Sam Barrow wrote:
> > Thanks everyone, I knew this, but I didn't want to use runkit because it
> > is a beta, and i don't want all that other stuff, just superglobals.
> > Also, runkit only allows you to use php.ini, but my patch allows you to
> > specify superglobals in your script with the keyword "superglobal" by
> > saying:
> > 
> > superglobal $var1, $var2 ;
> 
> I don't get why you can't just use a Registry pattern here. Having a 
> simpleRegistry object that you can throw data into and pull out of not only 
> allows you to keep your global space clean, but allows you to encapsulate 
> your "global" data and access it via a simple interface. Sure, it might be a 
> few extra keystrokes to type something akin to: Registry::get('var1'); but, 
> personally, I think the trade-off is well worth it.
> 
> simple example class:
> 
> class Registry {
>  protect function __construct() {} // no instantiation - static class
>  static protected $data = array();
> 
>  static public function get($name) {
>  return (isset(self::$data[$name]) ? self::$data[$name] : null);
>  }
> 
>  static public function set($name, value) {
>  self::$data[$name] = $value;
>  }
> }
> 
> 
> summary: why "fix" what ain't really broke...?
> 
> Cheers!,
> 
> --
> Carl
> 

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

[PHP-DEV] Question about constants

[Sam Barrow]

If i were to implement some type of patch, could i define a php constant
to indicate the patch has been applied while staying within the php
naming conventions? If so, what should i prefix with?

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

True. What if we created a php.ini directive that defaulted to off that
would determine the ability to declare superglobals,
"allow_superglobals" or something.

On Fri, 2007-11-16 at 22:18 -0800, Rasmus Lerdorf wrote:
> Sam Barrow wrote:
> > Just to make sure you understand me correctly, these are not at all
> > undeclared globals (as you said). You have to specifically turn on the
> > variables you want to be superglobals.
> 
> They are undeclared in the individual functions where they are used.
> You can declare them all you want in your part of a large project, but
> the fact is that they end up in the superglobal namespace and developer
> #2 working on another part of the code has no idea that you made up your
> own superglobal and what used to be a function-local variable in his
> code suddenly isn't anymore.
> 
> -Rasmus

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

I don't understand, people keep telling me this can cause problems so
it's trash. Really? Functions and variables can cause problems too. Not
to mention user input. Programming is not easy, but the more flexible it
is the better. I think it's up to the programmer to keep track of his
variables, rather than us limiting his functionality, just incase he
makes a mistake.

Any programmer can write bad code and it won't work. If he uses
superglobals he should understand that he needs to document them, it's
that simple. If that's too difficult, don't create a superglobal then,
great.

And if this isn't good enough, fine. Require an underscore for
superglobals to differentiate them even more. I'll write the code
myself, no problem.

On Sat, 2007-11-17 at 01:30 -0500, Robert Cummings wrote:
> On Sat, 2007-11-17 at 01:21 -0500, Sam Barrow wrote:
> > True. What if we created a php.ini directive that defaulted to off that
> > would determine the ability to declare superglobals,
> > "allow_superglobals" or something.
> 
> Does your code live in a bubble? Allowance of of arbitrary super global
> definitions would open a can of local variable clobbering worms.
> 
> A php.ini directive won't make this reality any more palatable.
> 
> Cheers,
> Rob.
> -- 
> ...
> SwarmBuy.com - http://www.swarmbuy.com
> 
> Leveraging the buying power of the masses!
> ...
> 

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

Re: [PHP-DEV] Re: Question about superglobals

[Sam Barrow]

Ok forget it if anyone wants the patch just send me an email. By the way
i didn't mention it also includes a function that retrieves the list of
current superglobals.

On Fri, 2007-11-16 at 22:47 -0800, Rasmus Lerdorf wrote:
> Sam Barrow wrote:
> > I don't understand, people keep telling me this can cause problems so
> > it's trash. Really? Functions and variables can cause problems too. Not
> > to mention user input. Programming is not easy, but the more flexible it
> > is the better. I think it's up to the programmer to keep track of his
> > variables, rather than us limiting his functionality, just incase he
> > makes a mistake.
> > 
> > Any programmer can write bad code and it won't work. If he uses
> > superglobals he should understand that he needs to document them, it's
> > that simple. If that's too difficult, don't create a superglobal then,
> > great.
> > 
> > And if this isn't good enough, fine. Require an underscore for
> > superglobals to differentiate them even more. I'll write the code
> > myself, no problem.
> 
> We simply don't think this flexibility makes up for the potential
> confusion it can cause.  It isn't solving something that can't be done,
> it is just changing a minor syntax and concept which has been in place
> for the past 12 years of PHP.  To be completely blunt, this change has
> no chance of making it into PHP.  If you want it, you will have to
> maintain your own patch.
> 
> -Rasmus
> 

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

Re: [PHP-DEV] [PATCH] Optional scalar type hinting

[Sam Barrow]

I have thought about this, using obects for all variables, but all of
the extra code amounts to alot in a large application, and when using
hundreds of small strings and integers scattered throughtout your
application, this would cause a serious performance drop.

On Sun, 2007-11-18 at 18:13 -0500, David Coallier wrote:
> On Nov 18, 2007 5:52 PM, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
> > 2007/11/18, Derick Rethans <[EMAIL PROTECTED]>:
> >
> > > I am actually thinking that it might be a good thing to add more and
> > > more. I know my quick hack isn't the best implementation though.
> >
> > Yes and it is an alternative and not a mandatory thing to use.. as long as :
> >
> >  >
> > function foo(int $num) {
> >return $num
> >
> > }
> >
> > foo("12345") // emit fatal error, NOT accept it as valid integer
> >
> > all is fine and Im all for it ;)
> > --
> > http://www.kissofjudas.net/
> >
> 
> I was thinking at something along the lines of objects also for instance:
> 
> $i = new Integer(33);
> 
> function foo(Integer $var) {
> }
> 
> foo ($i); else it emits a fatal error. But also if you do
> 
> $i = "Name"; that would emit a fatal error because the value is
> suposed to be an int. This might look a bit too much like java, but as
> an extension it could be something quite interesting I believe.
> 
> String, Object, Integer, Scalar, Float  and what else.
> 
> So thinking of something like
> 
> $string = new String("Foo");
> $string = "bar" or $string->setValue("Bar"); would do
> 
> $float = new Float(4.242);
> $float->setValue('foobar'); // That emits an error
> $float->setValue(3.14159);
> 
> echo $float; (__toString) or echo $float->getValue; to echo it's content/value
> 
> and so on.
> 
> Would that be "too" java-ish to be something considered in php6 ? ;-)
> 
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> 
> 
> 
> -- 
> David Coallier,
> Founder & Software Architect,
> Agora Production (http://agoraproduction.com)
> 51.42.06.70.18
> 

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

Re: [PHP-DEV] [PATCH] Optional scalar type hinting

[Sam Barrow]

I've been working on your patch, adding types and making it more stable.
Worked pretty good for me though, with the exception of a couple things
(some code was different in 5.3 than in your diff files, but that makes
sense as you wrote this patch in 2006).

I think more type hinting in all areas would be good, and if this is
something that is going to be implemented, I am willing to do as much of
the work as I'd have to.

 On Sun, 2007-11-18 at 21:25 +0100, Derick Rethans wrote:
> On Thu, 15 Nov 2007, Marcus Boerger wrote:
> 
> >   we discussed this a million times already I think. And the conclusion is
> > to not allow type hinting for base types.
> 
> I am actually thinking that it might be a good thing to add more and 
> more. I know my quick hack isn't the best implementation though. 
> 
> Derick
> 

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

Re: [PHP-DEV] Type hinting of class properties

[Sam Barrow]

I think type hinting of all variables eventually would be great, as long
as it stays completely optional.

On Mon, 2007-11-19 at 01:18 +0100, Baptiste Autin wrote:
> I know well the sacred "loose typing" anthem, but is there any hope to see
> the class properties type hinted one day? (and the return value as well)
> 
> I mean, as an OPTION, as it is already done with function parameters...
> 
> Class A {
> }
> Class B {
> public A $a;
> }
> 
> Because:
> 1.It is so strange to see that in PHP5 only the function parameters
> have this feature implemented today. It's like a half-done job.
> 2.Many design patterns make use of composition (versus inheritance -
> thanks the GoF) and a composition would be more readable with such a
> feature.
> 3.Model-driven, reverse-enginering tools would appreciate this too.
> 
> Other question: would it be conceivable to gather the ENV / GET / POST (and
> so on) variables into one or more system classes? (sorts of "context
> classes") so that one would always have the choice between looking into the
> traditional arrays $_xxx, or into the system classes (I'm sure this point
> has already been discussed, but I wasn't there :-).
> 

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

Re: [PHP-DEV] [PATCH] Optional scalar type hinting

[Sam Barrow]

I both like and dislike the fact that PHP is so loosely typed. It makes
it very easy, which I like, however it is sometimes not strict enough,
allowing for undetected errors, which of course I don't like.

I think the ideal solution here is to make it a hybrid type of language,
where typing is dynamic, but still controllable using type hinting. You
can use whichever you want where you want. Functions can have 3
parameters, two hinted and one not.

Keep in mind this is not strict typing. Key word: "hinting".

If all is 100% optional, your application can take advantage of the
flexibility of dynamic typing in places where it's needed, and also take
advantage of the control that type hinting gives you where it's
appropriate. Most languages either allow you to do whatever you want,
making some code chaotic and some bugs harder to detect, whereas some
are the complete opposite, imposing very strict limits on your
variables, and severely limiting your flexibility. PHP could be the
middle ground, with maximum flexibility, but also maximum control.

I'm currently using my type hinting patch with PHP 5.3 for an
application I'm working on with about 10,000 lines of code and hundreds
of functions, big and small. I'm using type hinting in most of the
functions, but not all. It's been very helpful so far, especially with
the "scalar" and "number" type hints.

On Sun, 2007-11-18 at 21:50 -0500, David Coallier wrote:
> On Nov 18, 2007 7:24 PM, Hannes Magnusson <[EMAIL PROTECTED]> wrote:
> > On Nov 19, 2007 12:13 AM, David Coallier <[EMAIL PROTECTED]> wrote:
> > > I was thinking at something along the lines of objects also for instance:
> > >
> > > $i = new Integer(33);
> > >
> > > function foo(Integer $var) {
> > > }
> > >
> > > foo ($i); else it emits a fatal error. But also if you do
> > >
> > > $i = "Name"; that would emit a fatal error because the value is
> > > suposed to be an int. This might look a bit too much like java, but as
> > > an extension it could be something quite interesting I believe.
> > >
> > > String, Object, Integer, Scalar, Float  and what else.
> > >
> > > So thinking of something like
> > >
> > > $string = new String("Foo");
> > > $string = "bar" or $string->setValue("Bar"); would do
> > >
> > > $float = new Float(4.242);
> > > $float->setValue('foobar'); // That emits an error
> > > $float->setValue(3.14159);
> > >
> > > echo $float; (__toString) or echo $float->getValue; to echo it's 
> > > content/value
> > >
> > > and so on.
> >
> > That has got to be the worst idea I've heard on internals for over a month.
> > Besides, you can do this in userland already anyway:
> >
> 
> haha :) Yes, you can do many things in userland.
> 
> >  > class InvalidTypeException extends Exception {}
> > class UnknownTypeException extends Exception {}
> >
> > class Types {
> > const INTEGER = 1;
> > const FLOAT   = 2;
> > const STRING  = 3;
> > const OBJECT  = 4;
> > const BOOLEAN = 5;
> >
> > private $val, $type;
> >
> > public function __construct($val, $type) {
> > $this->type = $type;
> > $this->setValue($val);
> > }
> > public function setValue($val) {
> > switch($this->type) {
> > case self::INTEGER:
> > if (!is_int($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > case self::FLOAT:
> > if (!is_float($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > case self::STRING:
> > if (!is_string($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > case self::OBJECT:
> > if (!is_object($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > case self::BOOLEAN:
> > if (!is_bool($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > default:
> > throw new UnknownTypeException;
> >
> > }
> > $this->val = $val;
> > }
> > public function getValue() {
> > return $this->val;
> > }
> > public function __toString() {
> > return (string)$this->getValue();
> > }
> > }
> >
> > class Integer extends Types {
> > public function __construct($val) {
> > parent::__construct($val, Types::INTEGER);
> > }
> > }
> > class String extends Types {
> > public function __c

[PHP-DEV] Multiple class inheritance

[Sam Barrow]

What is the general opinion on multiple class inheritance. I have a need
for it. I have objects for all user input fields.

$username = new field ;
$username -> name = 'username' ;
$username -> maxLen = 32 ;

I have three types of fields. Fields that are automatically put in the
database, such as timestamps, fields that are inputted but not stored,
such as "confirm password", and fields that are inputted by the user AND
stored in the database, such as username and password.

Now i have 3 classes:

- abstractField (has methods and properties that apply to all fields).
- inputField, extends abstractField (has methods and properties for
display of input form elements and labels).
- dbField, extends abstractField (has methods for storing and retrieving
in db, etc.).

However for fields that are inputted AND stored in the db, i need to
extend both inputField and dbField.

- inputDbField extends inputField, dbField.

Sure, there may be quick hacks to do this, but the only proper way seems
to be to extend both classes, and I don't want to duplicate any code
(dbField and inputField are both pretty big, and any modifications will
also have to be replicated).

And no, I don't want to use interfaces. Interfaces will barely do
anything for me, I'll still have to duplicate my method bodies, and
properties.

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

Re: [PHP-DEV] Multiple class inheritance

[Sam Barrow]

I was considering something like this, just seems like more of a hack to
me than the right way to do it, plus the performance hit you mentioned.

On Mon, 2007-11-19 at 00:11 -0600, Larry Garfield wrote:
> (Sorry, hit reply too soon.)
> 
> Or, alternatively, you can mostly implement "friend" functions of a sort:
> 
> http://www.garfieldtech.com/blog/php-magic-call
> 
> but they have a performance penalty:
> 
> http://www.garfieldtech.com/blog/magic-benchmarks
> 
> On Sunday 18 November 2007, Sam Barrow wrote:
> > What is the general opinion on multiple class inheritance. I have a need
> > for it. I have objects for all user input fields.
> >
> > $username = new field ;
> > $username -> name = 'username' ;
> > $username -> maxLen = 32 ;
> >
> > I have three types of fields. Fields that are automatically put in the
> > database, such as timestamps, fields that are inputted but not stored,
> > such as "confirm password", and fields that are inputted by the user AND
> > stored in the database, such as username and password.
> >
> > Now i have 3 classes:
> >
> > - abstractField (has methods and properties that apply to all fields).
> > - inputField, extends abstractField (has methods and properties for
> > display of input form elements and labels).
> > - dbField, extends abstractField (has methods for storing and retrieving
> > in db, etc.).
> >
> > However for fields that are inputted AND stored in the db, i need to
> > extend both inputField and dbField.
> >
> > - inputDbField extends inputField, dbField.
> >
> > Sure, there may be quick hacks to do this, but the only proper way seems
> > to be to extend both classes, and I don't want to duplicate any code
> > (dbField and inputField are both pretty big, and any modifications will
> > also have to be replicated).
> >
> > And no, I don't want to use interfaces. Interfaces will barely do
> > anything for me, I'll still have to duplicate my method bodies, and
> > properties.
> 
> 
> -- 
> Larry GarfieldAIM: LOLG42
> [EMAIL PROTECTED] ICQ: 6817012
> 
> "If nature has made any one thing less susceptible than all others of 
> exclusive property, it is the action of the thinking power called an idea, 
> which an individual may exclusively possess as long as he keeps it to 
> himself; but the moment it is divulged, it forces itself into the possession 
> of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
> Jefferson
> 

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

Re: [PHP-DEV] [PATCH] Optional scalar type hinting

[Sam Barrow]

Good idea about reducing the error warning level, isn't this currently
fatal? We could just turn it into an e_notice or e_warning.

On Mon, 2007-11-19 at 11:37 +, Richard Quadling wrote:
> On 19/11/2007, Sam Barrow <[EMAIL PROTECTED]> wrote:
> > I both like and dislike the fact that PHP is so loosely typed. It makes
> > it very easy, which I like, however it is sometimes not strict enough,
> > allowing for undetected errors, which of course I don't like.
> >
> > I think the ideal solution here is to make it a hybrid type of language,
> > where typing is dynamic, but still controllable using type hinting. You
> > can use whichever you want where you want. Functions can have 3
> > parameters, two hinted and one not.
> >
> > Keep in mind this is not strict typing. Key word: "hinting".
> >
> > If all is 100% optional, your application can take advantage of the
> > flexibility of dynamic typing in places where it's needed, and also take
> > advantage of the control that type hinting gives you where it's
> > appropriate. Most languages either allow you to do whatever you want,
> > making some code chaotic and some bugs harder to detect, whereas some
> > are the complete opposite, imposing very strict limits on your
> > variables, and severely limiting your flexibility. PHP could be the
> > middle ground, with maximum flexibility, but also maximum control.
> >
> > I'm currently using my type hinting patch with PHP 5.3 for an
> > application I'm working on with about 10,000 lines of code and hundreds
> > of functions, big and small. I'm using type hinting in most of the
> > functions, but not all. It's been very helpful so far, especially with
> > the "scalar" and "number" type hints.
> >
> > On Sun, 2007-11-18 at 21:50 -0500, David Coallier wrote:
> > > On Nov 18, 2007 7:24 PM, Hannes Magnusson <[EMAIL PROTECTED]> wrote:
> > > > On Nov 19, 2007 12:13 AM, David Coallier <[EMAIL PROTECTED]> wrote:
> > > > > I was thinking at something along the lines of objects also for 
> > > > > instance:
> > > > >
> > > > > $i = new Integer(33);
> > > > >
> > > > > function foo(Integer $var) {
> > > > > }
> > > > >
> > > > > foo ($i); else it emits a fatal error. But also if you do
> > > > >
> > > > > $i = "Name"; that would emit a fatal error because the value is
> > > > > suposed to be an int. This might look a bit too much like java, but as
> > > > > an extension it could be something quite interesting I believe.
> > > > >
> > > > > String, Object, Integer, Scalar, Float  and what else.
> > > > >
> > > > > So thinking of something like
> > > > >
> > > > > $string = new String("Foo");
> > > > > $string = "bar" or $string->setValue("Bar"); would do
> > > > >
> > > > > $float = new Float(4.242);
> > > > > $float->setValue('foobar'); // That emits an error
> > > > > $float->setValue(3.14159);
> > > > >
> > > > > echo $float; (__toString) or echo $float->getValue; to echo it's 
> > > > > content/value
> > > > >
> > > > > and so on.
> > > >
> > > > That has got to be the worst idea I've heard on internals for over a 
> > > > month.
> > > > Besides, you can do this in userland already anyway:
> > > >
> > >
> > > haha :) Yes, you can do many things in userland.
> > >
> > > >  > > > class InvalidTypeException extends Exception {}
> > > > class UnknownTypeException extends Exception {}
> > > >
> > > > class Types {
> > > > const INTEGER = 1;
> > > > const FLOAT   = 2;
> > > > const STRING  = 3;
> > > > const OBJECT  = 4;
> > > > const BOOLEAN = 5;
> > > >
> > > > private $val, $type;
> > > >
> > > > public function __construct($val, $type) {
> > > > $this->type = $type;
> > > > $this->setValue($val);
> > > > }
> > > > public function setValue($val) {
> > > > switch($this->type) {
> > > > case self::IN

Re: [PHP-DEV] [PATCH] Optional scalar type hinting

[Sam Barrow]

I just finished redoing this patch by the way, it's available on
sambarrow.com, along with my custom superglobals patch.

On Mon, 2007-11-19 at 15:17 +0300, Alexey Zakhlestin wrote:
> On 11/19/07, Richard Quadling <[EMAIL PROTECTED]> wrote:
> 
> > What if type hinting just generated an E_NOTICE. Nothing more for the
> > time being.
> >
> > Call it an experimental option.
> >
> > I already use hungarian notation for all my params ( cause I'm
> > unimaginative with my var names I suppose!), so the type hinting would
> > help me enforce this and reduce errors in the long run (code goes from
> > me to other developers who only glance at the dox)
> 
> I like this idea
> 
> but E_STRICT seems to fit better :)
> 
> -- 
> Alexey Zakhlestin
> http://blog.milkfarmsoft.com/
> 

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

Re: [PHP-DEV] Multiple class inheritance

[Sam Barrow]

Whether it's implemented or not, I'm going to write a patch for multiple
class inheritance. Does anyone here whos knows about the Zend Engine
willing to help me out just a little bit, to get me started? I'm stuck
at the syntax interpretation right now.

On Mon, 2007-11-19 at 02:07 -0500, Edward Z. Yang wrote:
> Larry Garfield wrote:
> > $myfield = new InputField(new DBField(new AbstractField(...))); [snip]
> 
> Nah, what you're talking about now is a chain of responsibility, where
> events are in the form of method calls. :-)
> 
> -- 
>  Edward Z. YangGnuPG: 0x869C48DA
>  HTML Purifier  Anti-XSS Filter
>  [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
> 

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

Re: [PHP-DEV] Multiple class inheritance

[Sam Barrow]

I doubt it will be implemented, but for my application it would be
incredibly helpful and worth it to me to write a patch even if I am the
only one to use it.

On Mon, 2007-11-19 at 17:53 -0300, Cristian Rodriguez wrote:
> 2007/11/19, Sam Barrow <[EMAIL PROTECTED]>:
> > Whether it's implemented or not, I'm going to write a patch for multiple
> > class inheritance.
> 
> I have the feeling that you are trying to use the wrong language.
> 
> Hopefully people on this lists still preserves their sanity and will
> not be wiliing to implement a concept that is know to work correclty
> only in very few implementations, if any, that causes ambiguity and
> opens the door for all sorts of unneeded complexity.
> 
> 
> -- 
> http://www.kissofjudas.net/
> 

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

[PHP-DEV] $_SERVER['REQUEST_TIME']

[Sam Barrow]

This was a good idea, however it could be even more useful if used to
calculate the execution time of your scripts. But since it only counts
whole seconds, for this microtime() would be better. Would it be
possible to add $_SERVER['REQUEST_MICROTIME']?

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

Re: [PHP-DEV] Multiple class inheritance

[Sam Barrow]

That would serve my purpose, as long as i can inherit methods and
properties from multiple parents.

On Mon, 2007-11-19 at 23:09 +0100, Arnold Daniels wrote:
> It would probably better to implement something like prototyping,  
> where there is only 1 parent, but there can be muliple prototype  
> classes from which methods are inherited.
> 
> On Nov 19, 2007, at 10:49 PM, Sam Barrow <[EMAIL PROTECTED]> wrote:
> 
> > I doubt it will be implemented, but for my application it would be
> > incredibly helpful and worth it to me to write a patch even if I am  
> > the
> > only one to use it.
> >
> > On Mon, 2007-11-19 at 17:53 -0300, Cristian Rodriguez wrote:
> >> 2007/11/19, Sam Barrow <[EMAIL PROTECTED]>:
> >>> Whether it's implemented or not, I'm going to write a patch for  
> >>> multiple
> >>> class inheritance.
> >>
> >> I have the feeling that you are trying to use the wrong language.
> >>
> >> Hopefully people on this lists still preserves their sanity and will
> >> not be wiliing to implement a concept that is know to work correclty
> >> only in very few implementations, if any, that causes ambiguity and
> >> opens the door for all sorts of unneeded complexity.
> >>
> >>
> >> -- 
> >> http://www.kissofjudas.net/
> >>
> >
> > -- 
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 

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

Re: [PHP-DEV] multiple namespace per file patch

[Sam Barrow]

I support this patch 100%. I have a large application I'm rewriting to
include namespaces, however now I can no longer use my script caching
functionality (which improved performance literally about 500%) that
compiled all of my includes into one file, because many of the files
have namespaces.

On Tue, 2007-12-04 at 12:12 -0600, Gregory Beaver wrote:
> Hi,
> 
> There's been enough confusion, here's the patch again, this time against
> 5.3, no tests for clarity
> 
> http://pear.php.net/~greg/multi.5.3.patch.txt
> 
> This patch allows:
> 
>  namespace A;
> class a {}
> namespace B;
> class a {}
> namespace A;
> import B::a as b;
> class c extends b;
> ?>
> 
> It doesn't allow:
>  $anycode = 1;
> namespace A;
> ?>
> 
> so all code must have a namespace declaration.  The sole purpose is to
> combine files containing namespace declarations.
> 
> Greg
> plain text document attachment (multi.5.3.patch.txt)
> Index: Zend/zend_compile.c
> ===
> RCS file: /repository/ZendEngine2/zend_compile.c,v
> retrieving revision 1.647.2.27.2.41.2.28
> diff -u -r1.647.2.27.2.41.2.28 zend_compile.c
> --- Zend/zend_compile.c   4 Dec 2007 12:38:42 -   
> 1.647.2.27.2.41.2.28
> +++ Zend/zend_compile.c   4 Dec 2007 17:24:34 -
> @@ -4722,13 +4722,10 @@
>   CG(active_op_array)->opcodes[num-1].opcode == 
> ZEND_TICKS)) {
>   --num;
>   }
> - if (num > 0) {
> + if (!CG(current_namespace) && num > 0) {
>   zend_error(E_COMPILE_ERROR, "Namespace declaration 
> statement has to be the very first statement in the script");
>   }
>   }
> - if (CG(current_namespace)) {
> - zend_error(E_COMPILE_ERROR, "Namespace cannot be declared 
> twice");
> - }
>   lcname = zend_str_tolower_dup(Z_STRVAL(name->u.constant), 
> Z_STRLEN(name->u.constant));
>   if (((Z_STRLEN(name->u.constant) == sizeof("self")-1) &&
> !memcmp(lcname, "self", sizeof("self")-1)) ||
> @@ -4738,6 +4735,16 @@
>   }
>   efree(lcname);
>  
> + if (CG(current_namespace)) {
> + zval_dtor(CG(current_namespace));
> + efree(CG(current_namespace));
> + }
> + if (CG(current_import)) {
> + zend_hash_destroy(CG(current_import));
> + efree(CG(current_import));
> + }
> + CG(current_import) = NULL;
> +
>   ALLOC_ZVAL(CG(current_namespace));
>   *CG(current_namespace) = name->u.constant;
>  }
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

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

[PHP-DEV] Namespaces

[Sam Barrow]

I think support for multiple namespaces in one file should definitely be
used. As far as using curly braces vs using the namespace declaration,
it doesn't really matter to me, however it is important that i be able
to use the same namespace twice:

namespace a {
function function1() {
return true ;
}
}

// some other code

namespace a {
function function2() {
return false ;
}
}

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

Re: [PHP-DEV] RFC: Dropping Namespace

[Sam Barrow]

I think namespaces are very useful when it comes to PHP in large scale
applications with hundreds of functions/classes.

On Tue, 2007-12-04 at 16:39 -0600, Brian Moon wrote:
> > With all the above considerations, especially my first point, I still have 
> > not
> > heard any good reason why namespaces in the current implementation are 
> > actually
> > useful - or what particular case they solve... so I am wondering, are they
> > really useful? I come now to the conclusion that they are not, and for 
> > myself
> > (and most likely my work projects) I would have to decide not to go with
> > namespaces, but instead stick with the 3 letter prefixing.  Something that I
> > have totally no problem with, as it is nice and easy.
> 
> I hate to, but I agree.  If the only point is to make class naming 
> pretty, it is kind of pointless.  Give me namespaces that scope 
> variables to a file and then we have something.  Yeah, I still code the 
> way PHP intended you to code, by templateing files together and not 
> making gynormous classes to print out some simple HTML over and over.
> 
> It would only be useful in that my company's code would not conflict 
> with some 3rd party software we use.
> 
> -- 
> 
> Brian Moon
> Senior Developer
> --
> http://dealnews.com/
> It's good to be cheap =)
> 

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

Re: [PHP-DEV] RFC: Dropping Namespace

[Sam Barrow]

Autoload would work exactly the same with namespaces, just do a
str_replace and replace "::" with "_".

On Wed, 2007-12-05 at 09:52 +0100, Robert Lemke wrote:
> Hi Derick,
> 
> I also agree with your arguments - beautifying class names is not  
> reason enough for
> introducing namespaces.
> 
> On 04.12.2007 at 23:16 Derick Rethans wrote:
> 
> > 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
> >   Zend_*, ezc*, and ezp* are perfectly acceptable markers for  
> > different
> >   'namespaces'.  We could optionally create a registry on php.net for
> >   this to avoid conflicts.
> 
> 
> While experimenting with namespaces to use with the next major version  
> of
> TYPO3, I realized that always using a full class name such as
> 
> "T3_MyPackage_MySubPackage_Controller_DefaultController"
> 
> has many advantages. Autoloading becomes a lot easier and if the  
> filename
> equals the class name (ie. the full name, not only  
> "DefaultController.php")
> you are never in doubt where a file belongs to or comes from.
> 
> Therefore we in the TYPO3 project currently tend to not using namespaces
> even if PHP6 had support for them.
> 
> robert

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

Re: AW: [PHP-DEV] Re: RFC: Dropping Namespace

[Sam Barrow]

This would be a good idea, if implemented with a compatibility layer to
be removed later.

::php
::str
::arr
::ob
etc
::ext
::mysql
::mysqli

Userland code can then use a namespace such as ::app, or just use the
global namespace with no worries. Probably not going to happen, atleast
not for a while, due to compatibility issues, but just a thought.

On Wed, 2007-12-05 at 17:43 +0100, Sebastian Bergmann wrote:
> Matthias Pigulla schrieb:
> > Given that it was technically feasible, (future) core classes should 
> > be in namespaces as well.
> 
>  Or
> 
>   - Introduce namespaces in PHP 6
>   - Move all functions and classes that are now global into
> (per-extension) namespace(s)
>   - Add a fallback mechanism that looks up mysqli_query() as query()
> in the MySQLi extension's namespace for PHP 6.0, drop that BC
> layer in PHP 6.1
> 
>  Not saying that I would want this (I don't think I do), just mentioning
>  the option.
> 
> -- 
> Sebastian Bergmann  http://sebastian-bergmann.de/
> GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
> 

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

Re: [PHP-DEV] Namespace

[Sam Barrow]

I didn't put any work in here and I agree with him 100%. Namespaces have
been incredibly useful for me. Now that I'm using them I would not want
to do without them.

As far as bundling, my application (over 11,000 lines now) did use a
bundling feature that I can no longer use. It would be very nice to be
able to do this, but honestly it is worth the performance hit to me.

Any large application needs structure, and yes underscores can be used
but this is a pain typing out long names every time, and what's the
harm? If you want to use bundling or don't like namespaces then just
don't use them.

On Wed, 2007-12-05 at 20:08 +0100, Jochem Maas wrote:
> Stanislav Malyshev wrote:
> >> +1 for putting namespaces on the backburner and taking the time to
> >> get it 100% right ...
> > 
> > What's "100% right"? Any proposals (besides braces)?
> 
> I'll take a guess that you put alot of effort into the namespace 
> implementation,
> that's the only reason I can think of that your taking it all so personally 
> and
> being rather vitriol.
> 
> for the sake of your health take a step back and breath my friend. you are
> not the car you drive, the clothes you wear or the namespace implementation 
> you
> created :-)
> 
> > 
> >> apparently people keep 'flogging this horse to death' because they are
> >> not
> >> convinced by your wisdom with regard to this decision - they may be
> >> idiots (me included)
> > 
> > I never talked about "idiots". I know smart people can have different
> > opinions, and - oh horror! - some may have wrong or mistaken opinions
> > too, and that doesn't make them idiots. How about you?
> 
> it was a self effacing comment. I think it's safe to say that compared to
> most of the php devs, I, and people like me could be considered idiots at
> least as far as developing is concerned .. it's all relative besides which
> the key words were "may be".
> 
> > 
> >> actually that is not true - a halfbaked concept is pretty much
> >> garanteed to give you
> >> and the users of your product more headaches than no implementation at
> >> all. and
> > 
> > This concept, however, is not "halfbaked".
> 
> based on the reactions it has been recieving I would disagree. that is not to 
> say
> that completing the baking process would not result in a wonderful functional 
> addition
> to the language. I'm just advocating putting it on the backburner until the 
> cooking
> time is complete.
> 
> "halfbaked" is probably the wrong word - it has negative conatations that I 
> didn't
> mean to imply.
> 
> > 
> >> besides possibly having to type a little less, there seems to be
> >> nothing namespaces would
> >> give us [in it's current form] that we cannot achieve already ... with
> >> the bonus that
> > 
> > Yes there is. More structured and clean code.
> 
> you have metrics to back that up? of course not because it's a completely 
> subjective
> point of view - and many people seem to think that there is no real gain in 
> this respect,
> besides there is nothing to stop me writing namespaced spaghetti.
> 
> I agree that namespaces pontentially offer a tool that allows developers to 
> create
> clearer structure in their code but given that it's only a potential why not 
> take a time
> out to hammer out more details, get more consensus and work out the details 
> of where
> namespacing should go in terms of functionality with the hassle of having to 
> worry about BC.
> 
> > 
> >> conversly - when namespace functionality is released, every developer
> >> will be confronted
> >> with any problems they might bring with them, at some stage, because
> >> there will be third
> >> party code out there that uses namespaces (code which for the sake of
> >> argument one would
> >> be required to use under some circumstances).
> > 
> > These problems being?
> 
> no longer having the option of bundling files for performance reasons is one 
> example, personally
> I have never done anything like that but apparently other people do and with 
> positive results for
> their applications - to me it seems that forcing such a restriction on these 
> people is against the
> pragmatic philosophy that [hopefully still] drives php, and is rather 
> artificial.
> 

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

Re: [PHP-DEV] RFC: Dropping Namespace

[Sam Barrow]

I agree, I also see this as critical in large applications. The current
implementation may have some problems, yes, but it's not hurting anyone
who's not using namespaces.

The minor issues around namespaces can be worked out in due time, but I
think it would be a huge mistake to drop the whole idea. Most
programming languages have some type of namespace implementation, there
is obviously some usefulness to it.

My personal opinion:

- Allow multiple namespaces per file (mostly for bundling). Personally,
in my application, this cuts execution time literally from .18 seconds
to about .04. Microseconds, but with alot of users this would definitely
be beneficial.

- Braces or declarations like the current, it doesn't matter. However I
think it is important to be able to use the same namespace in different
blocks, allowing functions to be declared under the same namespace in
different files. Declarations like it is now seem fine.

- Some type of import X as Y statement might be useful, but would be
very easy to abuse. Some people would import too much and defeat the
entire purpose of namespaces. I don't have much of an opinion on this.

In essence, I believe keeping namespaces is a necessity. The only useful
feature I have seen people talking about is multiple namespaces per
file. I also saw a patch on here for it (only about 5 lines of actual
code changed by the way), I set it up on PHP 5.3 and I've been using it
for about 8 hours of constant development and testing with no problems
whatsoever.

On Wed, 2007-12-05 at 14:10 -0600, Nate Gordon wrote:
> On Dec 5, 2007 12:04 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > > collision problems that class naming and function naming have. Only
> >
> > Only if you insist on *not* using the namespaces to solve collision
> > problems. For the 1001th time - you can not expect to put all names into
> > global space and have the language by some magic to sort it out and go
> > both ways. One name can mean only one thing, namespaces or not.
> > Namespaces just allow you more convenient rules for defining what name
> > means what thing.
> 
> I would like to second this notion.  There are those who would say
> that the global namespace is for the use of PHP itself.  I would
> disagree heartily, PHP as a language is built to serve the developer
> who is using it.  They should decide what exists in the global
> namespace.
> 
> When I write a library I will often create functions/classes/variables
> that have no business being used outside my library.  So I don't see
> the need to make the names longer just so I don't collide with someone
> else's internal variables/classes/functions.
> 
> This paves the way for doing much more advanced things with packages
> and run-time loading of code (which I know some people will think
> isn't good).
> 
> Of all the namespace talk I've heard, the only part I disagree with is:
> 
> use Foo::Bar as OtherBar;
> 
> This seems like a maintainability nightmare to me as well as having
> well having some possible BC issues long-term.  If you don't like
> someone's class name that much that you have to alias it then just
> make your own wrapper class:
> 
> class OtherBar extends Foo::Bar {}
> 
> Its not like it is that many more characters to write.
> 
> So if we have to wait until PHP 6 to get this right, then so be it.  I
> just see this as being critical to the future of enterprise/large
> scale PHP and don't want to see it die.
> 
> 
> -- 
> -Nathan Gordon
> 
> If the database server goes down and there is no code to hear it, does
> it really go down?
> :wq
> 

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

Re: [PHP-DEV] Namespace

[Sam Barrow]

The implementation as it is now works. It's functional, and useful.
Minor issues like import/use can be worked out when necessary, but for
now I see this as something that can be released (provided that most of
the bugs are worked out). Multiple namespaces per file is the only thing
I see as a feature that should be added, but as of now it is not a
pressing issue.

On Wed, 2007-12-05 at 13:36 -0800, Stanislav Malyshev wrote:
> > implementation [details] not the concept. I believe that the implementation
> > needs a little ironing out ... what's the harm in taking the time to do 
> > this?
> > or at least taking the time to let consensus take hold?
> 
> No harm, but we will have multiple namespaces per file figured out 
> pretty soon, and I don't see any new developments with the braces thing, 
> so what exactly would we wait for?
> 
> > metrics that support your argument that namespaces will make code more
> > maintainable, offer better structure and cleaner code.
> 
> Obviously, we can't have any metrics of anything until the namespaces 
> are implemented and used in some serious project, which can't happen 
> until we have a release with namespaces in it.
> 
>   > it remains nothing more than a pontential even after release. in the 
> same
> 
> For some time, yes. And if one chooses not to use it, maybe forever for 
> that particular user.
> I'm all for discussing practical ones, but frankly I don't see any new 
> issues here worth delaying anything.
> -- 
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED]   http://www.zend.com/
> (408)253-8829   MSN: [EMAIL PROTECTED]
> 

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

RE: [PHP-DEV] Namespace

[Sam Barrow]

You have a point, however it is not always this simple. Some
applications have classes/functions that are not necessarily gathered in
order by their namespaces. It would be a nightmare to try to organize
and then bundle these functions and classes together dynamically into
different files by namespace.

So far I agree with most of the opinions regarding namespaces on here,
but I do think it would be best to allow multiple namespaces per file.
People say this will be confusing, but namespace declarations are pretty
clear, as in clean code they should be on their own line:

namespace usefulStuff ;

class a {}
function z() {}

Yes it has slight potential for chaotic code, but there are hundreds of
ways to create chaotic code, and this is nowhere near the top of the
list. I believe that the benefits of bundling (huge performance
increases in my case) outweigh the risks.

This may not apply to small projects with 2 or 3 namespaces, we also
have to consider larger ones.

On Fri, 2007-12-07 at 04:20 +1000, [EMAIL PROTECTED] wrote:
> Just a thought... You know the whole thing about bundling into one file
> improving performance.  People do this when they have upwards of 20 classes
> being included per request.  I bet that most of the time these classes are a
> part of a framework / something that would be a part of common name space
> anyway.
> 
> The whole "One namespace per file" policy will not stop people from bundling
> their classes.  It will still allow them to bundle, but they will be
> restricted to just one file per namespace.  
> 
> So given a situation where someone has a library of around 20 classes...
> Where they would normally bundle down to one file... They bundle it down to
> 3 files, one for each namespace... There is hardly going to be much of a
> performance difference between 1 and 3 includes.
> 
> I guess the point I am saying is that everyone is freaking out about the
> possible performance loss - but in reality you can still bundle and get 90%
> of the bundling gain.
> 
> SCOTT MCNAUGHT
> Software Developer
> 
> Synergy 8 / +617 3397 5212
> [EMAIL PROTECTED]
> 

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

Re: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace

[Sam Barrow]

I agree with everything here, especially the solution to multiple
namespaces per file (allow but discourage), but i don't agree with the
__php__ namespace. If any separation of core php and extensions into
namespaces happens, it should be kept as simple as possible, with root
namespaces like "php::" and "ext::". The application should be allowed
to define its own root namespace, or use a namespace such as "app::".
Besides that I think all of your other suggestions are the best ones.

On Thu, 2007-12-06 at 19:36 -0600, Gregory Beaver wrote:
> Hi Derick,
> 
> I've been thinking a *lot* about your provocative email in the past
> couple of days, and have come to a different conclusion from my original
> reply (which, as a reminder stated I saw no problem with removing
> namespaces as long as we kept the import facility to alias classes via
> use).  After a few hours of thinking practically about the
> implementation, I realized that this would be impossible for the same
> reasons as your first argument.  So, I set out to find a solution that
> keeps namespaces and solves the problems.
> 
> I have found the solutions to every problem I could find, and to my
> surprise, even after crafting a new patch to solve some of them, have
> found a way to solve all of the problems within the existing
> implementation (with a few tweaks, but nothing major changed) or by
> specifying new coding conventions.
> 
> Summary:
> 
> 1) recommend all global non-namespaced code that wishes to import
> namespaced code via "use Namespace::Classname" add a "namespace
> __php__;" at the top of the file, and that the __php__ namespace be
> reserved for use by end-user applications.
> 2) use Name::*; is technically impossible without some kind of
> autoloading mechanism, but can be reasonably approximated by importing a
> long namespace name as a shorter one.  "use PEAR2::Really::Long::Name as
> a;" then allows referring to PEAR2::Really::Long::Name::Classname as
> a::Classname, and PEAR2::Really::Long::Subnamespace::Classname as
> a::Subnamespace::Classname.
> 3) multiple namespaces per file should be allowed, but strongly
> discouraged as a coding practice of last resort for most users.
> 4) brackets for namespaces is most necessary for hierarchical namespace
> implementations.  This is not such an implementation, and as such
> brackets do not add clarity but do slow down the implementation.
> 5) namespaces provide these benefits that are not available in PHP:
>a) short, unqualified descriptive class names can be used without
> fear of conflicting with an internal class
>b) a clear, uniform coding convention on how to avoid conflicts
> between your code and others that will help those who have to maintain
> the code of others.
>c) a way to alias longer names to increase readability and
> maintainability of code.
> 6) There are some dangers when using namespaces with autoload, but
> simple ways of thwarting those dangers.  Also dangerous is trusting
> external code that is in the same namespace, as functions can be redefined.
> 
> Detailed answers:
> 
> Derick Rethans wrote:
> > 1. As it is impossible to do "use XXX as NativeClass" we get to the 
> 
> >extension (DateTime, DateTimeZone). However introducing the new class
> >DateTimeSpan might break people's code that do things like:
> > 
> >  > use myNamespace::DateTimeZone as DateTimeZone;
> > ?>
> 
> This is indeed the biggest problem.  However, it only exists in the
> global "namespace" (non-namespaced code).  An example script using the
> non-existing hypothetical PEAR2::DateTime class:
> 
>  include 'PEAR2/Autoload.php';
> use PEAR2::DateTime; // fatal error - use name conflicts with internal class
> $a = new DateTime;
> ?>
> 
> However, the answer is simple and elegant.  PHP applications that take
> advantage of namespaces should use a namespace *in the application
> global code* that is reserved for application code, like __php__.
> 
>  namespace __php__;
> include 'PEAR2/Autoload.php';
> use PEAR2::DateTime;
> $a = new DateTime; // $a is an object of class PEAR2::DateTime after
> autoloading, or if a previously included file has declared class
> DateTime in namespace PEAR
> ?>
> 
> Note that the only difference here is the addition of 1 line of code at
> the top of the file.  On the same token, this code:
> 
>  namespace __php__;
> $a = new DateTime; // $a is an object of class ::DateTime
> ?>
> 
> works as expected, accessing the internal DateTime class directly.
> 
> In other words, 1 line of code is needed to take advantage of
> namespace's full protection and ability to import conflicting class
> names into the "global" (in this case unqualified, not containing :: in
> the name) scope, while at the same time preserving BC with existing code
> (no modification needed beyond addition of "namespace __php__;").
> 
> I recommend that the manual specify this convention, and will happily
> take on the documentation of it.
> 
> > 2. You have to import 

Re: [PHP-DEV] Namespace

[Sam Barrow]

However you don't have a semicolon after your namespace declaration.
With the current implementation you would need a semicolon, which
doesn't look nearly as good with braces.

On Fri, 2007-12-07 at 15:21 -0500, Ken Stanley wrote:
> I understand what you mean, but I was just trying to put a real-world face
> on a so-far theoretical problem. But that does raise an interesting point;
> we can already use braces anywhere and everywhere, and while we could easily
> wrap namespaces in anonymous braces like you describe, why not just go the
> extra mile and allow attaching them directly to the namespace, i.e.:
> 
>  
> namespace XYZ {
> // Do stuff
> }
> 
> // Looks a little better than
> 
> {
> namespace XYZ;
> 
> // Do stuff
> 
> }
> 
> ?>
> 
> Of course, this is just my opinion, and given your suggestion, at least
> there is an acceptable solution already. Thank you. :)
> 
> On Dec 7, 2007 3:10 PM, Robert Cummings <[EMAIL PROTECTED]> wrote:
> 
> > Is there any reason why you can't already use braces optionally? I mean,
> > the following code is valid with the current engine:
> >
> >  >
> > {
> >{
> >{
> >class Foo
> >{
> >function Foo()
> >{
> >echo 'Foo'."\n";
> >}
> >}
> >}
> >}
> > }
> >
> > ?>
> >
> > Cheers,
> > Rob.
> > --
> > ...
> > SwarmBuy.com - http://www.swarmbuy.com
> >
> >Leveraging the buying power of the masses!
> > ...
> >
> 
> 
> 

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

Re: [PHP-DEV] Namespace

[Sam Barrow]

Very good point

namespace stuff ;
{
function myfunction() {
return true ;
}
}

That would actually work, but it's not quite the same as you have the
semicolon after the namespace declaration, which looks kind of stupid.
Overall i dont think braces are a bad idea.

People say multiple namespaces per file are confusing, but braces would
partially solve this. If using braces makes multiple namespaces per file
more likely, I say that's the way to go, as I am very much in favor of
multiple namespaces per file.

On Fri, 2007-12-07 at 15:10 -0500, Robert Cummings wrote:
> On Fri, 2007-12-07 at 14:57 -0500, Ken Stanley wrote:
> > In regards to the braces or no braces question, I have a scenario that I
> > would like to share that could be considered similar in nature. We use a
> > cluster of databases where I work, and to make things easier on us, we have
> > a method called setSource() to switch between the clusters in our database
> > class. This allows us to easily query between the clusters, but since there
> > are no braces, we sometimes lose track of which cluster we are working on,
> > and thus bugs are born. I would think that if it were some how possible to
> > have braces, it would cause less headaches and problems, because we could
> > then logically group our queries together. The same argument could be used
> > with namespaces; especially _if_ the multiple namespace-per-file gets added.
> > Even without that little bit of functionality, it would make maintaining
> > namespaced code easier to read at first glance. For small apps, it probably
> > wouldn't be that big of a difference, but for files that span hundreds (and
> > even thousands) of lines of code, a developer could easily get lost in in
> > the namespace they are supposed to be in. Am I in a namespace? Which
> > namespace? Without the code block, and typical indentation, you could easily
> > overlook the namespace keyword.
> > 
> > Anyways, I understand that braces are just a bit of icing on the cake -- so
> > to speak -- but I just wanted to give a probable real-life situation to this
> > debate. :)
> 
> Is there any reason why you can't already use braces optionally? I mean,
> the following code is valid with the current engine:
> 
>  
> {
> {
> {
> class Foo
> {
> function Foo()
> {
> echo 'Foo'."\n";
> }
> }
> }
> }
> }
> 
> ?>
> 
> Cheers,
> Rob.
> -- 
> ...
> SwarmBuy.com - http://www.swarmbuy.com
> 
> Leveraging the buying power of the masses!
> ...
> 

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

Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace

[Sam Barrow]

In C++, STD was just a normal namespace with some classes and functions
in it, you didn't have to say "use std" unless you wanted to use
functions in the std namespace.

The "php::" namespace could just be a container for all of the functions
and classes that are currently thrown into the global namespace.

I think the name __php__ is too long and inconvenient to be used for a
namespace for all of the built in php functions. I would suggest "php::"
for built in php functions and "ext" for extension
defined functions.

On Fri, 2007-12-07 at 18:42 -0600, Larry Garfield wrote:
> On Friday 07 December 2007, Gregory Beaver wrote:
> 
> > > If new, future core extensions showed up in a reserved PHP::
> > > namespace, you would be >:-).
> >
> > Exactly - which is why you should never put classes, functions or
> > constants in the __php__ namespace.  The convention I am proposing is to
> > only use __php__ for code that *uses* re-usable components, not
> > *declares* them.  In this case, your example would be revised as:
> >
> >  > namespace Mylib;
> > class Date {}
> > ?>
> >
> >  > namespace __php__;
> > use Mylib::Date;
> > include 'autoload.php'; // note - require_once and () just slow things down
> > $a = new Date();
> > ?>
> >
> > This convention serves two purposes
> >
> > 1) library code is always explicitly "use"d
> > 2) name conflicts are impossible
> >
> > The suggestion to make "namespace __php__;" implicit is very
> > interesting, but would defeat its purpose, which is to separate
> > declarations from use.
> >
> > Another off-list suggestion was to make "use" outside of a namespace
> > declaration an error, as this is generally a bad idea that can lead to
> > many "gotchas".
> >
> > Greg
> 
> Doesn't strict C++ also have a requirement for a global namespace definition? 
>  
> It has been a very long time since I did any C++, but I seem to recall a 
> requirement for a "use std" or something like that directive that I never 
> actually understood. :-)
> 
> If there is a "named global namespace" __php__, then requiring it in order to 
> import anything makes sense.  It's one extra line of code and doesn't break 
> BC anymore than using the use keyword does.  
> 
> Another observation, if one takes the position that library code and "running 
> code" should always be separated, this setup would encourage that "best 
> practice" but does not absolutely require it.  That fits with the "doing 
> something dumb should be hard, but not impossible" philosophy. :-)  That 
> recommendation would definitely need to be well-documented.
> 
> I overall like this concept.  Kudos to Greg, as others have said.  One 
> question I would have is what is the performance hit of braces over a 
> keyword?  (Not a challenge; I genuinely don't know what the C implementation 
> differences would be that would make a difference.)  
> 
> -- 
> Larry GarfieldAIM: LOLG42
> [EMAIL PROTECTED] ICQ: 6817012
> 
> "If nature has made any one thing less susceptible than all others of 
> exclusive property, it is the action of the thinking power called an idea, 
> which an individual may exclusively possess as long as he keeps it to 
> himself; but the moment it is divulged, it forces itself into the possession 
> of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
> Jefferson
> 

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

Re: [PHP-DEV] Namespace

[Sam Barrow]

Once you say "namespace xyz ;" everything in the file is now relative to
namespace xyz. To refer to the global namespace, you use the following



On Sat, 2007-12-08 at 20:12 +, Richard Quadling wrote:
> On 07/12/2007, Lokrain <[EMAIL PROTECTED]> wrote:
> > Hello all,
> >
> > I just wanted to drop an opp. Just to see the logic, when we have
> > programming structure class, interface, function, if statement, switch
> > statement etc, we have bracers encapsulation. This is the logic that most
> > programming language give to show a programmer that something is inside
> > something. We here have namespace with the same idea, and no bracers.
> >
> > Conclusion: namespaces are not logical => no thanks
> >
> > PS. By the way, I do not think that any workarounds on that logic will not
> > be nice.
> >
> 
> I'm trying to understand the argument against using braces.
> 
> And that has led me to the following question.
> 
> Assuming no braces, how would I put code OUTSIDE of the namespace in a
> single file.
> 
>  namespace XYZ;
> 
> xyz related code goes here
> 
> non xyz related code goes here but how do I let PHP know it isn't part of xyz?
> 
> 
> 
> Do I have to change namespace by using a dummy namespace? Same issue
> how do I refer to the global namespace.
> 
> 
> Richard.
> 
> -- 
> -
> Richard Quadling
> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
> "Standing on the shoulders of some very clever giants!"
> 

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

[PHP-DEV] Type hinting

[Sam Barrow]

A few weeks ago I wrote a message on this list about my patch for scalar
type hinting. I've been using it for about a month now in a large scale
application im developing with no problems. It allows type hinting for
the following types: int, float, string, bool (boolean), num (int or
float), scalar (int, float, string, or bool), object, and resource.

All of these types have been very useful. Num has been useful for any
mathematical functions, scalar has been the most useful, mostly for
echoing values and interacting with the database (as a database cant
store arrays or objects).

The type hinting is all 100% optional and has caused no problems for me
at all, I use it in most function but some functions I'll use it for one
parameter and not the other, or none at all with no problems.

What is the general opinion on this? Examples below:

 'b')) ; // Catchable fatal error: Argument 1
passed to displayStuff() must be a scalar, array given

?>

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

Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace

[Sam Barrow]

I agree with this 100%, is this something that could be changed? I don't
see a reason behind it.

On Sun, 2007-12-09 at 16:24 -0500, Jessie Hernandez wrote:
> 
> internal class/function with the same name.
> 
> Dmitry, what's the reason this lookup logic wasn't used in your patch?
> 

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

Re: [PHP-DEV] RFC: Arguments (and suggestions) against the current implementation of namespaces

[Sam Barrow]

Agreed. I don't see any point in this limitation. As for confusion,
debugging would not be too hard (just echo __NAMESPACE__), or brackets
would solve that problem.

On Mon, 2007-12-10 at 16:59 -0300, Martin Alterisio wrote:
> 2007/12/10, Martin Alterisio <[EMAIL PROTECTED]>:
> >
> >
> > > c) If bracketed namespaces are a no-go, consider the possibility of
> > > > declaring the full name of the namespaced element in its definition:
> > >
> > > Which would lead to people routinely mixing different namespaces inside
> > > one file. Bad idea. Also would kill namespaced functions and constants,
> > > which would make organizing libraries using those impossible.
> >
> >
> > Why would it lead to people routinely mixing different namespaces inside
> > one file?
> > Why is this bad in the first place?
> > Why is it the language the one to decide which is the better way to
> > organize code?
> >
> > Also, that would not kill neither namespaced functions nor constants:
> >
> >  > function namespaced::foo() {
> > ...
> > }
> > const namespaced::CONST = "I'm namespaced!";
> > ?>
> 
> 
> PS: An example of an organization model that wouldn't be possible with the
> current implementation of namespaces:
> 
> Imagine that I'm writing a small module for my app. Just a main class, some
> helper classes and exceptions. For the purposes of this module I just find
> more organized to keep everything in a one file. Also, I expect exceptions
> only to be raised in most exceptional cases, therefore I see that is best to
> keep them in a subordinated but different namespace. I have two namespaces,
> e.g.: MyModule and MyModule:Exceptions, but I can't keep them in the same
> file. I don't see the point on having the exceptions in a different file,
> and I really prefer to keep the main namespace of my module as clean as
> possible. The language just took away the possibility to decide which
> organization schema I prefer.

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

[PHP-DEV] Namespace resolution

[Sam Barrow]

Ok, it's supposed to be this way right? If i define a custom class in
the global namespace called "myClass" and I'm in another namespace, I
can only access it using ::myClass, not just myClass (without the
colons)? Seems to me that it should check the local namespace and then
the global, but it only checks the globl if i specifically tell it to
with the preceding "::".

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

[PHP-DEV] Re: Type hinting

[Sam Barrow]

I didn't do anything with overloading, just this.

Also, due to its functionality, it's not something that can be made into
an extension, it would have to go directly into the php source.

I have the patch if you want it, let me know. I've been using it for
almost a month now with PHP 5.3 with no problems.

On Tue, 2007-12-11 at 13:07 +0100, Christian Müller wrote:
> Sam Barrow schrieb:
>   > What is the general opinion on this?
> 
> I'm all for it.
> Would be using it already, if it where available as an extension.
> 
> Do i recall right, that you (or someone else) had this combined with 
> overloading?
> 
> --
> Chris

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

Re: [PHP-DEV] namespace improvements to be committed very soon - final review

[Sam Barrow]

Is this patch going to be implemented in the PHP release?

On Tue, 2007-12-11 at 18:42 -0500, David Coallier wrote:
> On Dec 11, 2007 6:13 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I've been furiously working behind the scenes with Stas and Dmitry, and
> > have some enhancements to namespaces in the form of 2 patches.
> >
> > 1) multiple namespaces per file
> > 2) use ::name;
> >
> > 1) multiple namespaces per file
> >
> > This is implemented as such:
> >
> >  > namespace one;
> > use Blah::A;
> > // code
> > namespace two;
> > use Foo::A;
> > ?>
> >
> > The example above shows that imported names are reset at each namespace
> > declaration.  There is no prohibition on this code:
> >
> >  > namespace one; {
> > use Blah::A;
> > // code
> > }
> > namespace two; {
> > use Foo::A;
> > // code
> > }
> > ?>
> >
> 
> namespace name; {
> ...
> }
>  ??? You can already do that... it's just adding random { }
> 
> 
> > Users who wish to use brackets may do so.  The performance penalty
> > imposed by using brackets is minor for some cases, and for users who are
> > following the recommended practice of 1 namespace per file, the syntax
> > is ideal.
> >
> > Patch is:
> >
> > http://pear.php.net/~greg/namespace/PHP_5_3/multi.patch.txt
> > http://pear.php.net/~greg/namespace/PHP_6_0/multi.patch.txt
> >
> > Note that non-namespaced code cannot be present in a file containing
> > namespaces.  For users who are bundling, this will mean you will need to
> > create 2 files, one with non-namespaced code, and one with namespaced
> > code.  This minor prohibition is a design decision, not a technical
> > problem in the implementation.
> >
> > 2) use ::name
> >
> > This code:
> >
> >  > namespace Whatever;
> > use MDB2; // import PEAR's ::MDB2 from global scope
> > $a = MDB2::connect();
> > ?>
> >
> > is currently impossible, which will make namespacing old code harder.
> > The patch introduces this new syntax to import names from the global
> > namespace:
> >
> >  > use ::MDB2, ::strlen as len;
> > ?>
> >
> > http://pear.php.net/~greg/namespace/PHP_5_3/use.patch.txt
> > http://pear.php.net/~greg/namespace/PHP_6_0/use.patch.txt
> >
> > These patches are for review of both serious technical and serious
> > implementation issues.  In order to help move things along, I'd like to
> > define "serious" as something directly related to the implementation
> > that would cause a failure in PHP's ability to run scripts
> > deterministically, or some kind of memory leak/crash.
> >
> > commit is planned for the next 24 hours or so, but of course any issues
> > found in review can be fixed.  The patches are short, so in the worst
> > case, reverting is not difficult.
> >
> > Thanks,
> > Greg
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> 
> 
> 
> -- 
> David Coallier,
> Founder & Software Architect,
> Agora Production (http://agoraproduction.com)
> 51.42.06.70.18
> 

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

[PHP-DEV] Will pay for feature add

[Sam Barrow]

If anyone here is experienced enough to help me, I will pay for a patch
to allow for multiple class inheritance (class D extends A, B, C)
against PHP 5.3 CVS. Or if you can just help me get started on writing
it, I'm sure I could finish myself. I'm just stuck at the basic zend
class declaration functions.

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

RE: [PHP-DEV] Will pay for feature add

[Sam Barrow]

I understand that this functionality would not be implemented in the PHP
release, I was just going to try to get it going for myself, so that I
could have my own patch and compile from source when needed.

On Tue, 2007-12-25 at 17:39 -0800, Andi Gutmans wrote:
> Hi Sam,
> 
> When we designed PHP 5 we intentionally went down the Java-like route of
> multiple interfaces and single inheritance. This was a major design
> decision and not something we want to change. From the languages which
> do support it like C++ you can see how many problems it creates and the
> workarounds the language needs to support, hence why Java went down a
> different route.
> 
> The features you should be looking at are interfaces, single
> inheritance, and __call(). If there are special needs you have which
> require some additional functionality you may want to look at building
> some proxy class in C as a PHP extension but I have yet to see many
> situations where that's really needed.
> 
> Andi
> 
> > -Original Message-
> > From: Sam Barrow [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 25, 2007 12:23 PM
> > To: PHP Developers Mailing List
> > Subject: [PHP-DEV] Will pay for feature add
> > 
> > If anyone here is experienced enough to help me, I will pay for a
> patch
> > to allow for multiple class inheritance (class D extends A, B, C)
> > against PHP 5.3 CVS. Or if you can just help me get started on writing
> > it, I'm sure I could finish myself. I'm just stuck at the basic zend
> > class declaration functions.
> > 
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

[PHP-DEV] Function type hinting

[Sam Barrow]

I read that type hinting for function return values was going to be
implemented, is this true? If not, is it something that could be
implemented if I were to write a patch?

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?

And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a parent class that must
return a certain type.

class a {
abstract public function getNumber() returns int ;
}
class b extends a {
public function getNumber() {
return rand() * 3463 ;
}
}
class c extends a {
public function getNumber() {
return 'I\'m going to mess everything up by returning a 
string.' ; //
Would cause error with type hinting.
}
}

On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
> Hello everyone
> 
> I figured I would bring my opinion in to support of Sam's request for a more 
> complete type hinting feature. Namely I am interested in the support for 
> hinting scalar types on function and method arguments and I am sure it is 
> safe for me to say that I speak for a lot of people. Most people that I know 
> find the current type hinting, while useful, ridiculous because it looks like 
> the job was left unfinished for whatever abstract reason.
> 
> In my opinion type hinting should definitely be allowed for scalar values. As 
> for return types, I am not so sure. So far I have found no use for such a 
> feature in my own code, so I won't comment on it. If it is added, I welcome 
> it for those who find it useful but if it is not added I will not loose sleep 
> over it.
> 
> > I was thinking at something along the lines of objects also for instance:
> > $i = new Integer(33); 
>  After my own experiments with the subject I concur that while it can be made 
> to work, it is not only a bad idea (for the reasons mentioned earlier) it is 
> also redundant and just unnecessary. There is a lot better way to accomplish 
> the same and that by allowing scalar values to be hinted. It is simpler, 
> cleaner, and easier to implement.
> 
> > What if type hinting just generated an E_NOTICE. Nothing more for the
> > time being.
>  Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since if I 
> write a piece of code that hints that the argument for a-whatever method 
> needs to be an integer it seems useless if the user of my library can avoid 
> the issue just by supressing lesser errors and those who do not need to write 
> extensive error handling code to respond to this sort of error (if they 
> indeed deem it necessary to do so).
> 
> While hinting is, and should remain, optional, when it is used it should be 
> enforced. After all the user of my library has the option to dump it and go 
> for another library that does not force types. That is the beauty of having 
> options.
> 
> Tomi Kaistila
> PHP Developer
> 

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?

And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a parent class that must
return a certain type.

class a {
abstract public function getNumber() returns int ;
}
class b extends a {
public function getNumber() {
return rand() * 3463 ;
}
}
class c extends a {
public function getNumber() {
return 'I\'m going to mess everything up by returning a
string.' ; //
Would cause error with type hinting.
}
}

On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
> Hello everyone
> 
> I figured I would bring my opinion in to support of Sam's request for
a more 
> complete type hinting feature. Namely I am interested in the support
for 
> hinting scalar types on function and method arguments and I am sure it
is 
> safe for me to say that I speak for a lot of people. Most people that
I know 
> find the current type hinting, while useful, ridiculous because it
looks like 
> the job was left unfinished for whatever abstract reason.
> 
> In my opinion type hinting should definitely be allowed for scalar
values. As 
> for return types, I am not so sure. So far I have found no use for
such a 
> feature in my own code, so I won't comment on it. If it is added, I
welcome 
> it for those who find it useful but if it is not added I will not
loose sleep 
> over it.
> 
> > I was thinking at something along the lines of objects also for
instance:
> > $i = new Integer(33); 
>  After my own experiments with the subject I concur that while it can
be made 
> to work, it is not only a bad idea (for the reasons mentioned earlier)
it is 
> also redundant and just unnecessary. There is a lot better way to
accomplish 
> the same and that by allowing scalar values to be hinted. It is
simpler, 
> cleaner, and easier to implement.
> 
> > What if type hinting just generated an E_NOTICE. Nothing more for
the
> > time being.
>  Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat
since if I 
> write a piece of code that hints that the argument for a-whatever
method 
> needs to be an integer it seems useless if the user of my library can
avoid 
> the issue just by supressing lesser errors and those who do not need
to write 
> extensive error handling code to respond to this sort of error (if
they 
> indeed deem it necessary to do so).
> 
> While hinting is, and should remain, optional, when it is used it
should be 
> enforced. After all the user of my library has the option to dump it
and go 
> for another library that does not force types. That is the beauty of
having 
> options.
> 
> Tomi Kaistila
> PHP Developer
> 
On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
> Hello everyone
> 
> I figured I would bring my opinion in to support of Sam's request for a more 
> complete type hinting feature. Namely I am interested in the support for 
> hinting scalar types on function and method arguments and I am sure it is 
> safe for me to say that I speak for a lot of people. Most people that I know 
> find the current type hinting, while useful, ridiculous because it looks like 
> the job was left unfinished for whatever abstract reason.
> 
> In my opinion type hinting should definitely be allowed for scalar values. As 
> for return types, I am not so sure. So far I have found no use for such a 
> feature in my own code, so I won't comment on it. If it is added, I welcome 
> it for those who find it useful but if it is not added I will not loose sleep 
> over it.
> 
> > I was thinking at something along the lines of objects also for instance:
> > $i = new Integer(33); 
>  After my own experiments with the subject I concur that while it can be made 
> to work, it is not only a bad idea (for the reasons mentioned earlier) it is 
> also redundant and just unnecessary. There is a lot better way to accomplish 
> the same and that by allowing scalar values to be hinted. It is simpler, 
> cleaner, and easier to implement.
> 
> > What if type hinting just generated an E_NOTICE. Nothing more for the
> > time being.
>  Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since if I 
> write a piece of code that hints that the argument for a-whatever method 
> needs to be an integer it seems useless if the user of my library can avoid 
> the issue just by supressing lesser errors and those who do not need to write 
> extensive error handling code to respond to this sort of error (if they 
> indeed deem it necessary to do so).
> 
> While hinting is, and should remain, optional, when it is used it should be 
> enforced. After all the user of my library has the option to dump it and go 
> for another library that does not force types. That is the beauty of having 
> options.
> 
> Tomi Kaistila
> PHP Developer
> 

-- 
PHP Internal

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

I think we should stick with E_WARNING for now. If you want to use
exceptions you can throw one in a custom error handler. I can change
about 4 lines of code in my patch to have it emit an E_WARNING easily.

On Thu, 2008-01-03 at 19:49 +0100, Jochem Maas wrote:
> am I the only one to consider E_FATAL (as generated for class typehints) makes
> type hinting useless - given that there is no compile stage at which to catch
> typehint related mistakes. which means there is no way to trap the issue and
> offer some useful/user-friendly feedback to the user (in practice it usually
> means the white page of death for a site visitor)
> 
> E_WARNING also is not much better given that one would assume the 
> function/method
> that was passed incorrect variables (according to type) wouldn't run.
> 
> would an exception not be the most suitable thing to generate on a typehint 
> error?
> to me anything else makes typehinting in production environments pretty much 
> unusable
> unless one write code like so:
> 
> function foo(Foo $f) { /* do foo stuff */ }
> 
> $f = getFoo();
> if ($f instanceof Foo) {
>   foo($f);
> }
> 
> now the issue with such code is not that it is alot more verbose than might
> strictly be needed but that the instanceof statement makes the typehint rather
> superfluous.
> 
> 
> 
> Tomi Kaistila schreef:
> > Yes it seems PHP will omit E_WARNING if you omit an argument.
> > 
> > (Had to actually check.)
> > 
> > Not a bad choice for an error and probably also easier to manage when you 
> > are 
> > dealing with complicated error handling in large applications.
> > 
> > I would suggest E_WARNING or E_FATAL, but not E_NOTICE or E_STRICT, for the 
> > simple fact that they are ignore by a major portion of PHP developers and 
> > to 
> > use them would prompt a high risk of people writing bad code.
> > 
> > Also, now that you mentioned abstract classes, type hinting might also be 
> > useful with interfaces.
> > 
> > Tomi Kaistila
> > PHP Developer
> > 
> > On Thursday 03 January 2008 19:21:21 you wrote:
> >> I think E_WARNING would be appropriate. That's what happens when you
> >> omit an argument to a function right?
> >>
> >> And about function return type hinting, I don't think it would be as
> >> useful as parameter type hinting, but it would be useful. Mostly for
> >> stuff like declaring an abstract function in a parent class that must
> >> return a certain type.
> >>
> >> class a {
> >>abstract public function getNumber() returns int ;
> >> }
> >> class b extends a {
> >>public function getNumber() {
> >>return rand() * 3463 ;
> >>}
> >> }
> >> class c extends a {
> >>public function getNumber() {
> >>return 'I\'m going to mess everything up by returning a 
> >> string.' ; //
> >> Would cause error with type hinting.
> >>}
> >> }
> >>
> >> On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
> >>> Hello everyone
> >>>
> >>> I figured I would bring my opinion in to support of Sam's request for a
> >>> more complete type hinting feature. Namely I am interested in the support
> >>> for hinting scalar types on function and method arguments and I am sure
> >>> it is safe for me to say that I speak for a lot of people. Most people
> >>> that I know find the current type hinting, while useful, ridiculous
> >>> because it looks like the job was left unfinished for whatever abstract
> >>> reason.
> >>>
> >>> In my opinion type hinting should definitely be allowed for scalar
> >>> values. As for return types, I am not so sure. So far I have found no use
> >>> for such a feature in my own code, so I won't comment on it. If it is
> >>> added, I welcome it for those who find it useful but if it is not added I
> >>> will not loose sleep over it.
> >>>
>  I was thinking at something along the lines of objects also for
>  instance: $i = new Integer(33);
> >>>  After my own experiments with the subject I concur that while it can be
> >>> made to work, it is not only a bad idea (for the reasons mentioned
> >>> earlier) it is also redundant and just unnecessary. There is a lot better
> >>> way to accomplish the same and that by allowing scalar values to be
> >>> hinted. It is simpler, cleaner, and easier to implement.
> >>>
>  What if type hinting just generated an E_NOTICE. Nothing more for the
>  time being.
> >>>  Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since
> >>> if I write a piece of code that hints that the argument for a-whatever
> >>> method needs to be an integer it seems useless if the user of my library
> >>> can avoid the issue just by supressing lesser errors and those who do not
> >>> need to write extensive error handling code to respond to this sort of
> >>> error (if they indeed deem it necessary to do so).
> >>>
> >>> While hinting is, and should remain, optional, when it is used it should
> >>> be enforced. After all the user of my library has the option to dump it
> >>> and go for another library that d

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

Thank you. As long as a feature is useful, why not add it? Just because
some people don't find it useful, this is not at all a reason to
completely discard the idea, especially when the only argument is "well
PHP doesn't need that so just use another language".

On Thu, 2008-01-03 at 20:23 +0100, Derick Rethans wrote:
> On Thu, 3 Jan 2008, Stanislav Malyshev wrote:
> 
> > > When the type hint says I want an integer, then only integer should be
> > > accepted; no casting should be done. It may give predictable results
> > 
> > Why people that want Java just don't use Java I wonder? PHP never was a 
> > strict
> > static typed language.
> 
> Broken record perhaps? I am getting a bit tired of this "just use Java 
> argument", it's perhaps even a bit arrogant. From what I read there is 
> plenty of people that want type hints for static types - there's a few 
> patches out there, it doesn't slow down the general case. So why should 
> we *not* add it? (And yes, I changed my mind)
> 
> regards,
> Derick
> 
> -- 
> Derick Rethans
> http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
> 

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

Just so anyone who wants it has it, I have attached the last version of
my patch.

Note that it still issues a fatal error but this can be changed very
easily, would take me about 2 minutes.

Full specs:
Type hinting patch allows for 8 new type hints, in addition to array and
class type hinting.

- Integers (specified by "int", "integer", or "long")
- Floats (specified by "float", "double", or "real")
- Numbers (matches integers and floats, specified by "num" or "number")
- Strings (specified by "string")
- Booleans (specified by "bool" or "boolean")
- Scalars (matches strings, booleans, and numbers; specified by
"scalar")
- Resources (specified by "resource")
- Objects (matches any object, specified by "object")

The patch specifies a constant, PATCH_SCALAR_TYPE_HINTING, just there to
indicate that the patch is installed.

On Thu, 2008-01-03 at 20:23 +0100, Derick Rethans wrote:
> On Thu, 3 Jan 2008, Stanislav Malyshev wrote:
> 
> > > When the type hint says I want an integer, then only integer should be
> > > accepted; no casting should be done. It may give predictable results
> > 
> > Why people that want Java just don't use Java I wonder? PHP never was a 
> > strict
> > static typed language.
> 
> Broken record perhaps? I am getting a bit tired of this "just use Java 
> argument", it's perhaps even a bit arrogant. From what I read there is 
> plenty of people that want type hints for static types - there's a few 
> patches out there, it doesn't slow down the general case. So why should 
> we *not* add it? (And yes, I changed my mind)
> 
> regards,
> Derick
> 
> -- 
> Derick Rethans
> http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
> 
Index: Zend/zend_API.h
===
RCS file: /repository/ZendEngine2/zend_API.h,v
retrieving revision 1.207.2.8.2.8.2.5
diff -u -r1.207.2.8.2.8.2.5 zend_API.h
--- Zend/zend_API.h	2 Nov 2007 19:40:37 -	1.207.2.8.2.8.2.5
+++ Zend/zend_API.h	21 Dec 2007 20:56:40 -
@@ -69,7 +69,7 @@
 #define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name, sizeof(#name)-1, NULL, 0, 1, allow_null, pass_by_ref, 0, 0 },
 #define ZEND_BEGIN_ARG_INFO_EX(name, pass_rest_by_reference, return_reference, required_num_args)	\
 	const zend_arg_info name[] = {		\
-		{ NULL, 0, NULL, 0, 0, 0, pass_rest_by_reference, return_reference, required_num_args },
+		{ NULL, 0, NULL, 0, 0, 0, pass_rest_by_reference, return_reference, required_num_args, 0, 0, 0 },
 #define ZEND_BEGIN_ARG_INFO(name, pass_rest_by_reference)	\
 	ZEND_BEGIN_ARG_INFO_EX(name, pass_rest_by_reference, ZEND_RETURN_VALUE, -1)
 #define ZEND_END_ARG_INFO()		};
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.31
diff -u -r1.647.2.27.2.41.2.31 zend_compile.c
--- Zend/zend_compile.c	13 Dec 2007 10:02:03 -	1.647.2.27.2.41.2.31
+++ Zend/zend_compile.c	21 Dec 2007 20:56:41 -
@@ -1341,26 +1341,54 @@
 	cur_arg_info->pass_by_reference = pass_by_reference;
 	cur_arg_info->class_name = NULL;
 	cur_arg_info->class_name_len = 0;
+ 	cur_arg_info->scalar_type_hint = 0;
+ 	cur_arg_info->number_type_hint = 0;
+ 	cur_arg_info->type_hint = 0;
 
 	if (class_type->op_type != IS_UNUSED) {
-		cur_arg_info->allow_null = 0;
 		if (class_type->u.constant.type == IS_STRING) {
-			if (ZEND_FETCH_CLASS_DEFAULT == zend_get_class_fetch_type(Z_STRVAL(class_type->u.constant), Z_STRLEN(class_type->u.constant))) {
-zend_resolve_class_name(class_type, &opline->extended_value, 1 TSRMLS_CC);
-			}
-			cur_arg_info->class_name = class_type->u.constant.value.str.val;
-			cur_arg_info->class_name_len = class_type->u.constant.value.str.len;
-			if (op == ZEND_RECV_INIT) {
-if (Z_TYPE(initialization->u.constant) == IS_NULL || (Z_TYPE(initialization->u.constant) == IS_CONSTANT && !strcasecmp(Z_STRVAL(initialization->u.constant), "NULL"))) {
-	cur_arg_info->allow_null = 1;
-} else {
-	zend_error(E_COMPILE_ERROR, "Default value for parameters with a class type hint can only be NULL");
+ 			if (strcasecmp("scalar", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->scalar_type_hint = 1;
+ 			} else if (strcasecmp("num", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->number_type_hint = 1;
+ 			} else if (strcasecmp("number", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->number_type_hint = 1;
+ 			} else if (strcasecmp("int", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->type_hint = IS_LONG;
+ 			} else if (strcasecmp("integer", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->type_hint = IS_LONG;
+ 			} else if (strcasecmp("long", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->type_hint = IS_LONG;
+ 			} else if (strcasecmp("float", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->type_hint = IS_

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 20:50 +0100, Derick Rethans wrote:

> With that statement I don't agree though. It needs to be usefull for a 
> more general public, and not introduce a huge performance loss for 
> example.

You're right, I didn't mean that like it sounded.

But a feature that maintains backwards compatibility and doesn't have a
major disadvantage for those who choose not to use it is almost always
good. In this case, it will benefit many, and to those who choose not to
use it, they will probably never even notice it's there.

So why not? Because it somehow goes against the ideology of some PHP
users? I'm sorry but I just don't see that as reason enough to throw
away something that could be very useful.

PHP is quickly moving from an easy to learn unprofessional scripting
language into an enterprise-level scalable language. Look at it's newer
enhanced XML capabilities, improved OO engine, and all of the
third-party integration libraries.

Finer-grained control over an application (which type hinting
contributes to) is something that fits the newer and better language
that PHP is becoming.

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 22:01 +0200, Tomi Kaistila wrote:
> > Broken record perhaps? I am getting a bit tired of this "just use
> Java
> > argument", it's perhaps even a bit arrogant. From what I read there
> is
> > plenty of people that want type hints for static types - there's a
> few
> > patches out there, it doesn't slow down the general case. So why
> should
> > we *not* add it? (And yes, I changed my mind)
> Same here. I am getting generally tired of the attitude some 
> politically-correct people seem to have about writing "javaish" code. What 
> the heck is "javaish" code anyway? Most features that exist in both PHP and 
> Java can also be found in myriad of other languages and it has so far not 
> stopped the development team from adding a feature when it is clearly useful 
> and (most importantly) desired an uncounted number of people.
> 
> In fact those who oppose the feature seem only capable of doing so with 
> hair-splitting rhetorics.

Thank you, I've been thinking this stuff for a while now, ever since the
attitude I got when first introducing my patch. I'm glad some people
agree with me.

I don't care what my code looks like, and it's not written in some holy
PHP bible that PHP's one and only purpose of existence is to not be like
Java. If a good feature comes along, it should be evaluated on its pros
and cons, not whether or not it reminds us of Java or any other language
for that matter.

I'm sorry I just have no idea where people come up with this stuff. We
are supposed to be thinking technically and logically as we are all
obviously computer people, not like some Java-hating cult. The issue
seems incredibly simple to me, if there's a good feature and it's worth
adding, add it.

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 13:00 -0700, John Coggeshall wrote:

> Wouldn't this patch also allow for additional performace optimizations  
> which would help counter losses even in the non-general case?

Performance optimizations in what way?

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 12:27 -0800, Stanislav Malyshev wrote:
> > patches out there, it doesn't slow down the general case. So why
> should 
> > we *not* add it? (And yes, I changed my mind)
> 
> My opinion is that the language is not a salad of features that somebody 
> somewhere found useful. The language should have some directions and 
> properties that make it easy to understand and handy to work with. 
> Having both strict and non-strict typing in the same language does not 
> seem like a good idea to me.

In a way this is true, but I look at it this way. Some languages are
strictly typed, some are dynamically typed. PHP can have the best of
both worlds by having optional strict typing where desired, as well as
dynamic typing. I have numerous cases where I will have a type hinted
parameter and a non type hinted parameter in the same function. This way
we can have maximum flexibility where useful, but also control where
needed.

Keep in mind, this is not "strict typing" in its correct definition.
Strict typing allows very little room for type conversion. This is
optionally hinting the desired type of a function parameter.

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 12:51 -0800, Stanislav Malyshev wrote:
> > In a way this is true, but I look at it this way. Some languages are
> > strictly typed, some are dynamically typed. PHP can have the best of
> > both worlds by having optional strict typing where desired, as well as
> 
> I do not believe trying to both eat cake and leave it intact would do us 
> well. Mixing strict and non-strict code would be a nightmare. Absence of 
> static type control (necessary for interpreted language) would make 
> strictly typed code less, and not more stable. Add performance penalty 
> from type checking and effort would be required from PHP newcomers to 
> understand two code models instead of one - and you get the worst of 
> both worlds, not the best.

But this is not all-out strict typing. This is simply checking types on
execution of a function. I wrote the patch to follow the exact same
model as array type hinting. The only difference is that instead of
checking if the value is an array, it checks if it is an integer,
string, bool, etc.

There aren't two code models here at all. You can have a function
parameter, or you can have a type-enforced function parameter. PHP
newcomers can just not use type hinting if they want but I don't think
this is a valid argument.

As for performance, you may have a point. However it is probably no
worse than array type hinting, and it's definitely faster than class
type hinting, which were both deemed useful for PHP 5.1.

> > Strict typing allows very little room for type conversion. This is
> > optionally hinting the desired type of a function parameter.
> 
> That's not what I am hearing here on the list.

Sorry I don't understand, what is it you are not hearing on the list?

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 22:14 +0100, Jochem Maas wrote:
> Stanislav Malyshev schreef:
> >> In a way this is true, but I look at it this way. Some languages are
> >> strictly typed, some are dynamically typed. PHP can have the best of
> >> both worlds by having optional strict typing where desired, as well as
> > 
> > I do not believe trying to both eat cake and leave it intact would do us
> > well. Mixing strict and non-strict code would be a nightmare. 
> 
> possibly like the nightmare that namespaces will give us in there current
> form? I mention it because use of typehinting seems alot more voluntary and
> less intrusive (when one encounters it in 3rd party code) than namespaces will
> be.

I don't think any of this stuff will be a nightmare. Maybe for someone
who has no idea what they're doing, but in that case programming in any
language would be a nightmare.

> > Absence of
> > static type control (necessary for interpreted language) would make
> > strictly typed code less, and not more stable. Add performance penalty
> > from type checking and effort would be required from PHP newcomers to
> > understand two code models instead of one - and you get the worst of
> 
> newcomers? or newbies? the level of entry is being raised in all sorts of
> areas whether you like it or not as a by product of making php more
> suitable to enterprise level development. it's merely a case of
> not being able to please everyone all of the time (or of not having your cake
> and eating it)

I don't think we should hold back the advancement of PHP and slow down
hundreds of experienced developers to accommodate the newcomers. That's
like having a universal speed limit of 25mph to accommodate those who
don't know how to drive.

Learning a language is hard. If a newcomer wants to learn PHP, they will
work at it and do it, but keeping PHP at a lower level than what it
should be just to make it easier on newcomers is ridiculous.

> > both worlds, not the best.
> 
> why do we then have typehinting for objects? and more recently arrays?

Exactly. It makes no sense to me to introduce type checking for objects,
but not for scalar types, when 75% of my variables are integers,
strings, booleans, etc, and only about 25% are arrays and objects.

> I also seem to remember (forgive me if Im mistaken) that you we're a
> proponent for the increases in strictness surrounding various things related
> to OO. that feels rather hypocritical at some level.
> 
> > 
> >> Strict typing allows very little room for type conversion. This is
> >> optionally hinting the desired type of a function parameter.
> > 
> > That's not what I am hearing here on the list.
> 
> you implied in another post that php should have some kind of structured 
> direction.
> how about a language spec and a formal functionality proprosal/acceptance 
> mechanism?
> (preferably one that didn't allow major changes like the inclusion of 
> namespaces into
> a minor release)
> 

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 13:37 -0800, Stanislav Malyshev wrote:
> > suitable to enterprise level development. it's merely a case of
> > not being able to please everyone all of the time (or of not having your 
> > cake
> 
> PHP is pretty good with pleasing people (including enterprise 
> developers) as it is now, and will get better in 5.3 and 6 - without any 
> strict typing. So this argument is not exactly in your favor - burden of 
> proof is on new feature proposals, and bigger the feature - bigger the 
> burden.

Very true. But we have to make sure to give new features a completely
honest and objective view, strictly on their technical merits.

> > I also seem to remember (forgive me if Im mistaken) that you we're a
> > proponent for the increases in strictness surrounding various things related
> > to OO. that feels rather hypocritical at some level.
> 
> Like what? You don't expect me to have same opinion to all proposals, do 
> you?
> 
> > you implied in another post that php should have some kind of structured 
> > direction.
> > how about a language spec and a formal functionality proprosal/acceptance 
> > mechanism?
> 
> Yes, I'd be happy to see it happening. No, I don't have time to create 
> it. If you do - you know where to find a text editor and docbook build 
> system ;)
> 
> > (preferably one that didn't allow major changes like the inclusion of 
> > namespaces into
> > a minor release)
> 
> 5.3 is a "major" release from a lot of aspects, don't let the numbering 
> fool you. It is generally accepted that waiting for PHP 6 to make any 
> change would be too long. Unfortunately, we couldn't find a number 
> between 5 and 6 for a version number, so we'd have to settle on 5.3.

Definitely, and namespaces have caused me no problems and I've been
developing in PHP 5.3 (heavily using namespaces) for a couple of months.
I supported and still do support the namespace implementation 100%.

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 22:37 +0100, Markus Fischer wrote:

> Of course, Jochem, you're right. Exceptions would be nice.
> WrongArgumentException, InvalidWhateverException, ...

That would be very nice. The full blown suite of exception error 
handlers could be a future project, depending on code contributors and
community support.

As for my patch, I think we can all agree on E_WARNING. 

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

The value is this:

With type hinting:

function a(string $mystring, num $mynum, object $myobject) {

}

Without type hinting:

function a($mystring, $mynum, $myobject) {
if (!is_string($mystring)) {
trigger_error('Parameter 1 of function a() must be a string.',
E_USER_WARNING) ;
}
if (!is_int($mynum) and !is_float($mynum)) {
trigger_error('Parameter 2 of function a() must be a number.',
E_USER_WARNING) ;
}
if (!is_object($myobject) {
trigger_error('Parameter 3 of function a() must be an object.',
E_USER_WARNING) ;
}
}

On Thu, 2008-01-03 at 13:51 -0800, Stanislav Malyshev wrote: 
> > There aren't two code models here at all. You can have a function
> > parameter, or you can have a type-enforced function parameter. PHP
> 
> So now to use such function you'd have to check your variables for 
> typing - otherwise your application blows up. And the type-checking 
> should be total - otherwise you miss some call to some function or some 
> code path bringing wrong value and your application blows up at runtime 
> - since static type checking is not available. Meaning, unless all of 
> your code is type-enforced, you'd have to write a wrapper around each 
> type-enforced function manually checking that wrong value didn't get in. 
>   But you can do the same checks now, so what is the added value?

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

RE: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

You have a point, but for input in general non type-hinted functions
should be used. Your first example shows a scenario in which not to use
type hinting, because all $_REQUEST input is in string form. However
when dealing with internal functions and methods, type hinting can
prevent flawed interaction between multiple developer's code, as well as
enforce a consistent API.

On Thu, 2008-01-03 at 22:13 +, Amir Abiri wrote:
> The question that pops to my mind by reading this thread is "what's wrong 
> with the following code":
> 
> function add(int $a, int $b)
> {
>   return $a + $b;
> }
> 
> add($_REQUEST['a'], $_REQUEST['b']); // Assume $_REQUEST['a'] == '1' and 
> $_REQUEST['b'] == '2'.
> 
> And the truth is that if I was forced to explicitly cast I would be annoyed. 
> I can't say I see that
> cast as promoting better code or more readable code - It would just clutter 
> the code and be
> annoying. PHP does a lot of type juggling for me, why annoy me all of a 
> sudden? 
> 
> As for the argument of "it's optional" the problem with it is that most code 
> that the average PHP
> developer writes is constrained PHP that other PHP developers have already 
> written, either library
> or code base. The feature may be optional for the developer writing the 
> function or method, but it
> is enforced on the developer who's using it. This is exactly where the 
> "direction of the platform"
> arguments come into play.
> 
> So I'm thinking, "No".
> 
> But then I was thought about it further and thought about this scenario:
> 
> $a = some_functions(); // Let's say it returned NULL.
> $b = $_REQUEST['b'];   // Let's say this is ''.
> 
> add($a, $b);
> 
> 
> Very bad. Hell I'd like to have some easy way of telling off the developer 
> who tries to do that to
> my function. Enter type hints.
> 
> 
> Here are a few more examples:
> 
> concatenate(string $str1, string $str2)
> {
>   return $str1 . $str2;
> }
> 
> concatenate('x', 1);   // Great, what's the big deal ?
> concatenate(NULL, false);  // Hmm...
> concatenate($obj1, $obj2); // $obj1 and $obj2 have __toString().
> 
> 
> So the bottom line is that it seems to me that what would be really useful is 
> not strict type
> hinting, but more like "Juggling hinting". i.e differentiate between an "OK" 
> type juggle and a "bad"
> type juggle. Silently perform the first, while emit a small notice or warning 
> for the later.
> 
> Just my... erm, 2$... :-)
> 
> A
> 

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

If foo() is changed, the type hints should be removed. Most of the time
however, a function will not change its functionality enough to change
the purpose of the arguments.

On Thu, 2008-01-03 at 14:50 -0800, Stanislav Malyshev wrote:
> > type-hinting is asserting.
> > checking of types is needed only on interface-border points (where
> 
> With strict checking, that means instead of calling:
> foo($bar);
> you'd have now to do:
> if(is_integer($bar)) {
> // stupid foo() call would blow up if passed not integer, so I have 
> to manually handle it
> // oh wait, actually I don't have any way to handle it - I need 
> foo() to be called to proceed
> // so let's just
> die("can't call foo() because \$bar is not integer");
> }
> foo($bar);
> 
> Now how it's easier or makes application more stable? What happens if 
> foo() is changed and now accepts both integers and strings? What happens 
> if someone forgets to write a wrapper?
> -- 
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED]   http://www.zend.com/
> (408)253-8829   MSN: [EMAIL PROTECTED]
> 

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

It doesn't disable type conversion unless you specifically tell it to.
Plus the fact that if it issues an E_WARNING, your application will not
necessarily stop execution.

On Thu, 2008-01-03 at 14:30 -0800, Stanislav Malyshev wrote:
> > I don't get it.  We already have type hinting, just not for scalars. The 
> 
> Type hinting for scalars is different because it disables one of the 
> features of PHP language - conversion of scalar types into each other.
> 
> > So, can we switch the mundane conversation from "should we have type 
> > hinting" to "why don't we have scalar type hinting if we have non-scalar 
> > type hinting?"  That is the real conversation.  Type hinting is here. It 
> 
> These are different kinds of typing, with different consequences. You do 
> not convert DateTime into PEAR_Soap_Client routinely, nor such 
> conversion can make any sense at all, so distinguishing between them is 
> not the same as making hard distinction between integer and float and 
> string, and disabling conversion between them.
> -- 
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED]   http://www.zend.com/
> (408)253-8829   MSN: [EMAIL PROTECTED]
> 

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 02:01 +, Steph wrote:
> > I'm just a php developer who didn't agree with the rules on type
> > hinting.
> 
> ... or superglobals, or multiple class inheritance rules. Why PHP? What did 
> we do? :\
> 
> More seriously (because I don't think this has a hope in hell of getting in, 
> for all the reasons Stas is trying to explain) - I'm bothered because I idly 
> went to check you out when you first turned up and couldn't find any record 
> of your existence prior to your appearance on [EMAIL PROTECTED] Even the site 
> name's booked by proxy. Are you the Brackets man?
> 

I just like PHP enough that rather than switch languages, I would like
to attempt to make PHP better. I've only been working with the PHP
source since November and I'm 19 so I haven't been around for many prior
contributions to PHP; that's probably why you haven't heard of me. I
started messing with the source and about a week later I had the type
hinting and superglobal patches done, and I joined internals.

I completely understand the disadvantages to multiple inheritance so
I've kind of dropped that, I support custom superglobals but I can
understand why they are unwanted, but scalar type hinting I think should
be in PHP. I have written all 3 of these patches but this is the one I'm
pushing for mostly. I'm using the superglobal patch for my own
development, and I have multiple inheritance working, but I don't want
to have to rewrite the patch every time php changes.

And these reasons you're talking about that Stas brought up, I don't see
any reasons besides the fact that it may confuse newcomers and it's too
"javaish". Performance is not an issue here, especially for those who
don't use type hinting. For those who don't want to use it they don't
have to because it's optional.

Any other arguments can be countered by the fact that if type hinting is
not proper in the situation, don't use it. If you want to, then use it.
Everybody wins. Plus the majority on here seems to agree with me.

Type hinting is already in PHP. It's been in PHP. Why not add a couple
of useful types? I don't see any debate here.

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 02:56 +, Steph wrote:
> > I just like PHP enough that rather than switch languages, I would like
> > to attempt to make PHP better. I've only been working with the PHP
> > source since November and I'm 19
> 
> Right, that'd explain it. It's just that usually people do a bit of PHP 
> development (websites, applications, whatever) or throw out a couple of 
> classes, or _something_ that Google can find anyways, before they start 
> telling the core PHP dev team they're doing it all wrong.

Time out. I didn't say anyone was "doing it all wrong". And I've been
developing in PHP for about 4 years. I am Zend certified and I have a
full time job developing in PHP with people twice my age and years of
experience. Not at all bragging, but I am far from the beginner who's
speaking what he doesn't know. Just because my code isn't on google
doesn't mean I haven't done any. If you want to see some stuff I've done
just let me know I will gladly send it to you.

Plus the fact that I'm obviously not stupid and I have some idea what
I'm doing if I am writing patches for the PHP core with no prior
experience.

>  so I haven't been around for many prior
> > contributions to PHP; that's probably why you haven't heard of me. I
> > started messing with the source and about a week later I had the type
> > hinting and superglobal patches done, and I joined internals.

> No, you subscribed to the internals mailing list.

Ok, wording mistake.

> 
> > I completely understand the disadvantages to multiple inheritance so
> > I've kind of dropped that, I support custom superglobals but I can
> > understand why they are unwanted, but scalar type hinting I think should
> > be in PHP. I have written all 3 of these patches but this is the one I'm
> > pushing for mostly. I'm using the superglobal patch for my own
> > development, and I have multiple inheritance working, but I don't want
> > to have to rewrite the patch every time php changes.
> 
> So far, fair enough.
> 
> > And these reasons you're talking about that Stas brought up, I don't see
> > any reasons besides the fact that it may confuse newcomers and it's too
> > "javaish".
> 
> 'It may confuse newcomers' is a big issue in PHP. Ease of takeup is the 
> mainspring of the language's design. The other point Stas made that you 
> appear to have missed is that loose typing is very much a PHP feature. It's 
> one of the things that helps make the language easy for newcomers, and it 
> also means the language is more forgiving than others. OO is a different 
> matter because you get different *types* of objects. You don't get different 
> *types* of strings, integers or floats, or at least, not to the same degree. 
> People using PHP shouldn't have to know about those differences unless they 
> really need to.
> 

Ok then. This is understood, that's why newcomers shouldn't use type
hinting. Are you saying we should hold back new features because they
might confuse beginners?

I used PHP for quite a while before using any object oriented stuff.
When I was ready, I started doing object oriented programming.

Also, I didn't say we should throw away loose typing. This is not at all
strict typing. This is optionally type hinting specified function
arguments. There is a big difference.

> Performance is not an issue here, especially for those who
> > don't use type hinting. For those who don't want to use it they don't
> > have to because it's optional.
> 
> It's optional, sure, but it's one more thing that every newbie will need to 
> be aware of before s/he can call himself a PHP developer. Every one of those 
> optional features that is added to the language is another barrier against 
> takeup.
> 

How complicated is it? Is it any worse than array type hinting? Should
we sacrifice functionality in order to make it as easy as possible to
master PHP?

Programming is hard. If you have enough intelligence to call yourself a
PHP Developer then you can surely understand the difference between an
integer and a string.

> > Any other arguments can be countered by the fact that if type hinting is
> > not proper in the situation, don't use it. If you want to, then use it.
> > Everybody wins. Plus the majority on here seems to agree with me.
> >
> > Type hinting is already in PHP. It's been in PHP. Why not add a couple
> > of useful types? I don't see any debate here.
> You, a handful of list lurkers, Jochem hanging in there for his 
> one-man-crusade (he wants to formalize PHP core development so much that 
> nobody will do it for pleasure ever again), Derick inexplicably backing you. 
> Nobody else even bothering to argue because Stas seems to be doing the job 
> fairly well all by himself right now. Johannes quite rightly won't introduce 
> type hinting for scalars without a mandate, and there doesn't appear to be 
> one right now. If it _is_ accepted it'll most likely be in PHP 6 not 5.3 
> anyway, because 5.3's features were agreed (and limited) a couple of months 
>

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 02:56 +, Steph wrote:
> > I just like PHP enough that rather than switch languages, I would like
> > to attempt to make PHP better. I've only been working with the PHP
> > source since November and I'm 19
> 
> Right, that'd explain it. It's just that usually people do a bit of PHP 
> development (websites, applications, whatever) or throw out a couple of 
> classes, or _something_ that Google can find anyways, before they start 
> telling the core PHP dev team they're doing it all wrong.

I do have one site live - www.ubuntuhcl.org. I made this quite a while
ago, not the best coding methods because this was when I had much less
experience but a fully functional site I made form scratch.

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

RE: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
> We've discussed scalar type hinting many times in the past and decided
> against it.
> It really doesn't fit in very well with PHP's loosely typed nature which
> is one of the main reasons it has been so easy to use. The only reason
> why it works with classes and arrays is because those are unambiguous
> constructs.

It doesn't fit. This is not a technical argument, this is your opinion
on the way PHP should be. That's the problem here.

> Even this thread shows that there's no alignment between people on what
> it should actually do. This is due to the lose nature of PHP. For
> example, HTTP vars come in as strings. So if you have
> http://localhost/?n=1 in your URL there are some in this thread which
> would expect it to be successfully juggled by an "int" type hint even
> though it actually comes in as a string; and some who want it to be
> ultra-strict and if the PHP type isn't an integer it should emit an
> error. What happens when you pass an object with a __toString() method
> to a function expecting a "string"? I think it should work and convert.
> I am sure some here disagree. This is exactly the problem!

We keep saying that scalar type hinting is not intended to be used for
input. Even so, if you really wanted to you could run your input through
a very simple function and convert each variable into the appropriate
type.

function typeConvert($variable) {
if (is_array($variable)) {
foreach ($variable as $k => $v) {
$variable[$k] = typeConvert($v) ;
}
}
else if (is_object($variable)) {
foreach ($variable as $k => $v) {
$variable -> $k = typeConvert($v) ;
}
}
else {
if (is_numeric($variable) and substr($variable, 0, 1) !== '0') {
if (substr_count($variable, '.')) {
$variable = (float) $variable ;
}
else {
$variable = (int) $variable ;
}
}
}

return $variable ;
}

> Saying that it won't confuse newbies is also wrong. PHP is so popular
> because it's so easy for people to pick up. Part of this also includes
> ability to look at other people's code, understand it, copy-on-write
> (e.g. a Wordpress plug-in). The more features in PHP the harder it'll be
> for developers to deal with. Yes, we bit the bullet for namespaces
> because there were strong reasons in favor of it, we as a community had
> it on our wishlist for a long time and a lot of work went into it. And
> even when we did it we had to find a way to make it work for PHP. In
> this case, with the lose typing of PHP creating a consistent model which
> will be apparent to people without many questions is a big issue.

I've said this numerous times too. How hard is it to understand? If
someone can't understand this simple concept they are sure as hell not
going to understand object oriented or anything.

Plus the fact that this is actually easier to understand than
array/object type hints.

> Also, for those who say that when this feature is not used it doesn't
> have a performance impact that is also a problematic statement. If it
> exists people will use it. Most people using PHP don't understand (and
> shouldn't have to understand) how the language is implemented. It may
> very well be that even if we could agree on the semantics we'll see all
> sorts of developers "decorate" their code with type hints (because they
> think it'll help readability) who may down the road find themselves in a
> surprise when it comes to performance.

Well that's their decision. I could use functions and not use a single
class in my applications, and they would be faster. I sacrifice a little
performance in order to make my code better.

> Last, just because something can be implemented and a patch exists
> doesn't mean it should be in PHP. There are lots of things I can
> implement for PHP which shouldn't be in PHP. Also don't under estimate
> what happens when you get bloatware and over time how much harder it
> becomes to maintain and also how it does eventually end up slowing
> things down (over time there are more branches, more code a.k.a more
> cache misses, etc...)

You are right here. But define bloatware. Type hinting is already in
PHP. All I want to do is add a couple of types to this already
implemented feature. My patch is pretty small.

> We have what I think is a very exciting PHP version coming up with 5.3.
> The featureset has been agreed upon. It'd be great if all the
> contributing energy in this thread could be channeled towards playing
> around with 5.3 esp. the new i18n extension, namespaces, help with
> migration/incompatibility notes and garbage collector benchmarks. We are
> now at the stage where we really need t

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 10:55 +, Alain Williams wrote:
> On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote:
> > Hi all,
> > 
> > As someone who has dealt with many scripts written by others as well as
> > many of my own in a large-scale project (PEAR).  I can say with absolute
> > certainty that scalar type hints would not make my job easier.
> > 
> > In fact, it would make it harder.  Many of the functions I work with
> > require varied input and almost always require some kind of validation
> > of that input.  A built-in procedure that would either end execution
> > with a fatal error or suddenly jump execution to a global error handler
> > that has no idea of the context in which the error was triggered is
> > almost as useful to me as a PHP extension that runs the pump on an
> 
> You are missing the point.
> If you want your function to take an argument of arbitrary type, then
> you simply don't give a type hint[**]
> 
> [**] I suppose that we might implement the type hint 'mixed' which would
> have the same effect as no type hint. Some people might like this from
> the 'internal documentation' point of view.

I was thinking about this, a "mixed" type hint which doesn't do
anything. Would be very easy to add.

> > Where is the increased value?  Saving a few keystrokes of validation? 
> > No.  You still need to validate the input for range, or is_numeric() or
> 
> No. The point is NOT to save input ($_GET, etc) validation -- that will
> still need to be done; the point is to help pick up programming errors
> where you accidentally get the type wrong.
> 
> Granted: some idiots will use it as cheap input validation, but it is 
> difficult
> to help some people.

Exactly. This is not intended for $_REQUEST stuff. This is intended for
internal function interaction, configuration variables, etc. All
post/get data is inputted as strings, so this doesn't apply there.

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Thu, 2008-01-03 at 15:58 -0600, Brian Moon wrote:
> I don't get it.  We already have type hinting, just not for scalars. 
> The discussion seems to be about whether or not we should have it all. 
> But, the truth is, we have it.  We half way have it.  I fought for it to 
> be all or nothing back then and I still think it is half done that we 
> don't have scalar type hinting but we have array/object/class type 
> hinting.  Talk about inconsistency.
> 
> So, can we switch the mundane conversation from "should we have type 
> hinting" to "why don't we have scalar type hinting if we have non-scalar 
> type hinting?"  That is the real conversation.  Type hinting is here. 
> It is not going anywhere.  Let's finish the job.

Yes. Atleast add a "scalar" type hint to differentiate from arrays and
objects. A scalar type hint complies with PHP's way of not
differentiating too much between strings, booleans, integers, and
floats.

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

Re: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 10:06 +0200, Tomi Kaistila wrote:
> > It really doesn't fit in very well with PHP's loosely typed nature which
> > is one of the main reasons it has been so easy to use.
> I think this is one of the cornerstones that two sides disagree the most on. 
> People are afraid that PHP would turn into a strong-typed language by 
> allowing type hinting for scalar values. I do not think this would be the 
> case. You would still have all the freedom that you have no with PHP, since 
> PHP's type juggling is still in effect.
> 
> The only thing that would change is that the validation of the data that is 
> passed into functions would be somewhat automated, but since the validation 
> occurs with or without type hinting the result is still the same. If data is 
> incorrent, an error occurs whether it is an exception, a false return type, 
> or a triggered error. The behaviour of the program does not change with type 
> hinting.

Exactly. This is not strict typing. It's type hinting (key word,
hinting).

> > Even this thread shows that there's no alignment between people on what
> > it should actually do.
> This is true, but contributed to it is that so far we have spent more time 
> and 
> energy on the silly debate whether or not type hinting is a useful feature. 
> There is enough technical proof to suggest that it is in fact a useful 
> feature.
> 
> What I would like to see is actual discussion on how it should behave and see 
> if a concensus can be derived.
> 
> > Saying that it won't confuse newbies is also wrong. PHP is so popular
> > because it's so easy for people to pick up. Part of this also includes
> > ability to look at other people's code, understand it, copy-on-write
> > (e.g. a Wordpress plug-in).
> This is an argument that I honestly do not understand. Type hinting is 
> already 
> here. It exists in PHP. How can the concept be abandoned on the bases that it 
> would confuse new users, if the concept has already been approved and 
> implemented?
> 

Exactly, array and class type hints are actually more confusing than
scalar type hints. What's more confusing to a beginner, having to pass
an instance of a certain object to a function, or having to pass a
number or string?

> 
> Tomi Kaistila
> PHP Developer
> 

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 09:52 -0600, Gregory Beaver wrote:
> Alain Williams wrote:
> > On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote:
> >   
> >> Hi all,
> >>
> >> As someone who has dealt with many scripts written by others as well as
> >> many of my own in a large-scale project (PEAR).  I can say with absolute
> >> certainty that scalar type hints would not make my job easier.
> >>
> >> In fact, it would make it harder.  Many of the functions I work with
> >> require varied input and almost always require some kind of validation
> >> of that input.  A built-in procedure that would either end execution
> >> with a fatal error or suddenly jump execution to a global error handler
> >> that has no idea of the context in which the error was triggered is
> >> almost as useful to me as a PHP extension that runs the pump on an
> >> 
> >
> > You are missing the point.
> > If you want your function to take an argument of arbitrary type, then
> > you simply don't give a type hint[**]
> >   
> But I *don't* want my functions to take an argument of arbitrary type -
> it is in fact you who are missing the point.  A type hint is a poor
> solution to a real problem that is much more easily solved via simple
> input validation and graceful error handling.  The current situation in
> PHP provides a much more flexible solution to the same problem.
> 
> Many users out there are confused about simple things like the result of
> 1 === "1" versus 1 == "1".  The fact is that scalar types are simply not
> strict enough to warrant a type hint.  An object of class X is immutable
> - you either have that or a subclass.  An array is an array, and can't
> look like anything else.  Integers, floats, strings are much more gray
> area, and much less likely to provide good, clear input to check against
> a type hint.
> 
> Also, you and many who are in favor of type hints seem to forget that
> part of PHP's strength is the ability to distribute and use code written
> by other people.  I guarantee that regardless of whether I choose to use
> type hints, someone whose code I will have to use will be using type
> hints, forcing me to deal with them.  Imagine a program uses exceptions
> for error handling, and you wish to use a library that has type hints. 
> Now, you can't catch problems using this program except via fatal error,
> or worse, an error handler that has only a backtrace from which to grab
> context.
> > [**] I suppose that we might implement the type hint 'mixed' which would
> > have the same effect as no type hint. Some people might like this from
> > the 'internal documentation' point of view.
> >
> >   
> >> Where is the increased value?  Saving a few keystrokes of validation? 
> >> No.  You still need to validate the input for range, or is_numeric() or
> >> 
> >
> > No. The point is NOT to save input ($_GET, etc) validation -- that will
> > still need to be done; the point is to help pick up programming errors
> > where you accidentally get the type wrong.
> This is just the point that appears to be lost on advocates for scalar
> type hints - this work of picking up programming errors should be
> performed in development, not in production, and type hint as warning
> does nothing to assist debugging.  In the error log, there is no
> backtrace, so all you know is that on line X in file Y invalid input was
> passed to a function.  No context, no reproduce steps, and no backtrace
> to see the logic train.

That's not true. You can easily set up your error handler to throw an
exception, which will provide a full backtrace.

And type hinting will help to catch these errors in development, rather
than finding out that all of your users have their email addresses
stored as "Array" in your database.

> Greg
> 

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 17:53 +0100, Pierre wrote:
> On Jan 4, 2008 5:53 PM, Pierre <[EMAIL PROTECTED]> wrote:
> > On Jan 4, 2008 4:52 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> >
> > > But I *don't* want my functions to take an argument of arbitrary type -
> > > it is in fact you who are missing the point.  A type hint is a poor
> > > solution to a real problem that is much more easily solved via simple
> > > input validation and graceful error handling.  The current situation in
> > > PHP provides a much more flexible solution to the same problem.
> >
> > Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use
> 
> Read: othing will prevent you to >do not< use it :)
> 

So you're saying if you don't like it just don't use it?

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 11:51 -0500, Ilia Alshanetsky wrote:
> To add another two points to Stefan's argument. Type hinting does not  
> remove the need to filter user input, but it does allow you to safe- 
> guard internal functions (library code etc...) against accidental or  
> internal misuse or improper handling of the data in the front-end  
> layer. It also makes the code far more readable and understandable not  
> the mention help doc generation tools that interrogate the code.
> 

Exactly, not input, but internal application code. For me a big thing is
configuration variables which are then used to call functions. It would
also help any other developers looking at your code (easier to
understand the purpose of arguments to a functions if it is type
hinted).

> 
> On 4-Jan-08, at 11:41 AM, Stefan Esser wrote:
> 
> > Good Morning everyone,
> >
> > one should not forget that type hinting has some clear advantages the
> > anti type hinting advocates always try to forget...
> >
> > * the code gets smaller because not so many typechecks in every  
> > function
> > * because the code gets smaller it is faster executed (userspace
> > typecheck is slower than "engine-space")
> > * without all these type checks the code gets easier to read
> > * with type hints byte code optimizer can optimize the code far better
> > -> faster execution
> > * with type hints static analysing tools that check for
> > bugs/vulnerabilities can perform far better (intra procedural analysis
> > gives more information)
> >
> > Stefan Esser
> >
> > -- 
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 
> Ilia Alshanetsky
> 

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 18:09 +0100, Pierre wrote:
> On Jan 4, 2008 6:01 PM, Sam Barrow <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2008-01-04 at 17:53 +0100, Pierre wrote:
> > > On Jan 4, 2008 5:53 PM, Pierre <[EMAIL PROTECTED]> wrote:
> > > > On Jan 4, 2008 4:52 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > But I *don't* want my functions to take an argument of arbitrary type 
> > > > > -
> > > > > it is in fact you who are missing the point.  A type hint is a poor
> > > > > solution to a real problem that is much more easily solved via simple
> > > > > input validation and graceful error handling.  The current situation 
> > > > > in
> > > > > PHP provides a much more flexible solution to the same problem.
> > > >
> > > > Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use
> > >
> > > Read: othing will prevent you to >do not< use it :)
> > >
> >
> > So you're saying if you don't like it just don't use it?
> 
> Yes, that's the meaning of "optional" I suppose :)
> 
> My idea about it (I did not test the patch, so correct me if I
> misunderstood the proposal) was to leave the default as it is now:
> 
> function($a) > what Greg likes to always use ;)
> function(mixed $a) > little syntax sugar, same as the previous one
> function(int $a)
> etc.
> 

Exactly. I just added the "mixed" type hint which is the same as using
no type hint. The new patch is attached.

Extra keywords (real, long, double, etc.) have been taken out. The
available type hints are now mixed, int, float, bool, string, scalar,
num, resource, and object. And of course array and class type hints
still work.

Index: Zend/zend_API.h
===
RCS file: /repository/ZendEngine2/zend_API.h,v
retrieving revision 1.207.2.8.2.8.2.6
diff -u -r1.207.2.8.2.8.2.6 zend_API.h
--- Zend/zend_API.h	31 Dec 2007 07:17:04 -	1.207.2.8.2.8.2.6
+++ Zend/zend_API.h	4 Jan 2008 15:22:11 -
@@ -69,7 +69,7 @@
 #define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name, sizeof(#name)-1, NULL, 0, 1, allow_null, pass_by_ref, 0, 0 },
 #define ZEND_BEGIN_ARG_INFO_EX(name, pass_rest_by_reference, return_reference, required_num_args)	\
 	const zend_arg_info name[] = {		\
-		{ NULL, 0, NULL, 0, 0, 0, pass_rest_by_reference, return_reference, required_num_args },
+		{ NULL, 0, NULL, 0, 0, 0, pass_rest_by_reference, return_reference, required_num_args, 0, 0, 0 },
 #define ZEND_BEGIN_ARG_INFO(name, pass_rest_by_reference)	\
 	ZEND_BEGIN_ARG_INFO_EX(name, pass_rest_by_reference, ZEND_RETURN_VALUE, -1)
 #define ZEND_END_ARG_INFO()		};
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.35
diff -u -r1.647.2.27.2.41.2.35 zend_compile.c
--- Zend/zend_compile.c	31 Dec 2007 07:17:04 -	1.647.2.27.2.41.2.35
+++ Zend/zend_compile.c	4 Jan 2008 15:22:11 -
@@ -1372,26 +1372,42 @@
 	cur_arg_info->pass_by_reference = pass_by_reference;
 	cur_arg_info->class_name = NULL;
 	cur_arg_info->class_name_len = 0;
+ 	cur_arg_info->scalar_type_hint = 0;
+ 	cur_arg_info->number_type_hint = 0;
+ 	cur_arg_info->type_hint = 0;
 
 	if (class_type->op_type != IS_UNUSED) {
-		cur_arg_info->allow_null = 0;
 		if (class_type->u.constant.type == IS_STRING) {
-			if (ZEND_FETCH_CLASS_DEFAULT == zend_get_class_fetch_type(Z_STRVAL(class_type->u.constant), Z_STRLEN(class_type->u.constant))) {
-zend_resolve_class_name(class_type, &opline->extended_value, 1 TSRMLS_CC);
-			}
-			cur_arg_info->class_name = class_type->u.constant.value.str.val;
-			cur_arg_info->class_name_len = class_type->u.constant.value.str.len;
-			if (op == ZEND_RECV_INIT) {
-if (Z_TYPE(initialization->u.constant) == IS_NULL || (Z_TYPE(initialization->u.constant) == IS_CONSTANT && !strcasecmp(Z_STRVAL(initialization->u.constant), "NULL"))) {
-	cur_arg_info->allow_null = 1;
-} else {
-	zend_error(E_COMPILE_ERROR, "Default value for parameters with a class type hint can only be NULL");
+ 			if (strcasecmp("scalar", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->scalar_type_hint = 1;
+ 			} else if (strcasecmp("num", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->number_type_hint = 1;
+ 			} else if (strcasecmp("int", class_type->u.constant.value.str.val) == 0) {
+ cur_arg_info->type_hint = IS_LONG;
+ 			} else if (strcasecmp("float", class_type->u.constant

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 09:52 -0600, Gregory Beaver wrote:
> Alain Williams wrote:
> > On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote:
> >   
> >> Hi all,
> >>
> >> As someone who has dealt with many scripts written by others as well as
> >> many of my own in a large-scale project (PEAR).  I can say with absolute
> >> certainty that scalar type hints would not make my job easier.
> >>
> >> In fact, it would make it harder.  Many of the functions I work with
> >> require varied input and almost always require some kind of validation
> >> of that input.  A built-in procedure that would either end execution
> >> with a fatal error or suddenly jump execution to a global error handler
> >> that has no idea of the context in which the error was triggered is
> >> almost as useful to me as a PHP extension that runs the pump on an
> >> 
> >
> > You are missing the point.
> > If you want your function to take an argument of arbitrary type, then
> > you simply don't give a type hint[**]
> >   
> But I *don't* want my functions to take an argument of arbitrary type -
> it is in fact you who are missing the point.  A type hint is a poor
> solution to a real problem that is much more easily solved via simple
> input validation and graceful error handling.  The current situation in
> PHP provides a much more flexible solution to the same problem.
> 

Are you suggesting that if a function requires an integer, string, and
object, we use is_int, is_string, and is_object to trigger errors? What
if we have 50 functions like this?

With type hinting:

function a(int $a, string $b, object $c) {

}

Without type hinting:

function a($a, $b, $c) {
if (!is_int($a)) {
trigger_error(E_WHATEVER, 'Argument 1 to function a() must be an
integer.') ;
}
if (!is_string($b)) {
trigger_error(E_WHATEVER, 'Argument 2 to function a() must be an
integer.') ;
}
if (!is_object($c)) {
trigger_error(E_WHATEVER, 'Argument 3 to function a() must be an
integer.') ;
}
}

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 17:41 +0100, Stefan Esser wrote:
> Good Morning everyone,
> 
> one should not forget that type hinting has some clear advantages the
> anti type hinting advocates always try to forget...
> 
> * the code gets smaller because not so many typechecks in every function

True.

> * because the code gets smaller it is faster executed (userspace
> typecheck is slower than "engine-space")

Very true, type hinting would be many times faster than using is_int,
etc. which puts to rest any argument that type hinting will be bad for
performance.

> * without all these type checks the code gets easier to read

Yes, more concise and compact without manual type checking.

> * with type hints byte code optimizer can optimize the code far better
> -> faster execution
> * with type hints static analysing tools that check for
> bugs/vulnerabilities can perform far better (intra procedural analysis
> gives more information)

Also true. Applications like PHPDocumentor could make good use of scalar
type hints.

> 
> Stefan Esser
> 

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 12:48 -0500, Robert Cummings wrote:
> On Fri, 2008-01-04 at 12:41 -0500, Sam Barrow wrote:
> > On Fri, 2008-01-04 at 12:37 -0500, Robert Cummings wrote:
> > > On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
> > > > On Jan 4, 2008 6:20 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> > > > > Hello Pierre,
> > > > >
> > > > >   we never accepted this as a pro argument. Infact we often saw the
> > > > > necessaity to highlight something is optional to vote against it. We 
> > > > > do this
> > > > > for a reason. That is we only want to support mainstream features.
> > > > 
> > > > My point of view is that this feature should be a mainstream feature.
> > > > To make it optional was to lower the issues for those who don't care
> > > > about argument strictness. We did not give them this choice for the OO
> > > > strictness.
> > > 
> > > IMHO, optionally inclusion of type hinting for functions/methods can
> > > only be a boon to code quality and readability. IMHO when a type hint is
> > > provided and a parameter doesn't match the type hint then I think a
> > > fatal error should occur. This forces the user of the function that has
> > > type hinting to ensure their data is of the correct type. This prevents
> > > accidental wrong data conversion. However, I see the other side of the
> > > coin too where automatic type conversion could be desirable also.
> > > Perhaps a mixed solution would be viable?
> > > 
> > 
> > I don't think conversion would make sense here, as PHP will
> > automatically convert the variable before you use it anyway. Hinting
> > will prevent mistakes, conversion will just try to ignore them, which is
> > what PHP does already.
> 
> I think that depends on what I do with the variable. PHP doesn't know
> how I intend to use it, and if I know I want an int and I don't want to
> test for browserland garbage in my variable everytime the function is
> called, then an automatic type conversion to int for my function can
> make perfect sense. Yes, I could force the developer using my function
> to cast the parameter as an int, but I'm certain conversion in the
> engine without a userland cast is faster, and it makes it more
> convenient to the consumer of my function since they can still treat it
> like a classic function.

Yes, but whatever you do with it (echo, store in db, etc.) PHP will
perform its default conversion routine for the variable type. You have a
point though, this is something that I've actually been debating for
some time:

function a(int $a, cast int $b) {

}

$a must be an int
$b will be cast to an int

I just think this is getting a little bit too complicated. Many people
on here are resistant enough to scalar type hinting because they say
it's confusing, they'll definitely be even more resistant to something
like this.

> Cheers,
> Rob.

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 12:37 -0500, Robert Cummings wrote:
> On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
> > On Jan 4, 2008 6:20 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> > > Hello Pierre,
> > >
> > >   we never accepted this as a pro argument. Infact we often saw the
> > > necessaity to highlight something is optional to vote against it. We do 
> > > this
> > > for a reason. That is we only want to support mainstream features.
> > 
> > My point of view is that this feature should be a mainstream feature.
> > To make it optional was to lower the issues for those who don't care
> > about argument strictness. We did not give them this choice for the OO
> > strictness.
> 
> IMHO, optionally inclusion of type hinting for functions/methods can
> only be a boon to code quality and readability. IMHO when a type hint is
> provided and a parameter doesn't match the type hint then I think a
> fatal error should occur. This forces the user of the function that has
> type hinting to ensure their data is of the correct type. This prevents
> accidental wrong data conversion. However, I see the other side of the
> coin too where automatic type conversion could be desirable also.
> Perhaps a mixed solution would be viable?
> 

I don't think conversion would make sense here, as PHP will
automatically convert the variable before you use it anyway. Hinting
will prevent mistakes, conversion will just try to ignore them, which is
what PHP does already.

>  
> function foo( require int $a, require string $b ){}
> 
> foo( '5', 'bleh' );  // <-- fatal error
> 
> ?>
> 
> Contrast versus:
> 
>  
> function foo( int $a, string $b ){}
> 
> foo( '5', 'bleh' );  // <-- no exception or error $a in foo() will
>  // be type int (automatic conversion)
> 
> ?>
> 
> Versus (still allowed default style):
> 
>  
> function foo( $a, $b ){}
> 
> foo( '5', 'bleh' );  // <-- no exceptions or type conversions
> 
> ?>
> 
> Thoughts?
> 
> Cheers,
> Rob.
> -- 
> ...
> SwarmBuy.com - http://www.swarmbuy.com
> 
> Leveraging the buying power of the masses!
> ...
> 

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 17:51 +, Alain Williams wrote:
> On Fri, Jan 04, 2008 at 12:37:19PM -0500, Robert Cummings wrote:
> 
> > IMHO, optionally inclusion of type hinting for functions/methods can
> > only be a boon to code quality and readability. IMHO when a type hint is
> > provided and a parameter doesn't match the type hint then I think a
> > fatal error should occur. This forces the user of the function that has
> > type hinting to ensure their data is of the correct type. This prevents
> > accidental wrong data conversion. However, I see the other side of the
> > coin too where automatic type conversion could be desirable also.
> > Perhaps a mixed solution would be viable?
> > 
> >  > 
> > function foo( require int $a, require string $b ){}
> > 
> > foo( '5', 'bleh' );  // <-- fatal error
> 
> No.
> 
> > ?>
> > 
> > Contrast versus:
> > 
> >  > 
> > function foo( int $a, string $b ){}
> > 
> > foo( '5', 'bleh' );  // <-- no exception or error $a in foo() will
> >  // be type int (automatic conversion)
> 
> Yes. If $a is '5' but reject if $a is '5five'.

This is what I was considering, but to do something like this we will
have to implement a whole separate rule set just for type hint
conversion.

> > ?>
> > 
> > Versus (still allowed default style):
> > 
> >  > 
> > function foo( $a, $b ){}
> > 
> > foo( '5', 'bleh' );  // <-- no exceptions or type conversions
> > 
> > ?>
> > 
> > Thoughts?
> > 
> > Cheers,
> > Rob.
> > -- 
> > ...
> > SwarmBuy.com - http://www.swarmbuy.com
> > 
> > Leveraging the buying power of the masses!
> > ...
> 
> -- 
> Alain Williams
> Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT 
> Lecturer.
> +44 (0) 787 668 0256  http://www.phcomp.co.uk/
> Parliament Hill Computers Ltd. Registration Information: 
> http://www.phcomp.co.uk/contact.php
> Chairman of UKUUG: http://www.ukuug.org/
> #include 
> 

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 17:46 +, Alain Williams wrote:
> On Fri, Jan 04, 2008 at 12:11:41PM -0500, Sam Barrow wrote:
> 
> > Exactly. I just added the "mixed" type hint which is the same as using
> > no type hint. The new patch is attached.
> > 
> > Extra keywords (real, long, double, etc.) have been taken out. The
> > available type hints are now mixed, int, float, bool, string, scalar,
> > num, resource, and object. And of course array and class type hints
> > still work.
> 
> I notice that you use strcasecmp() to compare type name. I thought that we 
> were moving
> away from case independence, ie the type should be 'int' or perhaps 'INT' - 
> whatever
> we agree on it should have a defined capitalisation.

Oh ok. Well I assumed it would be case sensitive like variables but you
do have a point, many keywords in PHP are not case sensitive. This is
something that can be easily changed depending on what people want.

> Just an off the wall thought ... if the type is not a known scalar type or 
> class, then check to see if the
> word is a constant ... could be interesting  aka C's typedefs.
> 

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 13:22 -0500, Ilia Alshanetsky wrote:
> On 4-Jan-08, at 1:20 PM, Stanislav Malyshev wrote:
> 
> >> layer. It also makes the code far more readable and understandable  
> >> not the mention help doc generation tools that interrogate the code.
> >
> > I was under impression that it is good manners to actually document  
> > your code and not rely on the tools to "interrogate" your code. Of  
> > course, not everybody has good style, but I don't see much value in  
> > changing language so that people writing in bad style would feel  
> > more comfortable.
> 

Well it would be much easier to type hint than to manually document
every one of your function parameters.

> If you can offload type documentation you can make better use of your  
> time documenting the logic of the code, there is something to be said  
> about self documenting code especially when doing things like WSDL  
> generation.

Very good point.

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

RE: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 10:37 -0800, Andi Gutmans wrote:
> I think the "mixed" identifier is a minor issue but I also don't see
> it's purpose. If you don't want type hinting then don't write a type
> hint. It's also tool friendly...
> Andi

It is kind of pointless, just syntactic sugar to be honest. Not a big
deal at all though. I'd like it as I said for the syntactic sugar but
personally I don't care too much.

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 10:28 -0800, Stanislav Malyshev wrote:
> > Exactly. I just added the "mixed" type hint which is the same as using
> > no type hint. The new patch is attached.
> 
> IMO adding new type hint for the sole purpose of having some string next 
> to the variable is just silly. If you need documentation, use documentation.
> 
> > Extra keywords (real, long, double, etc.) have been taken out. The
> > available type hints are now mixed, int, float, bool, string, scalar,
> > num, resource, and object. And of course array and class type hints
> 
> Do you realize that hinting variable as "object" or "resource" has no 
> meaning, since resources and objects are not interchangeable and you 
> never want just "object" or "resource" - you want object of particular 
> class and resource of particular type?

Not necessarily, if you have a function that performs a generic
operation on any object. As for resources you are right, it might be
ideal to have "mysql resource" rather than just "resource", but just
having the "resource" type hint is better than having no type hint.

> Also, what use case might there be for "scalar"?

This is one that I find very useful, much more than it may seem. I use
scalar for any type of post/get input, printed output, or DB
interaction, as objects/arrays/resources cannot be printed or stored in
a database in a standardized way.

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 10:59 -0800, Stanislav Malyshev wrote:
> > Not necessarily, if you have a function that performs a generic
> > operation on any object. As for resources you are right, it might be
> 
> Like what? I don't know many operations that are good for any object and 
> only object and need special function to perform them. Actually, 
> excluding scenarios like serialization and RPC (which should take care 
> of other types too so irrelevant here) I can't think of any right now.
> > ideal to have "mysql resource" rather than just "resource", but just
> > having the "resource" type hint is better than having no type hint.
> 
> No, it's not better. Having GD image instead of mysql connection is not 
> better than having integer in any way. It would just produce different 
> error message, so what?

That's actually very true.

> > This is one that I find very useful, much more than it may seem. I use
> > scalar for any type of post/get input, printed output, or DB
> > interaction, as objects/arrays/resources cannot be printed or stored in
> > a database in a standardized way.
> 
> If you need serialization/printing, you have serialize() and 
> __toString() with respective handlers. If you reimplementing them and 
> using scalar restrictions, you most probably do it wrong.

Ok but if someone inputs an array in the query string i have a problem
with that. And I said standardized way, ie bool true outputs as "1",
float 5.20 outputs as "5.2". For objects, toString is a standardized
output but serialization is not, and for arrays no standardized output
exists.

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 11:26 -0800, Stanislav Malyshev wrote:
> > A language that can be used for large scale applications, with tons of
> > extensions for integration with many third party applications and
> > protocols. PHP is no longer a form submitter/emailer.
> 
> Hey, you are right, it isn't! It is actually used right now for "large 
> scale applications, with tons of extensions for integration with many 
> third party applications".
> 
> > Ok... You said that nobody wanted this feature. I'm saying how do you
> 
> I didn't. I said everybody was fine without this feature. It's 
> different. I may "want" to have a BMW 335i convertible (especially if 
> somebody donates it to me for free :), but I'm doing fine without it and 
> do not plan to spend money on buying one soon. :)

Good point. We were fine before OO and exceptions too weren't we.

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 11:20 -0800, Stanislav Malyshev wrote:
> > Ok but if someone inputs an array in the query string i have a problem
> 
> Which problem? OK, you'd have string "Array" instead once you handle it. 
> If it's a problem, then having "Array" from the start is a problem too.

Yes, and the type hint will catch this problem in a second.

>  > with that. And I said standardized way, ie bool true outputs as "1",
> > float 5.20 outputs as "5.2". For objects, toString is a standardized
> > output but serialization is not, and for arrays no standardized output
> > exists.
> 
> Object serialization is very standardized, it has proper handlers, etc. 
> As for outputting arrays, indeed, 'Array' is not very meaningful, but 
> would "Incompatible type is call in function foo() /foo/bar.php line 
> 123" be better?

Yes it would. Because the developer would fix the error upon seeing an
error message like that, and avoid the entire future problem. Do you
suggest letting the bug go unnoticed until it causes real damage?

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

RE: [PHP-DEV] RE: Optional scalar type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 10:08 -0800, Andi Gutmans wrote:
> See below:
> 
> > -Original Message-
> > From: Sam Barrow [mailto:[EMAIL PROTECTED]
> > Sent: Friday, January 04, 2008 5:47 AM
> > To: Andi Gutmans
> > Cc: internals@lists.php.net
> > Subject: RE: [PHP-DEV] RE: Optional scalar type hinting
> > 
> > On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
> > > We've discussed scalar type hinting many times in the past and
> > decided
> > > against it.
> > > It really doesn't fit in very well with PHP's loosely typed nature
> > which
> > > is one of the main reasons it has been so easy to use. The only
> > reason
> > > why it works with classes and arrays is because those are
> unambiguous
> > > constructs.
> > 
> > It doesn't fit. This is not a technical argument, this is your opinion
> > on the way PHP should be. That's the problem here.
> 
> Are you saying that languages are designed only based on technicalities?
> So why are languages so different? Each language has a spirit and an
> emphasis and this is definitely something to think about. It also
> relates to what the applicable market and users are.

True. I'm saying that this is being taken too far in this case. PHP with
type hinting is still PHP, I am not asking to redesign the entire
structure of the language.

> -snip-
> 
> So why don't we first see if people can agree on what this does:
> 
> I think all the following ones should work:
> 
> function iwantint(int $n) {
> iwantint("1");// "1" + 1 works great.
> 
> function iwantstring(string $str) {}
> iwantstring($toStringObject); // Works in strcmp()
> 
> function iwantfloat(float $f) {}
> iwantfloat(2);
> 
> function iwantbool(bool $b) {}
> iwantbool(1);
> 
> function iwantnull(null $n) {}
> iwantnull(null);  //Does this exist?

Null hint does not exist, as null is only one value and it would be
pointless.

I've stated my opinion on this, I'm going for standard hinting. Int
means int, not "1" or "one" or "1one". Bool means boolean true or false,
not "true", 1, 0, "0", etc.

> 
> And for consistency of the language we would be using PHP's type
> juggling system to see if there's a match or not and you'd get whatever
> results you get today.
> 
> Btw I think there's absolutely no argument that the error should be
> exactly the same as with array/class hints. No way are we going to have
> two different errors for the same kind of functionality. That's
> ludicrous.

Errors should all be the same for any type hint.

> More below:...
> 
> > > Saying that it won't confuse newbies is also wrong. PHP is so
> popular
> > > because it's so easy for people to pick up. Part of this also
> > includes
> > > ability to look at other people's code, understand it, copy-on-write
> > > (e.g. a Wordpress plug-in). The more features in PHP the harder
> it'll
> > be
> > > for developers to deal with. Yes, we bit the bullet for namespaces
> > > because there were strong reasons in favor of it, we as a community
> > had
> > > it on our wishlist for a long time and a lot of work went into it.
> > And
> > > even when we did it we had to find a way to make it work for PHP. In
> > > this case, with the lose typing of PHP creating a consistent model
> > which
> > > will be apparent to people without many questions is a big issue.
> > 
> > I've said this numerous times too. How hard is it to understand? If
> > someone can't understand this simple concept they are sure as hell not
> > going to understand object oriented or anything.
> 
> There are actually a lot of PHP developers who don't do OO oriented.
> This is why we left it as a choice to developers (it's been around btw
> since 1997 at least the basic OO functionality).

OK. And they're not using OO right? So tell them not to use type hinting
either!

> Anyway what's confusing here are the semantics not the feature itself.
> For example, I expect something different than you do.
> 
> > Plus the fact that this is actually easier to understand than
> > array/object type hints.
> 
> I don't think so because there's no potential type juggling in those
> (which is why we did it) but it's a pointless argument because it
> doesn't add much value to the discussion.

You have a point, but it is still a very simple concept.

> > > Also, for those who say that when this featur

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 13:02 -0500, Robert Cummings wrote:
> On Fri, 2008-01-04 at 12:51 -0500, Sam Barrow wrote:
> > On Fri, 2008-01-04 at 12:48 -0500, Robert Cummings wrote:
> > > On Fri, 2008-01-04 at 12:41 -0500, Sam Barrow wrote:
> > > > On Fri, 2008-01-04 at 12:37 -0500, Robert Cummings wrote:
> > > > > On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
> > > > > > On Jan 4, 2008 6:20 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> > > > > > > Hello Pierre,
> > > > > > >
> > > > > > >   we never accepted this as a pro argument. Infact we often saw 
> > > > > > > the
> > > > > > > necessaity to highlight something is optional to vote against it. 
> > > > > > > We do this
> > > > > > > for a reason. That is we only want to support mainstream features.
> > > > > > 
> > > > > > My point of view is that this feature should be a mainstream 
> > > > > > feature.
> > > > > > To make it optional was to lower the issues for those who don't care
> > > > > > about argument strictness. We did not give them this choice for the 
> > > > > > OO
> > > > > > strictness.
> > > > > 
> > > > > IMHO, optionally inclusion of type hinting for functions/methods can
> > > > > only be a boon to code quality and readability. IMHO when a type hint 
> > > > > is
> > > > > provided and a parameter doesn't match the type hint then I think a
> > > > > fatal error should occur. This forces the user of the function that 
> > > > > has
> > > > > type hinting to ensure their data is of the correct type. This 
> > > > > prevents
> > > > > accidental wrong data conversion. However, I see the other side of the
> > > > > coin too where automatic type conversion could be desirable also.
> > > > > Perhaps a mixed solution would be viable?
> > > > > 
> > > > 
> > > > I don't think conversion would make sense here, as PHP will
> > > > automatically convert the variable before you use it anyway. Hinting
> > > > will prevent mistakes, conversion will just try to ignore them, which is
> > > > what PHP does already.
> > > 
> > > I think that depends on what I do with the variable. PHP doesn't know
> > > how I intend to use it, and if I know I want an int and I don't want to
> > > test for browserland garbage in my variable everytime the function is
> > > called, then an automatic type conversion to int for my function can
> > > make perfect sense. Yes, I could force the developer using my function
> > > to cast the parameter as an int, but I'm certain conversion in the
> > > engine without a userland cast is faster, and it makes it more
> > > convenient to the consumer of my function since they can still treat it
> > > like a classic function.
> > 
> > Yes, but whatever you do with it (echo, store in db, etc.) PHP will
> > perform its default conversion routine for the variable type. You have a
> > point though, this is something that I've actually been debating for
> > some time:
> > 
> > function a(int $a, cast int $b) {
> > 
> > }
> > 
> > $a must be an int
> > $b will be cast to an int
> 
> Yes, that makes more sense since it brings things in line with the
> current semantics for array/object type hinting.
> 
> > I just think this is getting a little bit too complicated. Many people
> > on here are resistant enough to scalar type hinting because they say
> > it's confusing, they'll definitely be even more resistant to something
> > like this.
> 
> It's funny sometimes the complaints about too complicated. I mean, if
> people don't want to use a "complicated feature" then they shouldn't. I
> don't think cutting the legs out from developers who want to use said
> features is the solution. I mean we're all programmers around here... is
> it really that complicated? Required paraneter types, automatic
> parameter casting, and ad-hoc paramets types? :)

I agree with you 100% here, I just don't think the PHP development team
is going to be wiling to implement it, since they are very big on
keeping it easy for beginners. I agree with you 100% though, I'm just
saying that in the situation it's probably not going to happen.

> Cheers,
> Rob.

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 11:01 -0800, Stanislav Malyshev wrote:
> > Well PHP is changing into an enterprise-level language now. Out with the
> 
> What is "enterprise-level language"?
> 

A language that can be used for large scale applications, with tons of
extensions for integration with many third party applications and
protocols. PHP is no longer a form submitter/emailer.

> > old, in with the new. And I'm sure there were some developers who did
> > want this feature but didn't necessarily say anything.
> 
> So what? There are developers that don't want this feature and didn't 
> say anything.

Ok... You said that nobody wanted this feature. I'm saying how do you
know that, I'm sure there are some people that did.

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

Re: [PHP-DEV] type hinting

[Sam Barrow]

On Fri, 2008-01-04 at 11:04 -0800, Stanislav Malyshev wrote:
> > Well it would be much easier to type hint than to manually document
> > every one of your function parameters.
> 
> How is this:
> 
> /* @param $client string Contains the name of the client for the account
> 
> is worse or less clear or harder to write that this:
> 
> processAccount(string $client)
> 
> Note that unless you write the former you code is still undocumented and 
> knowing it's a string won't help you much.

About the same, but the @param comment doesn't stop someone from putting
an array into $client.

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