On 25 July 2014 16:06, Zeev Suraski wrote:
> I'd prefer that over a non-vague and very public character assassination
> that me and others are experiencing instead.
I cannot comment on that statement but character assassination is bad
either way, sure.
> I'm also wondering why you're replying t
On 24 May 2013 10:44, Stas Malyshev wrote:
>
> It is rather surprising that you would expect that as a PHP programmer,
> since it never worked this way in PHP, and no PHP code works this way
> either.
I'm saying that "as a PHP programmer" because my expectation is not
based on how other languages
On 23 May 2013 22:22, Stas Malyshev wrote:
> If we update file/line here, we lose original exception information and
> file/line in the exception becomes useless. Right now, since 99.99% of
> the code does "throw new", it is always useful. So how you would propose
> to solve this?
As a PHP progr
On 30 March 2011 15:05, Hannes Landeholm wrote:
> Parsing is a problem in many real-world
> problems and substr currently works great for that purpose.
That's funny because the first thing I thought when I read the
original mail was "oh that would be great for parsing." In fact, I've
just grep'ed
2010/8/12 Johannes Schlüter :
> Yes, my blog posting reflects my opinion and therefore is manipulative
Indeed. Depending where you'll look, you'll find big communities that
have no clue about or no need for type hinting/checking/casting, some
communities where "strict" typing is heresy, others whe
On 12 August 2010 00:11, Zeev Suraski wrote:
> I'm not sure how long you've been on internals, but I'm not sure there's any
> precedence to such strong and diverse opposition to a feature - amongst both
> core developers, original authors and the community at large.
I don't know, I remember some
On 11 August 2010 23:26, Zeev Suraski wrote:
> matter how much I try to explain - it won't help - we probably see things
> too differently for us to ever agree on it. Let's end it by saying that a
> great deal of people here think it's horrible to introduce strict typing to
> PHP period.
Sure, a
On 11 August 2010 21:59, Zeev Suraski wrote:
> Consensus about what? About two similar features with slightly different
> syntax being a bad thing? I don't think we need consensus for that. That's
> not up for discussion. It's an axiom for PHP.
Of course it depends on your definition of "simi
On 11 August 2010 20:40, Zeev Suraski wrote:
> Josh,
>
> This too (having both options) was debated many times. Read the archives.
I have already read the archives thank you very much. I'm sure you
have too and you remember that there's never been a consensus. I'm
sure that Derick remembers them
On 11 August 2010 19:11, Alexey Zakhlestin wrote:
> Did you read second RFC? The one which is about "so called" weak typehinting.
> Stas (and a lot of people on this list) prefer it.
> http://wiki.php.net/rfc/typecheckingstrictandweak
Yes of course, but reposting that link is a good idea. :)
> I
On 11 August 2010 19:20, Stas Malyshev wrote:
> I'm against it on sanity and logic grounds. I explained the reasons (for the
> Nth time) above. If you still can't comprehend that there's logic behind
> what I am saying and call it "ideology" - well, I guess there's a limit of
> what one can explai
On 11 August 2010 08:23, Stas Malyshev wrote:
>> I very much can, it's just not my intention. I want to be able to use
>> type hinting/type checking as a sanity check. If I write a method
>> whose signature is foo(int $n) I signal my intention to only accept
>
> Then you should use statically typ
On 11 August 2010 02:50, Stas Malyshev wrote:
> Hi!
>
>> First of all, I am talking about the typehinting syntax and mechanism
>> here. As Derick pointed out, current typehints are strict.
>
> Talking about "strict" vs. "non-strict" for class types is meaningless.
By "strict" typehints I meant th
On 11 August 2010 02:13, Arvids Godjuks wrote:
> Remember the main PHP principle? KISS. So keep it, blody hell, simple!
Please try to realize that what you find simple may not appear as
simple to everybody else. To me, typechecking is very simple: if type
equals typehint then ok else error. Very
On 11 August 2010 01:50, Stas Malyshev wrote:
> Hi!
>
>> Derick's point was about consistency. The approach described in his
>> mail is consistent with current syntax and mechanism(s). Current
>
> No it is not. There's no functions that produce errors when fed 1 instead of
> boolean "true" - all i
Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current
typehints do not apply any kind of conversion, so treating scalar
hints the same way is consistent with the current mechanism.
Reusing the typecasting syntax for typ
On 29 July 2010 13:57, Felipe Pena wrote:
> My suggestion (I guess already told it in some mail...) is to
> identify the native php type just when it's lowercased (case-sensitive).
Alternatively, one could use the full qualified name to refer to the
class name, e.g.
function expectsScalar(string
On 3 June 2010 23:37, Stas Malyshev wrote:
> Validation and typing are entirely different things. Many validation methods
> do not require or provide strict typing.
I can't agree more and that's exactly why I want typehints to only
check for type, not validate the content of a variable. An "integ
On 3 June 2010 22:24, Gustavo Lopes wrote:
> On Thu, 03 Jun 2010 17:25:53 +0100, Josh Davis wrote:
>
>> The only other big source of data is the database. [...]
Emphasis on "big." There's an infinite number of sources (from mashups
using XML or JSON to XML-RPC servers
On 3 June 2010 18:25, Josh Davis wrote:
> seems that mysqlnd experiments in using MySQL's binary protocol for
> all queries and not just prepared statements [1] didn't materialize.
I have to correct myself here, the MYSQLI_OPT_INT_AND_FLOAT_NATIVE
option did materialize, so nativ
On 1 June 2010 20:43, Stas Malyshev wrote:
> It is very frequent that you want number and get "1" instead - almost
> all incoming data for PHP are strings.
I'd like to point out that filter_input() does cast user input to the
right PHP type. And if memory serves, ext/filter is meant to be PHP's
On Sun, May 23, 2010 at 7:52 AM, Larry Garfield wrote:
>
> Everything that comes back from a database does
> so as a string. To wit: [...]
This is not entirely true though. mysqlnd will return native types
through PDO or mysqli if you use prepared statements [1] and hopefully
other queries somed
On 22 May 2010 17:04, Zeev Suraski wrote:
> As one of the key people who designed PHP's type system I consider strict
> type checks completely alien to and counterintuitive in PHP and am therefore
> pushing to implement 'weak' typing instead, in a way that's consistent and
> familiar to users.
I
2008/11/6 Stan Vassilev | FM <[EMAIL PROTECTED]>:
>
> There's one trivial solution: make the keywords and class names
> case-sensitive. Then classes "If", "Array", "Interface" will never class
> with the all-lowercase keywords.
As much as I'd love to see more case-sensitivity, I'm afraid it would
2008/10/30 Franck Jasper <[EMAIL PROTECTED]>:
> A recurrent scheme, on internals, is to underestimate the PHP developer's
> skills
> and needs.
> And no namespaces were added to the language by that time, because it was
> probably considered that a "PHP developer" would never need such a thing...
2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
> 1) check for namespaced\classname
> 2) try to autoload namespaced\classname
> 3) fail
Ok, that makes some sense wrt your position, which I originally
interpreted as namespace/internal/autoload.
You want to force users to use the full name at a
2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
>> Then, if we assume that most people will use the global namespace
>> without prefixing it, what would be the best resolution order for
>> them? (you didn't mention it in your previous message)
>
> Using the prefixed names.
I'm sorry but I stil
2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Actually, one time is enough, as it can bring an application from
> essentially zero disk accesses (with bytecode caching) to multiple disk
> accesses (to traverse full include path to exhaust all autoloading
> capabilities).
So we're talking a
2008/10/27 Rodrigo Saboya <[EMAIL PROTECTED]>:
> I agree with Stas. It's better to force people to actually reference their
> classes/functions/constants correctly and get better performance than
> getting unclear slowdowns.
If I'm not mistaken, you only experience any noticeable slowdown if
all o
2008/10/27 Hannes Magnusson <[EMAIL PROTECTED]>:
> But now you suddenly want to tell people how to change their
> keybindings? Goto sleep man.
Wow, that's incredibly hostile, uncalled for and counter-productive.
You are attacking Greg for going out of his way to accomodate those
inconvenienced by
2008/10/27 Cristian Rodríguez <[EMAIL PROTECTED]>:
> Im truly sorry, looking at the horrendously ugly example code, I just
> hope the average joe programmer dont touch this feature and stay with
> class prefixes for sanity sake.
If by "don't touch" you mean "don't even try" then I'd say it's not
2008/10/27 Guilherme Blanco <[EMAIL PROTECTED]>:
> Hi guys,
>
>
> I'm really interested to read the IRC conversation logs.
> Does anyone recorded it?
If you follow the link [1] from the first mail, you'll find the log
you're looking for in the References section.
[1] http://wiki.php.net/rfc/names
2008/10/18 Steph Fox <[EMAIL PROTECTED]>:
> I did actually keep tabs on this. Yes the choice of separator played a part
> for many. However there were just as many who were happy with it - and the
> same would have applied whatever separator was used.
What I'm wondering is how many of those "many"
2008/10/18 Daniel Brown <[EMAIL PROTECTED]>:
> On Sat, Oct 18, 2008 at 2:28 PM, Josh Davis <[EMAIL PROTECTED]> wrote:
>> 2008/10/18 Keryx Web <[EMAIL PROTECTED]>:
>>> Triple colon as in suggestion 1 and 2 is a readability nightmare - yes in
>>> both s
2008/10/18 Keryx Web <[EMAIL PROTECTED]>:
> Triple colon as in suggestion 1 and 2 is a readability nightmare - yes in
> both suggestions.
Is that why you voted for 3? Because triple colons are hard to read?
JD
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:/
2008/10/17 Mike Willbanks <[EMAIL PROTECTED]>:
> 1. #3 - it is much cleaner to read than the other implementations in
> resolving the conflict. a different separator will be much harder to simply
> see from a comparison.
I beg to differ. A different separator (namespace scope resolution
operator)
I have a question about 3. Where in a script can you use the "use"
statement? Could it be used inside conditionals? For example,
if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}
If that's the case, could we have a word from an opcode cache guru
about how nice it would p
2008/10/16 Steph Fox <[EMAIL PROTECTED]>:
> Please can those people who didn't already express a clear and relevant
> opinion, express it now? We don't have long to play with this if there's to
> be namespace support in 5.3.
Hi,
As far as I'm concerned, my preference goes to:
2. use a different
2008/10/15 Greg Beaver <[EMAIL PROTECTED]>:
>
> Read it and discuss.
Hello,
First of all I'd like to thank Greg for his efforts to move the
discussion in a positive direction. From a PHP user's point of view,
it's comforting to see that this kind of discussion can still take
place with a cool hea
2008/10/14 Steph Fox <[EMAIL PROTECTED]>:
>
> Only 8 hours ago, one Jean-Phillipe Serafin wrote: "Many people have
> starting working on top level application using namespaces, so there will a
> very bad buzz over the php community if namespaces are ripped out..." and
> there were further objection
In response to Larry Garfield's comment that "[t]here's nothing
"familiar" about :: to 99.99% of PHP developers who haven't already
been playing with the alphas" I'd like to point out that since PHP
5.1, the double colon is effectively used as a namespace operator by
extensions, in the sense that e
41 matches
Mail list logo
