Rich, I appreciate the candid and honest nature of your reply, while maintaining civility. This list needs more of that. Further replies inline:
On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch <c...@l-i-e.com> wrote: > On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote: >>> I have to say that no matter how much a luv my OOP, turning every >>> built-in type into an Object is just a Bad Idea... >>> >>> It's a form of bloat on RAM and CPU with minimal added value, imho. > >> Re-read what I had written. I never said to turn every built-in type >> into an object. In fact, what I was talking about was keeping and >> preserving the base types as-is. All that I was proposing was adding >> the ability to cast from and to the primitives. That way you could >> silently convert back and forth as needed (transparently when >> possible). >> > > I apologize that my brevity has been misconstrued. > > You are certainly free, even with the tools available in PHP, to > "wrap" an object around integers, strings, and so on. > > There may even be occasions where I think that would be a Good Idea (tm). Well, you can kind of do it now. You can't directly operate on those objects. You need to first manually cast them back to the native type. Take a look at SplFixedArray ( http://www.php.net/manual/en/class.splfixedarray.php ). It has a pair of methods, a static fromArray(), and a instance toArray(). What I'm talking about is adding the ability to push these conversions down to the engine level. > What I object to is building such a facility into core PHP, because: > > 1) You can already do it in userland, and I believe that's where it > belongs. Actually, almost exactly the opposite. You can't do it in userland, but you can in a PECL extension (via cast_object(), get() and set()). The first part of this proposal is basically just exposing those methods (almost 1:1, only consolidating cast_object and get into a single method with a parameter defining the difference). > 2) It unnecessarily [see 1] complicates core PHP, whose major > strengths that drive its success includes its simplicity. Actually, the first part of the proposal doesn't really change the core that much. All it does is add standard object handlers to expose cast_object (which is already partially exposed via __toString), get and set (which are currently null). There shouldn't really be other changes required to the core for the first part at least. The second part of the proposal (the castFrom auto-casting) would require some more changes to the core, and be much more significant. To be honest, I think that would be a separate effort (and a separate RFC) the more I think about it. >>> No matter which way you twist this pretzel: > > I had hoped that this bit would hint that all the proposals along > these lines, including yours, are proposals I would vote against, even > though I did over-blow your actual proposal. > >>> -1 > >> So what it sounds like you're -1ing to, is not actually what was >> proposed... >> >> I'm starting to work on a patch for this as a proof of concept... > > Please do so! > > I'll still vote -1, but obviously others will vote as they see fit. > > All these ideas are welcome. The ones with complete patches even more > so, as they allow a true idea of what the change would mean. > > Unfortunately, however, I must repeat that, so far, the idea has > always fallen flat on its face when the proposer actually attempts to > put action into deed, making a patch that fully meets their proposal. > > That doesn't mean you can't succeed, if you are more skilled than all > your predecessors. I don't think skill has that much to do with it. I think the real key difference is what's being attempted... Anthony > -- > brain cancer update: > http://richardlynch.blogspot.com/search/label/brain%20tumor > Donate: > https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE > > > > -- > 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
