Re: [PHP-DEV] Vote from a "Mere User"

I'm another "mere user", but here are my votes Issue 1: Choice #3 Issue 2: Agree with Greg. Josh Heidenreich ZCE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Clarifying the resolution rules

very code file, they would also need to update all global function calls. History has shown us that breaking code (e.g. PHP4 - PHP5) slows adoption of new versions. Just my 2 cents. Josh On Mon, Oct 27, 2008 at 10:06 PM, Stan Vassilev | FM <[EMAIL PROTECTED]> wrote: > Hi, > > > N

Re: [PHP-DEV] Clarifying the resolution rules

I like that way too On Tue, Oct 28, 2008 at 9:02 PM, Karsten Dambekalns <[EMAIL PROTECTED]> wrote: > Hi. > > Stan Vassilev | FM wrote: >> >> A yet another compromise is possible as the lesser evil: > > ... >> >> They key change is: not to make difference between internal and user >> global functi

Re: [PHP-DEV] Re: Clarifying the resolution rules

end? If your not careful you end up with c# or java where doing anything requires going through hundreds of classes and packages. Josh On Tue, Oct 28, 2008 at 10:09 PM, Nathan Rixham <[EMAIL PROTECTED]> wrote: > Stan Vassilev | FM wrote: >> >> Opinions about how disruptive a ma

Re: [PHP-DEV] Re: Clarifying the resolution rules

e the option to add 'use php' to every file. Also, sorry about the bad comparisons. Regards, Josh On Tue, Oct 28, 2008 at 11:16 PM, Stan Vassilev | FM <[EMAIL PROTECTED]> wrote: >> We are going to ignore the inherit problems that calling >> file_get_contents(__FILE__); wo

Re: [PHP-DEV] Namespaces and \t, \r, \n, \0 etc.

What about just silently converting newline to '\n' and tab to '\t', etc. I mean if you cant put those characters in a string, who will notice? or better, just use a single-quoted string. Regards, Josh On Wed, Oct 29, 2008 at 1:28 AM, Marcus Boerger <[EMAIL PROTECTED]

[PHP-DEV] Constants in double-quoted strings

rsing issues, perhaps a symbol should be placed before or after the opening brace. e.g. "SELECT ID, Name FROM Projects WHERE StatusID = {#STATUS_ACTIVE} LIMIT #{NUM_PER_PAGE} OFFSET {$offset}" Regards, Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Constants in double-quoted strings

Dave, how is a variable name any less a bareword than a constant name? Thats what the backets were for, perhaps combined with a symbol to make it even less likely, and of course if the constant is not found in the symbol table, the constant name would be outputted directly. On Wed, Oct 29, 2008 at

Re: [PHP-DEV] Reviving scalar type hints

See above -- relying on (or even really thinking about) this distinction is relying on implementation details which are going to change. Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] alpha3

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

Re: [PHP-DEV] namespaces and alpha3

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

Re: [PHP-DEV] my last attempt at sanity with namespaces

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

Re: [PHP-DEV] 'Sanity' tally to date

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

Re: [PHP-DEV] my last attempt at sanity with namespaces

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

Re: [PHP-DEV] Re: Sanity tally #2

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)

Re: [PHP-DEV] Re: Sanity tally #2

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:/

Re: [PHP-DEV] Re: Sanity tally #2

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

Re: [PHP-DEV] Re: Sanity tally #2

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"

Re: [PHP-DEV]

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

Re: [PHP-DEV]

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

Re: [PHP-DEV] mapping different keyboard layouts to make \ easier for non-English keyboard layouts?

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

Re: [PHP-DEV] namespace separator and whining

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

Re: [PHP-DEV] namespace separator and whining

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

Re: [PHP-DEV] namespace separator and whining

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

Re: [PHP-DEV] namespace separator and whining

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

Re: [PHP-DEV] Re: Class visibility in namespaces

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...

Re: [PHP-DEV] Call it: allow reserved words in a class or not?

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

Re: [PHP-DEV] Call it: allow reserved words in a class or not?

Stan Vassilev | FM wrote: use foo\bar\*; $a = new A(); $b = new B(); ... I may be asking this question out of ignorance, but here goes: What is the difference between the following snippets? // global.php use \foo\bar\*; $a = new A(); $b = new B(); // namespaced.php namespace \foo\bar; $a

Re: [PHP-DEV] Call it: allow reserved words in a class or not?

Johannes Schlüter wrote: On Thu, 2008-11-06 at 22:19 -0600, Josh Thompson wrote: I don't understand why in the namespaced example no one seems to have a problem with new A() meaning new \foo\bar\A(), but we can't use the * wildcard to do the same thing? Since we don't re

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

detail that "strict enforcement" for scalars is defined in terms of "lossless conversion" as outlined in the RFC, since that's the "PHP way" of loosely dealing with scalar types. The idea of "lossless conversion" has just never been relevant before since

Re: [PHP-DEV] About PHP NG "document lacking" argument

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

Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures

[Andrea, please forward this to internals if you don't see my message appear there in a few hours; as you know, FB is working through issues sending email to internals, and though I think I know how to get it through, if it doesn't make it, please help :) Thanks!] On Aug 4, 2014, at 12:49 PM, A

Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures

On Aug 10, 2014, at 11:20 AM, Andrea Faulds wrote: > Hi! > > Sorry for the slow response, I’ve been on holiday. No problem! > On 8 Aug 2014, at 01:32, Josh Watzman wrote: > >> The RFC goes a long way to fixing this, but one important place it misses is >>

Re: [PHP-DEV] [RFC] Safe Casting Functions

On Oct 20, 2014, at 3:57 PM, Andrea Faulds wrote: > Good evening, > > I am presenting a new RFC to add a set of three functions to do validated > casts for scalar types: > > https://wiki.php.net/rfc/safe_cast > > Please read it. > > Thanks! I think this is pretty cool, but I'm really worrie

Re: [PHP-DEV] [RFC] Safe Casting Functions

On Oct 20, 2014, at 6:17 PM, Andrea Faulds wrote: >> On 21 Oct 2014, at 02:07, Josh Watzman wrote: >> >> Throwing an exception or even returning NULL seems so much better than >> returning "false" -- "false" is a boolean, not an error, and despite s

Re: [PHP-DEV] [RFC] Abstract final classes

ether means you have a class that has no instances itself, and cannot be subclasses, so you can never have an object of that type. The use cases for being able to override such a class are questionable at best, as above. This really is just the combination of two existing class modifiers -- no ne

[PHP-DEV] [RFC] Nullsafe calls

would be a good one for PHP as well, so I'm submitting this RFC to add it -- you can see the RFC itself for a full discussion of the motivation for the feature, as well as the feature itself: https://wiki.php.net/rfc/nullsafe_calls Josh Watzman -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] [RFC] Nullsafe calls

On Dec 9, 2014, at 3:18 PM, Andrea Faulds wrote: >> On 9 Dec 2014, at 23:07, Josh Watzman wrote: >> >> Hey internals! A useful feature that Hack picked up in the last few months >> are "nullsafe calls", a way of propagating failure forward in a series of >

Re: [PHP-DEV] [RFC] Nullsafe calls

ty strongly that this is the correct behavior. It may sound strange when talking about isolated examples like this, but in the real-world code I've seen, it is the least confusing. (I'll see if I can dig up a better example instead of just citing nebulous "real-world code" ;)) Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe calls

d chains are probably a bad idea, but one or two is fine in a lot of cases. But I very vehemently disagree that method chains are *always* a bad idea (i.e., the Law of Demeter) -- or basically any hard and fast rule about programming, for that matter. It can be done tastefully, and for tasteful uses this reduces a lot of boilerplate. Basically every language feature can be abused, and I don't think this one is particularly more prone to abuse than anything else. Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe calls

, catching exceptions here aren't appropriate in the slightest. (Not that *throwing* them is wrong -- if you expect that object to be non-null, then throwing one is great -- my problem is with dealing with that failure by immediately catching it. See my original post for the extended ex

Re: [PHP-DEV] [RFC] Nullsafe calls

had a busy morning :) All of that said: it's not clear to me that this actually matters that much. I wasn't able to quickly find an example because the vast majority of the Hack code I have that uses this operator isn't actually affected one way or the other. Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe calls

On Dec 10, 2014, at 4:12 PM, Christoph Becker wrote: > Josh Watzman wrote: > >> However, for a lot of failures, I don't feel that exceptions are >> appropriate. I tend to only use them for exceptional behavior -- >> usually, some failure that needs to be propaga

Re: [PHP-DEV] [RFC] Nullsafe calls

rrences of this feature and I have yet to find a single one where the short circuit matters or not -- so maybe my recollection and intuition here are just wrong. I'll keep digging and thinking about this. Not convinced yet, but starting to feel less strongly about it. Josh -- PHP Internal

Re: [PHP-DEV] [RFC] Nullsafe calls

On Dec 12, 2014, at 11:09 AM, Josh Watzman wrote: > On Dec 10, 2014, at 11:24 PM, Stanislav Malyshev wrote: > >>> the real-world code I've seen, it is the least confusing. (I'll see >> >> Which real-world code you are talking about? Examples please. &

Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e

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

Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e

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

[PHP-DEV] RFC: Boxing and Unboxing

Greetings All, Intro = The discussion over type hinting seems to be getting divided between those who really like it (most likely the ones who write strongly typed programs anyway) and those who don't want to add yet another kind of type system to PHP. I have been thinking about it and

Re: [PHP-DEV] Type hinting - Request for Discussion

troels knak-nielsen wrote: 1) It covers all the use cases for a type-based system (You can use `is_integer` as a contract, if you want that) 2) It's extensible in user-space, which means that it can be used to convey much more accurate information, relevant to the application needs. 3) It's focus

Re: [PHP-DEV] Type hinting - Request for Discussion

troels knak-nielsen wrote: - How do you know if it is a contract or the current object type hint? The simplest solution would be to make one take precedence. You're not likely to have both a class and a function with the same name, and if you do, you kind of had it coming to you. For backwards

Re: [PHP-DEV] Type hinting - Request for Discussion

Lukas Kahwe Smith wrote: > On 10.07.2009, at 13:20, Lewis Wright wrote: > > >> 3) function Foo(is_int($x)) { > >> > >> Function is_int is called, an error is raised if it returns false. > >> > > > > But then you're complicating it to the point where it's no longer > > much more > > useful

Re: [PHP-DEV] Type hinting

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

Re: [PHP-DEV] Type hinting

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

Re: [PHP-DEV] Type hinting

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

Re: [PHP-DEV] Type hinting

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

Re: [PHP-DEV] Type hinting

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

Re: [PHP-DEV] Type hinting

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

Re: [PHP-DEV] [RFC] Return type-hint

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

Re: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)

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

Re: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)

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

Re: [PHP-DEV] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)

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

Re: [PHP-DEV] Strict typing (was: Typehints)

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

Re: [PHP-DEV] Strict typing

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

Re: [PHP-DEV] Strict typing

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

Re: [PHP-DEV] Strict typing

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

Re: [PHP-DEV] Strict typing

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 su

Re: [PHP-DEV] Strict typing

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

Re: [PHP-DEV] Strict typing

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

Re: [PHP-DEV] Strict typing

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

Re: [PHP-DEV] Strict typing

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

Re: [PHP-DEV] Adding a more logical string slicing function to PHP

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

[PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

Bool() would be of the most personal benefit - if proposal is converted to an RFC, would it be better (faster/smoother) to do one RFC for all the cast possibilities - or to have an RFC for each cast separately? Thank you for the consideration, information, and feedback. Cheers, Josh ps. Also, a

Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

> On Jul 6, 2020, at 11:54 AM, Marco Pivetta wrote: > > Hey Josh, > > Similar proposals were raised recently for `__toArray()`: see > https://externals.io/message/108369#108369 > > I'd endorse avoiding object-to- casts via cast operations: they are > a good so

Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

 > On Jul 7, 2020, at 3:24 PM, Rowan Tommins wrote: > >> On 07/07/2020 18:13, Josh Bruce wrote: >> Decided to put something >> together:https://github.com/joshbruce/external-project-proposals/blob/master/php-concepts/interact-with-instance-as-php.md > > > H

[PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

ng the overly contrived nature of the samples and will improve those over time should interest maintain or increase. Cheers, Josh ps. If you have any feedback or information on social interactions here that might help, please do let me know, normally I would have watched for a while before putt

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

> On Jul 8, 2020, at 12:54 PM, Marcio Almada wrote: > > Hello Josh, > >> Link to working draft: https://bit.ly/php-0001 <https://bit.ly/php-0001> > > From a type safety POV I'd prefer to have an interface available, the > same way we did > to the Stri

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

cast to bool either effectively return the result of an empty check or a not-zero check - an object, if instantiated, is always true. __toBool would give us a way of saying it’s not true (it’s not empty, it's not zero, but it's not okay for some reason - maybe we need to do some follow-on configuration method calls…just making stuff up). :) Cheers, Josh

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

to maintain consistency - but object may be an exception??). Cheers, Josh ps. Also did get registered to the wiki from a different thread conveniently happening at the same time. :)

[PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declare emptiness and by extension truthiness

t; Thanks for all the feedback so far! Definitely feels like progress. Cheers, Josh

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declare emptiness and by extension truthiness

nother thread I’ve been watching and I think I need more karma to make that a thing. I will continue working on this and if it generates enough pull then maybe I’ll be let in - I’ll also contribute where I can to start earning karma. Updated: https://bit.ly/php-0002 <https://bit.ly/php-0002> Cheers, Josh

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declare emptiness and by extension truthiness

nerObject) { // I know it can give and receive messages, and is not empty } else { // I know it can give and receive messages, but is empty } I remember hearing what sounds like hyperbole but it said something like 40% of code written is guarding against null. I can totally see that being real so didn’t look much further into it. If we can guarantee that an object is that type of object - just happens to be empty, maybe we reduce or remove the need null-checks?? Cheers, Josh

Re: [PHP-DEV] Drop warning about non-public magic methods

rement make the following impossible: class SomeClass { private function __toString() {} } $instance = new SomeClass(); $instance->__toString(); It’s one thing if PHP can always reach it, it’s a different thing if I, as the developer, can make it so others can’t. Cheers, Josh > On Jul

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

, if I had class “String” would that still throw a reserved word violation? Cheers, Josh > On Jul 14, 2020, at 5:52 AM, Brent Roose wrote: > > Hi Nikita > > What happens to the attributes syntax if this RFC doesn't pass? > > Furthermore, I think voting against this RF

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declareemptiness and by extension truthiness

> On Jul 13, 2020, at 12:14 PM, Christoph M. Becker wrote: > > On 13.07.2020 at 17:18, Josh Bruce wrote: > >> Re the wiki: I can edit pages now, it doesn’t look like I can create them. >> There’s another thread I’ve been watching and I think I need more karma to >

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declareemptiness and by extension truthiness

> On Jul 14, 2020, at 1:24 PM, Josh Bruce wrote: > > >> On Jul 13, 2020, at 12:14 PM, Christoph M. Becker wrote: >> >> On 13.07.2020 at 17:18, Josh Bruce wrote: >> >>> Re the wiki: I can edit pages now, it doesn’t look like I can create them. >

[PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

ate it! Cheers, Josh

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

https://wiki.php.net/rfc/objects-can-be-falsifiable Updates: - Open issues (outstanding questions/concerns) updated - Future scope - References now have links to original copies on GitHub (still updating 0002) - will be removed if accepted a

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

> On Jul 15, 2020, at 3:26 AM, Nikita Popov wrote: > > On Tue, Jul 14, 2020 at 5:37 PM Josh Bruce <mailto:j...@joshbruce.dev>> wrote: > New to the discussion and being this deep; so, apologies for any bumps. > Mainly questions. > > Does this only affect t

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

> On Jul 16, 2020, at 10:28 AM, Josh Bruce wrote: > > https://wiki.php.net/rfc/objects-can-be-falsifiable > <https://wiki.php.net/rfc/objects-can-be-falsifiable> > > Updates: > > - Open issues (outstanding questions/concerns) updated > - Future scope

[PHP-DEV] Re: [RFC][Discussion] Objects can be declared falsifiable

estions, and concerns! Cheers, Josh

Re: [PHP-DEV] Registration on wiki

mentions. Also not sure if the question changes - it’s always been the same for me. Would give credit to the person who pointed this out earlier to someone else that I happened to see and try, but I don’t remember who it was. Cheers, Josh > On Jul 28, 2020, at 12:54 AM, [ ] wrote: > &

Re: [PHP-DEV] Allow two words keywords

Maybe add it to that thread?? https://externals.io/message/111218 Cheers, Josh > On Jul 30, 2020, at 4:50 AM, Deleu wrote: > > Such a nice syntax. Even better than @@ and @. I wish this could get more > attention/traction. > >> On Wed, Jul 29, 2020, 19:46 David Rodrig

Re: [PHP-DEV] [RFC] Import of variables

or method on a class. Cheers, Josh > On Aug 9, 2020, at 9:58 AM, David Rodrigues wrote: > > I suggests to make something like Node does: import "file.php" ($a, $b) so > $a and $b must be extracted from file.php context. All other variables > should be ignored. >

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

are-development/php-falsifiable-objects> 2. I agree some type of working concept should be a thing. 3. Have some other projects taking precedent, any assistance on implementation would be greatly appreciated. Cheers, Josh > On Jul 22, 2020, at 7:49 AM, Larry Garfield wrote: > > On Tue, Jul

[PHP-DEV] [Concept] Don't cast keys in array to int

f course, casting back puts us back to an indexed array. I’ve picked up that type juggling might be a touchy point - but the focus is on why the key gets cast at all when it’s an array type. Is it to facilitate the type juggle from an object to an array?? Cheers, Josh -- PHP Internals - PHP

Re: [PHP-DEV] [Concept] Don't cast keys in array to int

Thanks Rowan. I can appreciate that rationale. Also let’s me in on why we might want to have an indexed array that is not necessarily sequential - but are integers. Thanks again. Cheers, Josh > On Aug 17, 2020, at 4:17 AM, Rowan Tommins wrote: > > On Mon, 17 Aug 2020 at 05:19

Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

not be completely following. Cheers, Josh > On Aug 29, 2020, at 3:39 PM, Alex wrote: > > I like it! > > What is the $use_flags parameter for? > >> On Sat, Aug 29, 2020 at 10:24 PM tyson andre >> wrote: >> Hi internals, >> The primitives any() and a

Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

even if the output isn’t different in most cases. example(true, true, false); example(USE_BLUE, DROP_FIRST... With names arguments in 8 we do get helped, I think. mb_case_switch had 3 flags in the beginning, now gas 6 - if I’m remembering and interpreting the docs correctly. Cheers, Josh

Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

a database or some ORM, I *get* all - I’m not verifying “all pass [a predicate]”. Cheers, Josh > On Aug 29, 2020, at 6:48 PM, tyson andre wrote: > >> The “any” check is just to if anything in the iterable passes the predicate, >> yeah?? >> >> What I find mysel

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

> “Type system” implementation - https://github.com/8fold/php-shoop/blob/master/src/Filter/TypeAsBoolean.php <https://github.com/8fold/php-shoop/blob/master/src/Filter/TypeAsBoolean.php> Cheers, Josh > On Aug 9, 2020, at 3:59 PM, tyson andre wrote: > > Hi Josh, > > I

  1   2   >