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
calar 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
>
>
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,
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
0 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/m
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:
> >
> >
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 w
t;
> > 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 m
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
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,
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 a
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
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
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.
>
&g
eave 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
> >
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 le
t 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 B
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/unsu
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 c
perglobal 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:
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 k
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,
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 wo
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 retur
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 dyna
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 t
t "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
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
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. No
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.
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&#
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 M
totype
> 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
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
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() {
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 namespa
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
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 worrie
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
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 ide
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 feat
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 namesp
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::
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-wo
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.
P
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 na
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 d
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
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 Inter
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 br
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 onl
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
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
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 fun
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 desig
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
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
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
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_FAT
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, D
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.
-
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 backw
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
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
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
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 bel
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, a
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) a
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 con
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($myn
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 interac
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 o
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 sc
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 getti
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 bi
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 bi
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
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
> > ce
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
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 PH
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 (PE
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 missin
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
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
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 (PE
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.
> *
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, Ma
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
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 par
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
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
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.
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
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
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!
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
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
> > Subje
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:3
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 p
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
1 - 100 of 254 matches
Mail list logo
