Hi,
This does not seem like a good way for me ...
Think about combining many scripts.
It's for example quite usual to use Symfony and parts of Zend Framework
together. Think about what will happen if the one framework uses another
autocast logic ...
Bye
Simon
2012/2/27 Anthony Ferrara
> I fai
I'll try to find some time tonight to create that for ya.
Once this discussion comes together a little bit more and we have at least
a vague-ish idea what direction we're moving in, I'll also go ahead and
create an RFC as well so we have a conceptual product to build on.
--Kris
On Sun, Feb 26,
I fail to see how you would do it via a register function... Unless
you mean a call-chain of callbacks to try to "cast" with a "from" and
a "to" parameter:
spl_autocast_register(function($from, $to) {
if ($to == 'Integer') {
return new Integer((int) $from);
}
});
That could have
> Or operator-overlading to the rescue? :-)
Not quite. Especially because with operator overloading done at this
level (how it would be implemented in PHP) it's almost impossible to
make it consistent:
class string {
public function overload+($mixed) {
return $this->value + $mixed;
Hi,
I create a new thread to discuss about Scalar type hinting.
Following the John Crenshaw proposed terminology:
> - "Strict Typing" means the super strict old C style typing that has been
proven to be ridiculous in this environment because of the obvious problems
inherent in the fact that almos
+1 as well,
I start a new thread for that.
This debate is major for PHP's futur.
I'm little frustrated about this thread,
I don't have any new argument for or against the enum proposal.
2012/2/27 Clint M Priest
> +1 for that as well.
>
> -Original Message-
> From: Kris Craig [mailto:
+1 for that as well.
-Original Message-
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Sunday, February 26, 2012 7:48 PM
To: John Crenshaw
Cc: Arvids Godjuks; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
Well said, John! I think that's a terrifi
Well said, John! I think that's a terrific idea!
--Kris
On Sun, Feb 26, 2012 at 5:44 PM, John Crenshaw wrote:
> > From: Kris Craig [mailto:kris.cr...@gmail.com]
> >
> > I actually agree as well. Looking back in the thread, I think my overly
> > broad use of the word "strict" might have led to
> From: Kris Craig [mailto:kris.cr...@gmail.com]
>
> I actually agree as well. Looking back in the thread, I think my overly
> broad use of the word "strict" might have led to some confusion over what
> I'm advocating.
Honestly, this is the biggest problem that the typing debates have had. Some
Ok, I've updated the RFC based on input received here. I also made a
decision on the APXS vs. APXS2 question; please refer to the RFC for
details. If anybody has any objections to this decision, now would be the
time to say something!
I've targetted this for 5.4.1 so this won't have any bearing
So long as that release note clarifies that this patch has NOT yet gone
through the QA cycle and that, therefore, you use it at your own risk; then
I have no objection to that approach.
--Kris
On Sun, Feb 26, 2012 at 5:12 PM, Adam Harvey wrote:
> On 25 February 2012 04:02, Gustavo Lopes wrote
On 25 February 2012 04:02, Gustavo Lopes wrote:
> On Fri, 24 Feb 2012 20:57:50 +0100, Stas Malyshev
> wrote:
>
>>> If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
>>> included? This would reduce any negative user sentiment that "PHP 5.4
>>> doesn't even support the latest
Exactly, hence why I'm still on the fence with that. I was hoping for some
further discussion though to see if anyone can think of a way around that,
though admittedly nothing comes to my mind.
--Kris
2012/2/26 Tom Boutell
> There's no such thing as optional global anything, if you're a libra
There's no such thing as optional global anything, if you're a library
or framework developer who has to cope with what's turned on wherever
their code may wind up.
On Sun, Feb 26, 2012 at 7:30 PM, Kris Craig wrote:
> I actually agree as well. Looking back in the thread, I think my overly
> broa
I actually agree as well. Looking back in the thread, I think my overly
broad use of the word "strict" might have led to some confusion over what
I'm advocating. So to clarify, I'm referring to optional non-dynamic
typing vs purely dynamic typing as we have now. Strict typing would
require some
I absolutely agree with this. The hurdle with the strict type hinting is
pictured very well. Strict is strict - either the whole codebase follows
it, or it doesn't follow it at all. If a part of the code uses it - means
all the code comunicating with that part has to use, or at least has to be
writ
[trim]
> 2. "Strict type hinting would eliminate PHP's flexibility and take away its
> unique simplicity."
>
> I respectfully disagree. Again, let me remind you that we are *not*
> talking
> about *converting *PHP to strict type hinting. Instead, we're merely
> talking about allowing PHP develop
On 02/26/2012 07:43 PM, Tom Boutell wrote:
> If what I did is basically already in 5.4 and won't be finding its
> way back to 5.3, I guess I'm good with my hack for now.
Interesting, I never noticed it, but I tried your exact configure
switches and I was able to reproduce it. Here is what I use on
I like it, at least from a raw conceptual standpoint. I think you might be
on to something here, though I'd need to take some time to deliberate on it
in more detail. But my initial gut reaction is that this would at very
least be a step in the right direction. =)
--Kris
On Sun, Feb 26, 2012
Bleh well that's just semantics. Strict typing / type hinting is what I'm
talking about; not specifically advocating one or the other.
And yeah this started as an enum proposal, but it came back to this issue.
I offered to move this to a separate topic but everyone seems content to
just keep tal
I just realised that if it were going to add magic casting, it could as well
be done with a spl_autocast_register(), so that you could either cast things
when they match, throw an exception, etc. (there should be some default
value dynamic typing, so the perfomance wouldn't hurt) .
I don't think
On 26/02/12 05:11, Arvids Godjuks wrote:
> Kris Craig
>
> I usually just read the list, sometimes add if I have something to say and
> I had voiced my opinion on typehinting before. And you know, just from the
> stand of a userland developer who has 7-8 years of experience and devoting
> myself to
On 26/02/12 15:57, Anthony Ferrara wrote:
> I've gone back and re-read a bunch of the old posts on Type Hinting,
> and have come to the conclusion that it won't be done any time soon.
> Not because it doesn't have merit, but because there are at least a
> few fundamental difficulties that are non-t
If what I did is basically already in 5.4 and won't be finding its way
back to 5.3, I guess I'm good with my hack for now.
What component are you suggesting I build shared?
On Sun, Feb 26, 2012 at 2:39 PM, Hannes Magnusson
wrote:
> On Sun, Feb 26, 2012 at 20:34, Tom Boutell wrote:
>> Hmm.
>>
>>
On Sun, Feb 26, 2012 at 20:34, Tom Boutell wrote:
> Hmm.
>
> Here is my apt-get install line, starting from a stock install of
> 11.10 in virtualbox:
>
> apt-get -y install build-essential apache2 libxml2-dev libcurl4-openssl-dev \
> libcurl4-openssl-dev libjpeg-dev libpng-dev libfreetype6-dev li
Hmm.
Here is my apt-get install line, starting from a stock install of
11.10 in virtualbox:
apt-get -y install build-essential apache2 libxml2-dev libcurl4-openssl-dev \
libcurl4-openssl-dev libjpeg-dev libpng-dev libfreetype6-dev libicu-dev \
libmcrypt-dev mysql-server mysql-client libmysqlc
On 02/26/2012 07:19 PM, Tom Boutell wrote:
> Bump - this is still a live issue on Ubuntu 11.10, for instance.
>
> I just hacked my Ubuntu PHP-from-source installer to touch up the
> Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job.
>
> Which I knew more about autoconf, I'd like to
Bump - this is still a live issue on Ubuntu 11.10, for instance.
I just hacked my Ubuntu PHP-from-source installer to touch up the
Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job.
Which I knew more about autoconf, I'd like to help figure this out
properly so everyone doesn't wind
On 02/26/2012 04:48 PM, Anthony Ferrara wrote:
>> I have to say, it doesn't get work, thinking this:
>>
>> $mixed1 = new Interger(2);
>> $mixed2 = new Interge(3);
>> $guess_what_type_is = $mixed1 + $mixed2;
>>
>> thanks
>
> That one is actually pretty straight forward. Since `+` is a numeric
> op
On Sun, 26 Feb 2012 16:39:10 +0100, Laruence wrote:
On Sun, Feb 26, 2012 at 10:57 PM, Anthony Ferrara
wrote:
I have to say, it doesn't get work, thinking this:
$mixed1 = new Interger(2);
$mixed2 = new Interge(3);
$guess_what_type_is = $mixed1 + $mixed2;
Actually, this part of the proble
> I have to say, it doesn't get work, thinking this:
>
> $mixed1 = new Interger(2);
> $mixed2 = new Interge(3);
> $guess_what_type_is = $mixed1 + $mixed2;
>
> thanks
That one is actually pretty straight forward. Since `+` is a numeric
operation (with the one exception of array + array), it would
On Sun, Feb 26, 2012 at 10:57 PM, Anthony Ferrara wrote:
> I've gone back and re-read a bunch of the old posts on Type Hinting,
> and have come to the conclusion that it won't be done any time soon.
> Not because it doesn't have merit, but because there are at least a
> few fundamental difficultie
Clint,
First off, thanks for the reply. With respect to the large switches,
that could easily be avoided with something like:
public function __castTo($type) {
$method = 'castTo' . $type;
if (method_exists(array($this, $method))) {
return $this->$method();
}
throw new Log
I definitely like the idea of being able to cast objects, I've frequently
wished to be able to cast an object to an array. I would argue against the
single __castTo() and __castFrom() magic methods as large switches get to be
difficult to find/read and doesn't support separation.
I would prefe
I've gone back and re-read a bunch of the old posts on Type Hinting,
and have come to the conclusion that it won't be done any time soon.
Not because it doesn't have merit, but because there are at least a
few fundamental difficulties that are non-trivial to figure out while
still keeping the usefu
On Sun, Feb 26, 2012 at 10:03 AM, Stas Malyshev wrote:
> Hi!
>
> Just discovered that our stock "php 4 support discontinued" message in bugs
> looks like:
>
> We are sorry, but we can not support PHP 4 related problems anymore.
> Momentum is gathering for PHP 6, and we think supporting PHP 4 will
On 02/26/2012 08:03 AM, Stas Malyshev wrote:
> Hi!
>
> Just discovered that our stock "php 4 support discontinued" message in
> bugs looks like:
>
> We are sorry, but we can not support PHP 4 related problems anymore.
> Momentum is gathering for PHP 6, and we think supporting PHP 4 will
> lead to
Hi!
Just discovered that our stock "php 4 support discontinued" message in
bugs looks like:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PH
38 matches
Mail list logo
