Re: [PHP-DEV] Re: Mandatory File Locking in PHP?
On Thursday 30 January 2003 02:24, George Schlossnagle wrote: Mandatory locks actually prevent read and write calls from _anyone_ else succeeding on that file. If implemented improperly, they are also a wide open door for denial of service attacks on a system (set a mandatory lock on /etc/passwd and hilarity ensues). Security conscious system administrators disable them in their system for this reason. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf troubles with 4.3.0
On Sat, Dec 28, 2002 at 12:33:06PM +0100, Sascha Schumann wrote: ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_INCLUDE Install m4 1.4 rather than 1.4o. p15104972:/usr/src/packages/SPECS # rpm -qi m4 Name: m4 Relocations: (not relocateable) Version : 1.4 Vendor: (none) Release : 37Build Date: Sat Dec 28 23:27:02 2002 Install date: Sat Dec 28 23:27:40 2002 Build Host: p15104972.pureserver.info ... Building mod_php4.3.0 now gives: Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.4356 + umask 022 + cd /usr/src/packages/BUILD + cd php-4.3.0 + ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.4.1 (ok) rebuilding configure NONE:0: /usr/bin/m4: `syncoutput' from frozen file not found in builtin table! NONE:0: /usr/bin/m4: `changesyntax' from frozen file not found in builtin table! autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_INCLUDE rebuilding main/php_config.h.in NONE:0: /usr/bin/m4: `syncoutput' from frozen file not found in builtin table! NONE:0: /usr/bin/m4: `changesyntax' from frozen file not found in builtin table! + autoconf NONE:0: /usr/bin/m4: `syncoutput' from frozen file not found in builtin table! NONE:0: /usr/bin/m4: `changesyntax' from frozen file not found in builtin table! configure.in:384: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:526: warning: AC_TRY_RUN called without default to allow cross compiling ext/iconv/config.m4:55: warning: AC_TRY_RUN called without default to allow cross compiling ext/imap/config.m4:203: warning: AC_TRY_RUN called without default to allow cross compiling ext/imap/config.m4:213: warning: AC_TRY_RUN called without default to allow cross compiling ext/qtdom/config.m4:36: AC_PROG_CXXCPP was called before AC_PROG_CXX ext/xml/config.m4:5: warning: AC_TRY_RUN called without default to allow cross compiling ext/xslt/config.m4:95: warning: AC_TRY_RUN called without default to allow cross compiling autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_INCLUDE Bad exit status from /var/tmp/rpm-tmp.4356 (%build) -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf troubles with 4.3.0
On Sat, Dec 28, 2002 at 12:28:16PM +0100, Derick Rethans wrote: Looks like a bug in your build tools installation. Can you try upgrading to automake 1.5 and libtool to 1.4.2? Will try. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] autoconf troubles with 4.3.0
I am trying to build a fresh php 4.3.0 rpm on SuSe Linux 7.2 with all updates. My build is based on the spec file for a working 4.2.3 build, which I updated for 4.3.0. It fails like this: Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.57298 + umask 022 + cd /usr/src/packages/BUILD + cd php-4.3.0 + ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.4.1 (ok) rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_INCLUDE rebuilding main/php_config.h.in + autoconf configure.in:384: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:526: warning: AC_TRY_RUN called without default to allow cross compiling ext/iconv/config.m4:55: warning: AC_TRY_RUN called without default to allow cross compiling ext/imap/config.m4:203: warning: AC_TRY_RUN called without default to allow cross compiling ext/imap/config.m4:213: warning: AC_TRY_RUN called without default to allow cross compiling ext/qtdom/config.m4:36: AC_PROG_CXXCPP was called before AC_PROG_CXX ext/xml/config.m4:5: warning: AC_TRY_RUN called without default to allow cross compiling ext/xslt/config.m4:95: warning: AC_TRY_RUN called without default to allow cross compiling autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_INCLUDE Bad exit status from /var/tmp/rpm-tmp.57298 (%build) Do I need to update some auto-stuff, again? Or what may be the cause for the breakage? Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ? vs. ?php - a statistic
We have heard a lot of anecdotal evidence about the usage of ? vs. ?php vs. other methods of PHP invocation. In order to clear things up a little, I have asked a friend of mine for more detailed numbers from a real world example. The following tests have been done very much ad hoc, and the numbers are not representative. They have been made across the PHP files found at a very large german provider. The test has been running for a night until he killed it, and the friend estimated that a full run across several million domains would take about 10 days to complete. He did not do anything to filter out standard scripts such as phpMyAdmin, nor did he do anything else to postprocess the numbers. The following numbers have been generated by find and grep for all lines that have something that resembles a PHP opening tag. These lines have then been categorized and counted. The total result set had a size of approx. 1.3 million lines. ?php 84% ?=3% ?12% % 0,3% script... 37ppm If you can come up with a script or a program that a) performs and b) can take the output of find at stdin, I will ask for a more detailed statistic. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ? vs. ?php - a statistic
On Thursday 24 October 2002 11:28, Zeev Suraski wrote: I don't think that matters that much really. Even if it's 2%, and not 12% or 50%, we're still talking about billions of lines of code... Yes, we do. I am still offering the opportunity to run a statistical analysis of choice across a very large assembly of real world PHP use for all of you, provided you come up with a script that does the counting. This is not limited to ?-matters at all. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsigned Problems Revisited
On Tuesday 22 October 2002 19:23, Jason T. Greene wrote: If for some reason we HAVE to have a symmetrical bogus unsigned left shift operator, and we completely disagree with my arguments on overloading the HEREDOC operator, then we can implement , =, . = as the unsigned shift operators. There is no need for operators to be composed from nonalphabetic characters. You could use a function (shift is already taken, but ashift and ushift for arithmetic shift and unsigned shift are free and value, direction and shift width are parameters). Or you could use an operator with a name similar to assembler instructions (asl, asr for arithmetic shift left and right, lsl and lsr for logical shift left and right). I rather prefer this to an arbitrary number of angle brackets. 2. Shift behavior declare compiler directive Implement a declare compiler directive which will change the behavior of Sucks. 3. Implement Unsigned Data types - This would be a very good idea, but is hard to do in the current typing concept of PHP. (Shift function) See above, if function, then as generic as possible. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
On Wednesday 23 October 2002 09:41, Edin Kadribasic wrote: (B OTOH, having implicit_flush turned on makes writing interactive command (B line programs easier. Some programs (like pear installer) might even depend (B on it. (B (BThe proper way around this, as I see it, is to flush at the end of line, and (Bbefore each read operation on an interactive tty. This would give you (Bthe performance of implicit_flush off with the proper interactive behaviour. (BI'd like to call this "implicit_flush = smart". (B (BKristian (B (B (B-- (BPHP Development Mailing List http://www.php.net/ (BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Idea to extend language: Explicitly setting variable scope inside user defined function (longer)
On Tuesday 22 October 2002 03:19, Hans Zaunere wrote: While some of the scoping tricks proposed seem like potential overkill, I've yearned for a way to explicitly declare a variable a super-global. We already have that. If $avar is a variable, $GLOBALS[avar] is the superglobal access to that variable. Always has been since the dawn of time. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
On Tuesday 22 October 2002 08:13, Terence Kearns wrote: I would hate to see PHP's simple but awsome application producing capability essentially *crippled* (or at least stifled) when XML becomes the norm because inter-application functionality (such as SOAP for only *one* example) is essential as the web landscape evolves. I can see how short_open_tag enabled makes life harder than it should be for the XML-using PHP-developer. I fail to see how this can happen in a situation where this developer has no control over the appropriate php.ini setting, though. So basically, what PHP does now is unclean, hacky and as usuall correct, enabling short_open_tag for the great unwashed masses. Those that strive for lean and clean XML-solutions always can flip the switch, or if they are of the brighter variety, use a more templatey generation schema that does not mix XML and PHP in the first place (PEAR::XML_Transformer comes to mind, if you do not like XSLT). Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
On Tuesday 22 October 2002 09:17, Terence Kearns wrote: Ideally this is true, but as so many poeple have pointed out, not every developer has access to the ini file on their ISPs server. Indeed, maintaining a php.ini file is already a nightmare for ISP hosting to unspecified groups PHP users. I cannot speak for other ISPs, only for our setup. In our environment we do have low traffic setups. These are run from Apache servers with a hacked up suexec that includes a chroot() call to the customers toplevel directory. This setup runs CGI-everything including CGI-PHP. Due to chroot, each customer gets a copy of a minimal execution environment including a copy of the PHP interpreter and a copy of php.ini. The customer can install additional software (sparc binary) including a C-Compiler or Assembler, a different PHP if she likes. Should the customer break something, we reinstall a copy of the original setup on top of this. This setup offers the advantage of highly customized configuration for the customer, extremely low maintenance cost for us, and very high grade security (no safe_mode required, security independent of PHP, affects all CGI, even resistant to access rights goofs). The price is the CGI performance penalty. Because of this we also have some mod_php setups, but these are usually dedicated (again no safe_mode) or very controlled. In these environment the customer cannot control php.ini, but has no need to as there is php_flag and php_value available from .htaccess. This includes the dreaded short_open_tag flag. And frankly, if you need XML and short_open_tag disabled, and if you need it on a hosting machine and not as a local CLI program (which I think is far more likely) and if you need to intermix XML and PHP instead of using a templating solution, and if you THEN insist on a provider with a setup that is simply broken, then I feel you deserve what you get. Really. My main concern is that when XML becomes very popular, trying to implement it will become a NON-trivial exercise for the great unwashed. If you need to deal with XML, and you need to do it with PHP instead of XSLT, go PEAR and use the Transformer. You save yourself all the engineering and you will be independent of all short_open_tag hassles. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
Am Mittwoch, 21. August 2002 22:09 schrieb Shane Caraveo: Rasmus Lerdorf wrote: production quality. The best we can do is pick a small set of extensions and a small set of platforms and say that with the limited set of extensions, against a specific set of versions of addon libraries on a specific version of that OS, yes, it should be production quality - maybe. I believe the designers of the Roxen web server were in a similar situation as Roxen is threaded, too. They worked around this problem with wrapper functions that kept a per-library lock for each library that was not tested as threadsafe. They gradually improved the granularity of their locks, and isolated threadsafe functions, improving performance. How are the perl people handling this issue? I believe they are using the same libs as we do. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
Am Donnerstag, 22. August 2002 09:43 schrieb Rasmus Lerdorf: Putting in locks is the easy part. The tough part is finding which libraries are safe and which ones aren't. I think that is easy, too. Either the library you are using is being documented as threadsafe, then it is. Or it isn't documented as threasdsafe, in which case you have to mutex it, even if it is actually threadsafe internally - no docs for it, the feature is an accident and you may not rely on it. Talk to the developers and make them cooperate. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Output Buffering and error messages?
How does PHP handle error messages when some ob_handler is engaged? Are they caught as well? If so, why? Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
On Fri, Jun 07, 2002 at 09:27:13AM -0500, Jason T. Greene wrote: IMO, one of the big reasons for having a powerful OO mode, and continually evolving php to have a bigger target than just a web programming language, is code re-usability. You do not need OO for this. OO just helps you to manage your namespaces better. The rest is just good coding practice and a little bit of organisation. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
Am Donnerstag, 6. Juni 2002 19:59 schrieb Dan Hardiker: I sit in many PHP channels (IRC), and observe many class-based PHP networks (php-classes.org is one I monitor closely) and can say definatly that the majority of PHP users want *more* OO capabilities in PHP. From a marketing POV, what most people want is NOT more OOP in PHP, but actually a hostable Java. PHP is everywhere and pretty much free, when it comes to webspace hosting. Java usually isn't, because it has certain requirements for its execution environment that cannot be met in cheap hosting environments. So when users ask for more OO in PHP, they usually want Java and Java capabilities for the price of their current PHP site, and a migration path towards this. Since there is no such thing, they end up trying to turn PHP into Java. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch-tastic!
Am Mittwoch, 5. Juni 2002 10:44 schrieb Ilker Cetinkaya: Nice, but why not overload + for strings to do the concatenation? i totally agree, overloading + for string concat is really desireable. No, it is a nightmare. PHP is a dynamically typed language, that is, the actual language objects know their type, while object names (variable identifiers) are untyped. Also, PHP automatically changes types of language objects as needed. Consequently, most developers do not know the actual type of their variables (it is not seen anywhere unless you specifically ask for it), and most of the time they don't actually care for it. For example, when was the last time you noticed or even cared that all arguments of your program (_GET, _POST, _COOKIE) are actually string type, even if they are pure numeric strings? Overloading + would suddenly require that developers care about type, and would force them to write expressions like $c = $a . $b; as $c = (string) $a + (string) $b; just to make sure. Not actually an improvement. This actually a deeper problem, as we have seen in the last few discussions here on the list. PHP may remotely resemble C, C++ or even Java. It isn't. And it isn't intended to be. If you treat it like any of these statically typed, compiled, and far more traditional languages, you bleed. Big time. Actually, I believe that Javascript has the programming and execution model that comes closest to PHP of all the C lookalike languages. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch-tastic!
Am Mittwoch, 5. Juni 2002 16:41 schrieb Jason T. Greene:
If '+' concatenates what does '-' do?
It drives you nuts.
At least it does so in pike, which is a (discretionary, it has a
type mixed) statically typed language and overloads the
arithmetic operators for string types.
See
http://pike.roxen.com/documentation/tutorial/tutorial_5.html#5.1
for the full details. Here is the relevant excerpt:
operands: string + string
return type: string
In this case, any int or float is first converted to a string.
Then the two strings are concatenated and the resulting string
is returned.
operands: string - string
return type: string
A copy of the left string with all occurrences of the right
string removed.
operands: array(string) * string
return type: string
All the strings in the array are concatenated with the string on
the right in between each string. Example: ({foo,bar})*-
will return foo-bar.
operands: string / string
return type: array(string)
In symmetry with the multiplication operator, the division
operator can split a string into pieces. The right string will
be split at every occurrence of the right string and an array
containing the results will be returned. Example: foo-bar/-
will return ({foo,bar})
Now if you would kindly look up the overloaded operator
definitions for arrays and hashes (called mappings in pike) and
after that retire to a secluded place _before_ you vomit?
Thank you,
Kristian
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch-tastic!
[ I copy this to php-dev again, despite the fact that Ilker sent this to me in private mail, because I want to promote the concept of warnings for named accesses to _-members again. Privacy in C++/Java style will raise a lot of issues on this list again, if it is introduced to PHP. My proposal will have less syntactial impact, and will better blend with the general style of the language at this time. ] Am Donnerstag, 6. Juni 2002 11:58 schrieb Ilker Cetinkaya: know how objects and inheritance is done in javascript (ecma respectively?). have you ever seen private members on objects of js? In Javascript, each object is it's own class. You create new objects basically by duplicating some initial object, that is, Javascript's new is actually a clone. This is conceptually close to what PHP 4 does, where you can have preinitialized member variables in an object, and where you can at runtime add member variables to an object (and you could for a short time even add member functions thanks to Andrej, I believe). PHP 4 deviates from (I would even say obscures this) by not having an explicit clone operator (but PHP 4 implicitly clones every time due to unexpected value-semantics). Regarding the concept of private: Private member variables and private member functions are a nuisance anyway in a language where you can add members to an object at runtime. Also, in it's wake the concept of private introduces a lot of syntactic complexity as well, such as the need for protected variables and functions, and a friend relationship between classes. You will immediately see discussions around this issue once privacy is introduced. In Javascript-like languages, the same effect can be had by simply issuing a warning whenever accessing a member variable or member function with a name starting with _ through a named variable. That is, you would see warnings for $a-_private_slot = 10; $b = $a-_private_slot; $c = $a-_private_function(); but not when accessing the same internally using $this: $this-_private_slot = 10; $b = $this-_private_slot; $c = $this-_private_function(); A coder that must access private member variables and member functions through a named variable (and there are a lot of legitimate reasons for this, namely all metaprogramming applications including debuggers, rpc proxies, serializers and the like) can easily shut of this warning: $a-_private_slot = 10; $b = $a-_private_slot; $c = $a-_private_function(); will all execute warning-free, and clearly mark these statements as violating the encapsulation-contract of conventional OO programming, the same way a type-cast marks a violation of the typing contract in C, C++ or other statically typed languages (and there are a lot of legit reasons for that, too). This implementation of private has several advantages, one of them being that it is elective, another of them being that it is the minimal syntactic extension of current PHP, and a third of them being that it is compatible with current PEAR. namespaces? statics? consts? These concepts do not contradict a dynamically (this is different from loosely!) typed language concept. in closing, i have to admit that such a change would be a big issue in aspects of compatibility, juggling, parsing and object handling. therefore i'm sure it's not going to be realized. but still i'd desire it. just to be more stricty. I suggest you try Java. You seem to want it. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Linuxtag Coordination
I will be at Linuxtag on Sunday. I will have a cellphone. The number is +49 170 2231 811. I will not have net access. You need to summon me by phone (or by calling my name thrice while standing in a properly ornamented pentagram). Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision
Am Mittwoch, 5. Juni 2002 14:26 schrieb [EMAIL PROTECTED]: Peace through superior firepower? That's a trademarked american concept at the moment, I think. Kristian Can we please keep the anti-american comments to ourselves. Or else! :-) Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Funny message
On Tue, 4 Jun 2002, Michael Stolovitzsky wrote: Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM in [...] With all due respect to Hebrew humour, am I the only one who thinks that the above line is confusing to non-Israeli? ;) Hey, I am a transplanted Canadian Danish Latin Eskimo living in California and even I know that this obviously means double-colon... Still the error message sucks, even if you substitute any other token in place of the double colon. There is no context given (listing the line in question and placing a ^ below the current position would be of great help), and sometimes there are even general parse errors messages, no reason given at all. This seems to need a bit of work, I believe. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision
Am Montag, 3. Juni 2002 18:11 schrieb Sebastian Bergmann: Zeev Suraski wrote: Hmm, because he's bigger? :) I can live with that :) Peace through superior firepower? That's a trademarked american concept at the moment, I think. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision (was: libxml bundling)
On Sun, Jun 02, 2002 at 12:17:34AM +0300, Zeev Suraski wrote: The ease of PHP - one of its biggest advantages is also one of its biggest disadvantages. IMHO. Do you mind elaborating on that?? I think we should hash out this issue as soon as possible, because if people have a vision of turning PHP into a language which is hostile towards newbies, then there's a serious lack of consensus in our team. Furthermore, if you think that we should not strive to make it even easier for people to get started, forever, then we have a strong disagreement as well. I think that PHP should be only as newbie hostile as security dictates (register_globals off and similar stuff). It should be as convenient and easy to use as possible. It should also provide hooks and means to reconfigure it manually for those people who want to outgrow PHP, or want to run a cleaner language. That is, there really should be options that turn on stricter variable checking, stricter handling of objects. And there should be deployment models that enable more demanding programming styles. And these should NOT be default. Those who want them will be able to enable them. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision
On Mon, Jun 03, 2002 at 02:38:50PM +0800, John Lim wrote: Let me explain. I'm developing extranets with PHP and occasionally I get a checklist of required features from a customer. Features such as: - clustering, - management of server farms, - transparent fail-over, - load balancing - application deployment without restarting server - advanced queueing - database connection pooling I believe that many of these features should probably not be part of the language, Most of these are features of the deployment model, not the language. That's part of the problem: Since PHP 3, development has (publicly) concentrated on the language and language features. The deployment model has changed slightly, adding a lot of SAPIs, but not fundamentally - SAPIs manage variables and state like they always did. Also, Zend added some very important things with their Cache, which has been duplicated partially outside Zend. I believe the things that you list above are very important, as important or even more important that the language level changed for PHP 5/ZE2. The issue is, little is being done into this direction at the moment, with SRM being the only project focussing on that. Someone has asked for a vision for PHP, and it might me that... Does this mean that when i become more successful and get larger clients with Enterprise requirements I have to abandon PHP and switch to Java or MS.NET? I hope not. Unless PHP adresses this issue explicitly and publicly: Yes, you will have to switch. Sad. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision
On Mon, Jun 03, 2002 at 04:44:05PM +0800, John Lim wrote: We might not want people to fiddle around with the internals of a class, for example an authentication class which holds the passwords of users. Even if the whole web site is Zend Encoded, doing a var_dump on $GLOBALS will reveal a lot about .the site. Private variables and private functions are not a security tool. They enforce (partially) a contract between the producer and the user of a class. They also have big design problems, which ultimately lead to a lot of more, and more complicated issues (friend, protected and the like, debugging problems and so on). Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
On Fri, May 17, 2002 at 03:46:42AM +0300, Zeev Suraski wrote: In a perfect world, ISPs would have used chroot'd environments always, running either CGI's We do. On earth. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
Am Dienstag, 16. April 2002 18:23 schrieb Dave Mertens: And that's the problem. PHP isn't promoted anymore. Not in the way .NET and Java are. 2 years ago i convinced my boss to use PHP, but these says MS and Java can do the same stuff as PHP. Only partially a problem with promotion. As I see it, neither Java nor .NET have a convincing deployment model in a shared (hosting) environment. PHP does run fine as a transient server (CGI, FCGI binary) or as a module with save mode. Every hosting offer (in Germany at least) does include PHP. So nearly all web applications running in a shared environment (and this is all small to medium business) is done in PHP. On the other hand it is useless to talk about a PHP object framework as long as PHP has to reinstantiate all thus puny little objects on each and every call to the application. The memory management overhead and initalization does in no way scale to justify such a framework. Ulf Wendel, Sebastian Bergmann and I did some uncoordinated ad-hoc research into this matter and came up all with the same results. PHP is missing a high-end deployment model, with SRM being a possible way out. Problem is, SRM is not mature enough for production, yet, is not being actively promoted enough and there should be even more development support behind it. And perhaps there should be talk about better ZE2/SRM integration. Only with a deployment model that keeps per-session object instances around between requests a larger object framework for PHP does pay off. Unless such a deployment model is well understood and common for PHP, the investment into a kind of PHP platform will not pay off sufficiently to justify work in this area. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] classes, instances objects in ZE2
On Mon, Apr 08, 2002 at 05:18:07PM +0200, Marcus B?rger wrote: In my book, private is only of very limited use, because there always must be a way around it. So that book is your own meaning. No, an english ideom. http://www.m-w.com/cgi-bin/dictionary?va=book - in one's book : in one's own opinion I wrote: Introducing private (in C++) immediately called for the introduction of protected and friend, with protected being a mechanism to break privacy along the lines of the inheritance hierarchy and friend being a mechanism to break privacy across inheritance hierarchies, at compile time. meaning: A private variable is encapsulated, not accessible from outside the class. This is often to strong a protection and therefore the introduction of private variables usually triggers the introduction of mechanisms to subvert this privacy, with protected and friend being such mechanisms, and with proctected working along the inheritance hierarchy and friend across it, and with both mechanisms working only at compile time. You rephrase this, acknowledging my definitions: Yes it does call for it. But please do not use break. A private method is a method that cannot be used for inheritance. Thus you cannot implement it another way in a derived class/object. A protected method is a method that can be used for inheritance but is not accessible from other classes. A friend is a method/class that is allowed to handle private/protected members of another class (here breaking could be used). I wrote: Since PHP does many things at run time which C++ does at compile time, there must be a mechanism to break privacy at run time, which makes it pretty pointless to have private variables in the first place. meaning: mechanisms that subvert privacy at compile time are not sufficient or adequate for a language which does many things at run-time. I believe we agree on this, but cannot find direct evidence for that in your comment - do we agree on this particular point? You comment: Does not because inheritance does not necessary have to be implemented at compile time. For example, using aggregate. This can be handled using the same words at runtime, too. I get this as meaning: It is a bad idea to encode attributes of variables such as scope, visibility and accessability into the name of a variable and it would be better to use keywords for this. I concur with that. Traditionally, PEAR used the _ prefix to mark nonpublic slots in classes due to the lack of better mechanisms. So private as a keyword is probably better suited than my suggestion of using _ as a prefix to a variable name. I'd rather go for a warning that is being triggered whenever I access $a-_slot, but not when I access $this-_slot (Access to private object member). I could suppress this warning by writing $a-_slot as $a-_slot instead. We could do this by issuing an error instead of a warning (and we should)! So how would we break privacy at run-time, then? The -prefix for statemens only supresses warning messages, but does not allow continuation after error. If accessing a private slot in an object the regular way throws an error, we need a complete alternative syntax to be able to do this at run-time. I frown on this, because it adds a lot of complexity to the language. Issuing a warning instead allows us to use the statement prefix to access private slots in a class where we explicitly intend to do this, and still get notification for all accidental accesses to private slots. As already mentioned above we could use friend or referring to the other OO discussion going on we could use aggregation to achieve this. So there is no need for get/Set_private(). protected and friend are commonly compile-time mechanisms, so they are not sufficient for us, unless you refer to an uncommon case where protected() and friend() are being used as functions on existing objects or classes in order to modifiy accessibility attributes after object instantiation. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
On Tue, Apr 09, 2002 at 12:11:11AM +0300, Zeev Suraski wrote:
Having both makes very little sense. Compile-time vs.
run-time in PHP doesn't make any real difference as far as
functionality goes, because the stages are linked together
immediately.
Not the point here. In
class D extends A, B, C ...
the class names are static (determined at compile-time). In
$classes = array(A, B, C, D);
$d = new Object; // Object is an empty class.
foreach($classes as $c) {
aggregate($d, $c);
}
the class names are variables, and in fact, aggregate could and
should take an array as well as a string as the second parameter
in the first place.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
On Mon, Apr 08, 2002 at 02:44:14PM -0700, brad lafountain wrote:
for($i = 0;$i 1;$i++)
{
$d = new a;
aggregate($d, b);
aggregate($d, c);
$d-method();
}
That is
$d = new A;
aggregate($d, array(B, C));
for ($i=0; $i1; $i++) {
$d = copy $a;
$d-method();
}
in PHP, with aggregate() taking the array syntax suggested by
me, and copy being to instances what new is to Classes (copy
constructor). As you can see, it is a direct match to your code
for($i = 0;$i 1;$i++)
{
$d = new d;
$d-method();
}
(but $d is already initialized properly in my example, and then
copied, whereas you run 1 initializations).
I currently am trying to talk my company to use php over
java. This is a huge project. The company i work for has 22000
employees and probally 500-1000 developers across us (mainly).
And in desiging our classes i can see where i could use MI.
and im not about to go and tell all 500 developers that
evertime you create an instance of x you need to aggerate y.
You don't. There is no need.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Aggregation, Multiple Inheritence, pros/cons
On Mon, Apr 08, 2002 at 08:57:09PM -0400, fabwash wrote: My vote is java like: no MI, no aggregation, single inheritence and use of interfaces :) Could you please explain how interfaces promote code reuse? I am not the perfect java pro, and as I understand it, interfaces define a set of instance variables and methods that must be there in order to be compliant to an interface, but provide to way to import an implementation of such an interface into an existing class. Objective-C had interfaces, which were in fact such lists of instance variables and methods, and it had categories, which could be implementations of interfaces which could then be imported into a class (but could be used in other ways as well). Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggregate() und overload()
On Mon, Apr 08, 2002 at 11:49:23AM -0500, Andrei Zmievski wrote:
__get_x() is simply a shortcut, I don't see how it can
backfire on us in the overload framework.
Nor can I, at the moment.
But then, nobody did see how variable constructor names could
possibly backfire on us with a concrete example, nor were
registered globals generally considered a bad idea when they
were introduced.
I just want it on record that I have the same bad feeling as
with variable constructor names right now with __get_x(). And I
suggest a different method of implementing your desired
behaviour which gives you more control about how the namespace
is being used. There are at least two I can come up with:
1. You register the property handlers and call wrappers with
overload or within the ctor. That would be a three-tuple
(slot, getter name, setter name) for properties, and a pair
(slot, wrapper name) for instance functions. Or you declare
them, using a more static syntax, if this is too dynamic for
you:
class A {
private $a;
getter function __get_a() {
return $this-a;
}
setter function __set_a($v) {
$this-a = $v;
}
2. You name the instance variables and methods to be handles
specially when calling overload(), but do not allow
for user specified names.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] classes, instances objects in ZE2
On Tue, Apr 09, 2002 at 11:11:58AM +0200, Marcus B?rger wrote:
Keywords are better then implicit definitions.
Agreed.
I would like to have private, protected and public which can
be easily done by adding one single flag to the members of an
object.
So how would you set or reset these flags at run-time?
With friends implementation may be much harder because each
class or even object has to have a friends list.
Why would friend be necessary in the first place, when you
simple could
class A {
private $slot;
}
class B {
function do_with_an_A($someA) {
$someA-slot = 10; // I know it is private and I intend to break it.
}
}
friend is just a compile-time declaration of a list of classes
for which you intend to break privacy, and if you can to it
anyway at run-time, you do not need such a declaration.
protected and friend are commonly compile-time mechanisms, so
they are not sufficient for us, unless you refer to an uncommon
case where protected() and friend() are being used as functions
on existing objects or classes in order to modifiy accessibility
attributes after object instantiation.
Why are they not sufficient?
Because, again, they require a complete and finished declaration
of privacy breakage at compile time. That is lacking dynamism,
and for some more advanced applications such breakage at
run-time would be extremely handy.
There is nothing that forbids us to save information generated
for the compiler tree into our classes/objects and using them
at run time.
using would not be enough here, modifying or ignoring
would be called for.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] aggregate() und overload()
On Tue, Apr 09, 2002 at 12:23:57PM +0300, Zeev Suraski wrote:
For the record, the advantages and disadvantages of variable name
constructors were clear from day one,
Nonetheless they were seriously broken in PHP 3, and
class __get {
function __get() {
echo I am a constructor\n;
}
}
class Bomb extends __get {
}
overload(Bomb);
$bang = new Bomb;
still stands.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggergate vs MI
On Mon, Apr 08, 2002 at 08:59:39AM -0700, brad lafountain wrote: class A; class B; class C; $c = new C; aggergate($c, A); aggergate($c, B); Just because they can. Yes of course, but how is this better than class D extends A, B, C; $d = new D; for the same reasons (i.e. because you can as opposed to it makes sense???) Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] aggregate() und overload()
I have several observations regarding the newly implemented
aggregate() und overload() extensions. Depending on the
correctness of these observations you may want to reconsider the
inclusion of these extensions in the current build of PHP.
The following has not in its entirety verified in the source and
may be incorrect or incomplete. Please correct me.
Situation:
$obj = new Origclass; aggregate($obj, Classname); is a
function which adds all instance variables and methods from
class Classname to an object $obj of an original class
Origclass. There are variations of aggregate which allow you to
add instance variables and methods selectively by enumeration
and regex.
Observation:
aggreate and friends break the introspection in PHP, and may
interfere with serialization and sessions. This is, because
get_class($obj) returns Origclass, and no trace of Classname.
Also, $obj is_a() Origclass, but not is_a(Classname), leading to
serialization of $obj as a pure Origclass, and reinstantiation
as a pure Origclass with no methods from Classname at all.
This is the situation of serialize() in PHP 3 at a slightly
elevated level. Reminder: In PHP 3, serialize() did not record
the class of an object on serialization, and unserialize()
consequently produced an object with no methods at all, which is
in fact quite useless.
Also, because of the fine grained nature of the more advanced
variations of aggregate, there is no fast way to describe the
class or type of an object instance. The only way to completely
describe an object is to completely enumerate its instance
variables and instance methods. Essentially, get_class and
friends become meaningless.
Alternative:
aggregate is a badly designed way to introduce multiple
inheritance like functionality. There are at least two tested
ways to implement MI functionality. Statically typed languages
such as C++ set type == class and implement pure MI. Regarding
PHP, this would lead to
class C extends A, B { ... }
with the order of A and B being important. Also,
get_parent_class() would need to be modified to return
inheritance level information or inheritance graph information
together with class names in order to produce meaningful
information. Something like
$v = get_parent_class($complicated_object);
$v would be
array(A = B, B = C, B = D);
for
class A extends B ...
class B extends C, D ...
An alternative, possibly cleaner way would be the introduction
of interfaces and categories. In this scenario we keep single
inheritance. We introduce declarations of interfaces, which may
contain a number of instance variables and functions. Interfaces
are a simple declaration of these, there is no implementation at
all in an interface.
A class may claim conformity with an interface. This means that
the class at least has all the instance variables the interface
demands and has at least implementations for all member
functions of the interface. The class may implement all this
independently or it may import a category.
A category is class-subset, and always an implementation of an
interface (you cannot define a category for which no interface
definition is being known).
Interfaces and Categories are found in some dynamically typed
languages, sometimes under slightly different names. They
separate type and class, and in order for them to function in
PHP we would need enumerative functions and predicates to
complement the new language constructs (get_defined_interfaces(),
get_defined_categories(), conforms_to($interface_name)).
Recommendation:
As-is aggregate() is a broken design, and will break existing
older functionality. It will create a number of support issues,
and later backward compatibility issues. It may inspire even
more broken fixes for these issues, effectively uglifying the
language itself or at least its object system.
The best would be to remove aggregate() completely, and bury it.
It should be replaced by a proper MI system, probably one for a
dynamically typed language, as PHP is such a language.
If aggregate() functionality is being used right now, and is
critical, it should be kept, properly documented, the drawbacks
spelled out in all its ugliness and its use strongly
discouraged. It should be clearly marked as obsolete from day 1,
and may be removed at any time. If someone uses this feature
despite the warning labels, this person deserves everything that
happens.
Situation:
The overload() extension allows userland code to intercept get,
set and call operations on the instance variables and instance
functions of an object. It does this by defining the special
fixed name functions __get, __set and __call in a class, which
are enabled by calling overload() on this class.
It also allows, according to Sebastian Bergmann, and in spite of
the current documentation at
http://www.php.net/ref.overload.php, __get_x(), __set_y() and
__call_x() functions in order to intercept accesses and calls to
instance variable x and
Re: [PHP-DEV] aggregate() und overload()
On Thu, Apr 04, 2002 at 03:06:30PM -0800, Shane Caraveo wrote:
Recommendation:
If overload() indeed supports variably named callback functions
such as __get_x(), support for this should be removed in order
to avoid a number of possible inconsistencies and namespace
pollution.
Yes it does support it. No it shouldn't be removed. Why not explain
the problems you perceive.
1. Variant:
class A {
function __get_x(...) {
}
}
class B extends A {
}
overload(B);
Does A::__get_x() magically become an automated callback in B?
When A was written, it was obviously never intended to be one.
How is this being handled?
2. Variant:
class C {
...
}
overload(C);
$c = new C;
aggregate($c, A);
Again, does A::__get_x() magically become an automated callback
in C? How is this being handled?
Generally speaking, automated callback functions such as
constructors, destructors, getters, setters and wrappers should
never have variable names. They shall use only a small and
clearly defined part of the namespace. All kind of strange
things happen, if you inherit, aggregate or MI such functions.
When you are using constant names for such functions, at least
defining them in your derived class will for sure overwrite and
contain any inherited behaviour and you will know that you are
clean and operate in a controlled namespace.
We have had this with PHP 3 constructors running wild, we had
this with PHP FI, 3 and 4 poisoning the global namespace, and we
really should /not/ make this kind of mistake again.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mon, Mar 25, 2002 at 09:44:00PM +0100, Edin Kadribasic wrote: Are you sure you were testing it with CLI? Header hiding (-q) has been in there since the first check-in back in Jan 6. This is good. I have tried to compile a list of things I would like to see in php-cli, and haven't checked yet which of these are already there. I came up with - automatic -q mode enabled - php honoring -- as end of options as required by getopt so that #! /usr/bin/php ... -- can be written and works as expected, even if somebody names his script -i or something. - no html in error messages or warnings - php reading /etc/php-cli.ini, $HOME/.php.ini unless $PHPRC suggests something different. ./.php.ini and ./php.ini not read, unless . is put in $PHPRC path. - safe_mode'ish features off or even disabled, since they make no sense in cli. - gpc variables not registered, argc/argv honored - error logging to stderr, not to syslog or other target. - sensible php.ini default installed with no execution time limit and memory limit. This list is not complete, it is just what comes to mind immediately when thinking of cli-ifying php. Also, I wonder how starting PHP in HTML-mode relates to CLI usage, but I believe this would break to many things. - #! /usr/bin/php -- Hello world - Hello world program in php-cli, starting in HTML mode. - #! /usr/bin/php -- ?php echo Hello world; - The same, as of now, using actual PHP facilities - #! /usr/bin/php -- echo Hello world; - What someone would expect from a scripting language. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Tue, Mar 26, 2002 at 01:31:56AM -0800, Rasmus Lerdorf wrote: This comes up every now and then and I believe it would be a mistake to change the startup mode. I should be able to take any .php file and run it through php-cli normally and vice-versa. Having, in essence, two different file formats is not a step forward in any way. Complete agree here. This is the sensible thing to do, albeit somehow aethetically disturbing. :-) Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] easter eggs?
On Wed, Dec 19, 2001 at 04:38:45PM +0100, Robin Ericsson wrote: phpinfo.phtml?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 ^- who the hell is this guy? :) I believe this is Thies. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] namespaces ambiguity
On Mon, Oct 01, 2001 at 01:06:05PM +0200, Marc Boeren wrote: If that is impossible, how about some new combination, like : HTML:Table looks ok, too... Some languages use quotes like ' or ` to indicate namespaces. Since the context in question may not allow the start of a string constant anyway, I don't see a problem with this, as in HTML'Table or similar constructs. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Patch to ext/pdf/
Access denied: Insufficient Karma (kk|php4/ext/pdf)
cvs server: Pre-commit check failed
cvs [server aborted]: correct above errors first!
So patch this yourself.
Kristian
? diff
Index: pdf.c
===
RCS file: /repository/php4/ext/pdf/pdf.c,v
retrieving revision 1.94
diff -u -r1.94 pdf.c
--- pdf.c 7 Aug 2001 17:26:30 - 1.94
+++ pdf.c 21 Aug 2001 12:38:28 -
@@ -81,6 +81,8 @@
PHP_FE(pdf_close, NULL)
PHP_FE(pdf_begin_page, NULL)
PHP_FE(pdf_end_page, NULL)
+ PHP_FE(pdf_get_majorversion, NULL)
+ PHP_FE(pdf_get_minorversion, NULL)
PHP_FE(pdf_get_value, NULL)
PHP_FE(pdf_set_value, NULL)
PHP_FE(pdf_get_parameter, NULL)
@@ -2245,6 +2247,29 @@
/* }}} */
+/* {{{ proto int pdf_get_majorversion()
+ Returns the major version number of the PDFlib */
+PHP_FUNCTION(pdf_get_majorversion)
+{
+if (ZEND_NUM_ARGS() != 0) {
+WRONG_PARAM_COUNT;
+}
+
+RETURN_LONG(PDF_get_majorversion());
+}
+
+/* {{{ proto int pdf_get_minorversion()
+ Returns the minor version number of the PDFlib */
+PHP_FUNCTION(pdf_get_minorversion)
+{
+ if (ZEND_NUM_ARGS() != 0) {
+ WRONG_PARAM_COUNT;
+ }
+
+ RETURN_LONG(PDF_get_minorversion());
+}
+
+/* }}} */
/* {{{ proto void pdf_delete(int pdfdoc)
Deletes the PDF object */
PHP_FUNCTION(pdf_delete)
Index: php_pdf.h
===
RCS file: /repository/php4/ext/pdf/php_pdf.h,v
retrieving revision 1.19
diff -u -r1.19 php_pdf.h
--- php_pdf.h 7 Aug 2001 17:26:32 - 1.19
+++ php_pdf.h 21 Aug 2001 12:38:28 -
@@ -42,6 +42,8 @@
PHP_FUNCTION(pdf_close);
PHP_FUNCTION(pdf_begin_page);
PHP_FUNCTION(pdf_end_page);
+PHP_FUNCTION(pdf_get_majorversion);
+PHP_FUNCTION(pdf_get_minorversion);
PHP_FUNCTION(pdf_get_value);
PHP_FUNCTION(pdf_set_value);
PHP_FUNCTION(pdf_get_parameter);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Linux Today Article
[ Brainstorm warning - these are relatively unsorted thoughts, and they have to be taken with heavy editing. -- KK ] [ Additional idea: Let us make this an online brainstorm. Please reply to this message only, do not reply to any replies at all for the next few days - no comments on other peoples ideas allowed at first, just idea collection. See my questions down below in the text, and answer them, then send your reply. Do not to try to be too friendly, too coherent and do not avoid provocation. We will have an integration session later, and see what comes out of this. -- KK ] On Thu, Aug 16, 2001 at 10:29:06AM +0200, Stig S?ther Bakken wrote: IMHO people like Zeev, Andi and Rasmus are the natural channels for such visions, but we're not quite there yet. They are. I was on the Future of Zend session with Zeev on Linuxtag and met Rasmus later, too. I proposed several ideas, but they are only fragments, not a complete concept - some of these ideas may be interesting, though. These need to be reviewed, integrated and then sold to the community. Then there is the other problem, that is, parts of the PHP community are still feeling uncomfortable with Zend, the license and/or other things surrounding these issues. This, too, is not helping in the process of creating a grand unified PHP theory. And finally - and this is just my personal view on things, the view of someone who is currently in the process of slowly gaining distance to PHP and beginning very different work - I think that some people I know personally have bet to much of their own lives on PHP and are beginning to have difficulties to see the fun side of all things PHP and tend to take such issues to seriously. I mean, PHP still is an Open Source project despite all the commercial undercurrents (companies selling addons, education or conferences) popping up all over the place - and I am very happy with that, because I strongly believe that this is the better way to develop software. Doing Open Source should be fun, in fact it must be fun in order to work. So tell us: Why do you develop PHP, the language, and where do you want to go with it? But for a vision to form we need to find a common ground for a few things. The LinuxToday article kept rambling about PHP not being a platform, which is true, it is but one of the components in such a platform. Yes. So what is the platform thing to you developers, which buzzwords, ideas, concepts and services relate to the platform, and how do they again relate to PHP. In technical marketese, how do you see the current market that PHP caters, and what market should PHP be catering in 3 and 5 years? Please let us make this a brainstorm session - send your ideas, perhaps roughly classify them as buzzwork, idea, concept, service, as plus or minus, as urgent or nice to have or send them in a free form format, as you see fit. Do not reply to other peoples ideas, and do not comment on them. Just think, take inspiration, and send your ideas. We will discuss them and integrate them later. Also, what is your vision - the 3 and the 5 year vision? Who will be using PHP, why will they be doing it, what will they be doing with it, and how will it be different from the situation today? And finally, what is services to you? How will they relate to PHP and what do we as developers need to do to enable them? Let's collect stuff, and see what we can make out of it. Kristian -- Kristian Köhntopp, NetUSE AG Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] The PHP brainstorm
I send this again, under a proper subject. You might want to use a slow Friday afternoon or the weekend to think about this, and write something up. Please do, we need your input. We will clean up not before Tuesday - see the instructions below. Kristian - Forwarded message from Kristian Koehntopp [EMAIL PROTECTED] - Date: Thu, 16 Aug 2001 11:07:47 +0200 From: Kristian Koehntopp [EMAIL PROTECTED] To: Stig S?ther Bakken [EMAIL PROTECTED] Cc: Kristian Koehntopp [EMAIL PROTECTED], Zeev Suraski [EMAIL PROTECTED], Blake Schwendiman [EMAIL PROTECTED], php-dev mailinglist [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Linux Today Article User-Agent: Mutt/1.2.5i In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Thu, Aug 16, 2001 at 10:29:06AM +0200 [ Brainstorm warning - these are relatively unsorted thoughts, and they have to be taken with heavy editing. -- KK ] [ Additional idea: Let us make this an online brainstorm. Please reply to this message only, do not reply to any replies at all for the next few days - no comments on other peoples ideas allowed at first, just idea collection. See my questions down below in the text, and answer them, then send your reply. Do not to try to be too friendly, too coherent and do not avoid provocation. We will have an integration session later, and see what comes out of this. -- KK ] On Thu, Aug 16, 2001 at 10:29:06AM +0200, Stig S?ther Bakken wrote: IMHO people like Zeev, Andi and Rasmus are the natural channels for such visions, but we're not quite there yet. They are. I was on the Future of Zend session with Zeev on Linuxtag and met Rasmus later, too. I proposed several ideas, but they are only fragments, not a complete concept - some of these ideas may be interesting, though. These need to be reviewed, integrated and then sold to the community. Then there is the other problem, that is, parts of the PHP community are still feeling uncomfortable with Zend, the license and/or other things surrounding these issues. This, too, is not helping in the process of creating a grand unified PHP theory. And finally - and this is just my personal view on things, the view of someone who is currently in the process of slowly gaining distance to PHP and beginning very different work - I think that some people I know personally have bet to much of their own lives on PHP and are beginning to have difficulties to see the fun side of all things PHP and tend to take such issues to seriously. I mean, PHP still is an Open Source project despite all the commercial undercurrents (companies selling addons, education or conferences) popping up all over the place - and I am very happy with that, because I strongly believe that this is the better way to develop software. Doing Open Source should be fun, in fact it must be fun in order to work. So tell us: Why do you develop PHP, the language, and where do you want to go with it? But for a vision to form we need to find a common ground for a few things. The LinuxToday article kept rambling about PHP not being a platform, which is true, it is but one of the components in such a platform. Yes. So what is the platform thing to you developers, which buzzwords, ideas, concepts and services relate to the platform, and how do they again relate to PHP. In technical marketese, how do you see the current market that PHP caters, and what market should PHP be catering in 3 and 5 years? Please let us make this a brainstorm session - send your ideas, perhaps roughly classify them as buzzwork, idea, concept, service, as plus or minus, as urgent or nice to have or send them in a free form format, as you see fit. Do not reply to other peoples ideas, and do not comment on them. Just think, take inspiration, and send your ideas. We will discuss them and integrate them later. Also, what is your vision - the 3 and the 5 year vision? Who will be using PHP, why will they be doing it, what will they be doing with it, and how will it be different from the situation today? And finally, what is services to you? How will they relate to PHP and what do we as developers need to do to enable them? Let's collect stuff, and see what we can make out of it. Kristian -- Kristian Köhntopp, NetUSE AG Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 - End forwarded message - -- Kristian Köhntopp, NetUSE AG Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Linux Today Article
On Thu, Aug 16, 2001 at 01:20:23PM +0300, Zeev Suraski wrote: I don't usually buy into long term visions, because they virtually never work. Microsoft changed its vision twice in the last 5 years, *completely*, from end to end. Sun (and the other Java followers) have also changed their Java vision several times during its short lifespan, also, from end to end. Agreed - and so did Perl, which I quoted as a compareable example, at least to a degree. But then, that was not entirely my point - of course the vision changes. I wrote As you can see in the case of Perl, the vision need not be final, useful or even true, it just needs to be cool, and believable. It is being used as a tool to bind the community tigther together, to provide hope and a sense of direction. and for this such a vision _is_ useful. It provides a frame that puts all the small actions and progress in a larger frame, and it provides a reference point so that you can verify the stated goals of your project against the daily reality. If they no longer match satisfactorily, you change course (and vision). The key points are _cool_ and _believeable_ _vision_. Cool in order to attract the proper audience. Believeable in order to motivate them, and the vision in order to provide the necessary sense of direction. The vision may sometimes be farther out than the actual goal - sometimes you need a longer baseline to align your ruler more accurately. The vision is a marketing tool. It is the ackowledgement that the current product has shortcomings, but expressed in the most positive form: We are working to remedy these, and we hope that we will be doing this until x and we plan to do it in the following way y. We invite you to participiate - if you are up to the task. We promise you hard work, but also a generally good time and an interesting experience. And besides, 'It's kind of fun to do the impossible.' (Walt Disney). This is - of course - bullshiting. People like to be bullshitted, it has to be done nicely, though. So the question still stands: Where do you see yourself in 3 to 5 years, where do you see PHP? What do you see in the terms platform and services? Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
