RE: [PHP-DEV] Internals read-only

2007-12-13 Thread scott.mcnaught
This email thread is boring... -Original Message- From: rich gray [mailto:[EMAIL PROTECTED] Sent: Friday, 14 December 2007 12:17 AM To: internals Mailing List Subject: Re: [PHP-DEV] Internals read-only If this suggestion from Jani is supported then all I can say is WTF a bunch of

RE: [PHP-DEV] Namespace

2007-12-08 Thread scott.mcnaught
Quick question... If I wanted to override or extend php's functions... Could this work? Say I want to change the implementation of var_dump() to make it more html friendly... function var_dump($mixedVariable) { echo('pre'); ::var_dump($mixedVariable); echo('/pre'); }

RE: [PHP-DEV] Namespace

2007-12-06 Thread scott.mcnaught
Just a thought... You know the whole thing about bundling into one file improving performance. People do this when they have upwards of 20 classes being included per request. I bet that most of the time these classes are a part of a framework / something that would be a part of common name space

RE: [PHP-DEV] Garbage collector patch

2007-12-04 Thread scott.mcnaught
I think having it configurable is a must. Turning it on / off via a compile flag will not suit everyone. Eg - I have a situation where I would not want to run garbage collection for web pages served off my server due to the performance hit, however I also have a CLI script which I run to do

RE: [PHP-DEV] ignored patches

2007-12-03 Thread scott.mcnaught
I am a developer on a CMS also which uses the auto-include functionality to include many classes over many files. Each request can include up to 30 different files. The speed increase is around the 15% mark when combining the files. This is with APC installed too. I heard rumours however that

RE: [PHP-DEV] POSIX regex

2007-07-19 Thread scott.mcnaught
I don't like the idea of having a u prefix for Unicode strings. It may improve performance, and give you some level of fine grain control, but... - It breaks your keep php simple policy by introducing a lot of new functions (ugly). - I (plus a lot of others) have an existing php5 application

RE: [PHP-DEV] POSIX regex

2007-07-19 Thread scott.mcnaught
I don't really know much about unicode, and to be honest, I don't really know much about the internal workings of php. But I assume that there are going to be different implementations of string functions depending on whether the string is unicode or not. I'm going to suggest an implementation

RE: [PHP-DEV] POSIX regex

2007-07-19 Thread scott.mcnaught
Sorry if you are using outlook, turn off the thing that says Extra line breaks in this message were removed at the top of my previous message. Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 20 July 2007 10:11 AM To: internals@lists.php.net

RE: [PHP-DEV] Native Singleton Implementation

2007-03-13 Thread scott.mcnaught
Very well. I just thought it would be a nice OOP feature to save time on some people's behalf. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Wednesday, 14 March 2007 8:41 AM To: [EMAIL PROTECTED] Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Native

RE: [PHP-DEV] Native Singleton Implementation

2007-03-12 Thread scott.mcnaught
Perhaps I should not call it singleton then. Because I'm not trying to put a flexible design pattern with large degrees of freedom as such into core php. All I am trying to achieve is a nice way for people to implement classes that only ever need one instance. Can I ask why you are very much

RE: [PHP-DEV] Native Singleton Implementation

2007-03-12 Thread scott.mcnaught
Does such a feature exist in any other languages? Not that I know of. But does that mean it's a bad idea? What is the point of putting just one possible solution into core PHP when there are plenty of acceptable solutions already out there in userland? That is like saying what's the point

RE: [PHP-DEV] Native Singleton Implementation

2007-03-10 Thread scott.mcnaught
Yeah that's the same way that I implement it. You're still using strings for referencing class names. Sorry my file didn't get attached when sent to the list. http://hlrally.net/media/singletonabc.inc The advantages are: - Speed improvements - Allows for context sensitive code hinting in IDEs

RE: [PHP-DEV] Native Singleton Implementation

2007-03-09 Thread scott.mcnaught
Hi Tony, I do have a single singleton class to deal with singletons (as you put it). I have attached it to this email for your reference. But it's back to my original problem where you either have to: - Duplicate code for each singleton class ... or ... - Reference your classes via strings

RE: [PHP-DEV] Native Singleton Implementation

2007-03-06 Thread scott.mcnaught
Hi Greg, There is no reason why you can't still use the current method to implement your variations to the singleton design pattern. But, yes, I am proposing that the strict text book variety is implemented. If you haven't had the need to singleton-ize more than 2-3 classes, you probably haven't

RE: [PHP-DEV] Native Singleton Implementation

2007-03-06 Thread scott.mcnaught
Thanks Peter. I agree with everything except the use of the keyword new. I think that it's just simply too confusing. People won't know whether they are getting a fresh instance or not. The only keyword suggestion is not bad. I think id prefer get or something. (or better no keyword at all ;))

[PHP-DEV] Native Singleton Implementation

2007-03-04 Thread scott.mcnaught
*** Sorry - forgot to change the subject *** Hello All, I am new to the php internals mailing list. I am a fairly experienced programmer with a few ideas floating around. I have come from a C++ games development background and have now moved to primarily writing in php. One thing that I used

RE: [PHP-DEV] Native Singleton Implementation

2007-03-04 Thread scott.mcnaught
Sure, implementing singleton is easy enough. But you can't abstract it in PHP. In C++ you can use things called template classes or generics to abstract the singleton implementation. This way you don’t have to duplicate the protected constructor, the instance and the accessor for each class. I