Re: [PHP-DEV] 答复: [PHP-DEV] full LFS support
$code $complaints; On Tue, Aug 3, 2010 at 6:01 AM, Ferenc Kovacs i...@tyrael.hu wrote: Maybe this is just lost in the weekend's email swarm. At least I hope this is the reason for the silence. Tyrael On Tue, Aug 3, 2010 at 2:11 PM, 高春辉 gaochun...@gmail.com wrote: nobody to care this change? :( -邮件原件- 发件人: tyr...@gmail.com [mailto:tyr...@gmail.com] 代表 Ferenc Kovacs 发送时间: 2010年7月30日 22:14 收件人: PHP Internals 主题: [PHP-DEV] full LFS support Hi. I would like to know what is the current status of the LFS support for php. http://bugs.php.net/bug.php?id=27792 http://bugs.php.net/bug.php?id=48886 As far as I can see, there are some patches floating around, but some of them doesn't work, some of them are incomplete. As far as I can see, with the latest release(5.3.3) you can't stat or filesize a file where the size is = 2GiB on 32bit OS, and = 4GiB on 64bit. Is this true? From the proposed patches, it seems that there arent that many LOC which needs to be adjusted to provide a decent LFS support. Are there any blocker objections or architectural problems, or we just lack specification or manpower to fix this issue? If this gets fixed, will this be included into the 5.3 branch, or this can only be added with the next major version? Tyrael -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 答复: [PHP-DEV] full LFS support
Sorry: $code $complaints; 2010/8/4 Ronald Chmara rona...@gmail.com: $code $complaints; On Tue, Aug 3, 2010 at 6:01 AM, Ferenc Kovacs i...@tyrael.hu wrote: Maybe this is just lost in the weekend's email swarm. At least I hope this is the reason for the silence. Tyrael On Tue, Aug 3, 2010 at 2:11 PM, 高春辉 gaochun...@gmail.com wrote: nobody to care this change? :( -邮件原件- 发件人: tyr...@gmail.com [mailto:tyr...@gmail.com] 代表 Ferenc Kovacs 发送时间: 2010年7月30日 22:14 收件人: PHP Internals 主题: [PHP-DEV] full LFS support Hi. I would like to know what is the current status of the LFS support for php. http://bugs.php.net/bug.php?id=27792 http://bugs.php.net/bug.php?id=48886 As far as I can see, there are some patches floating around, but some of them doesn't work, some of them are incomplete. As far as I can see, with the latest release(5.3.3) you can't stat or filesize a file where the size is = 2GiB on 32bit OS, and = 4GiB on 64bit. Is this true? From the proposed patches, it seems that there arent that many LOC which needs to be adjusted to provide a decent LFS support. Are there any blocker objections or architectural problems, or we just lack specification or manpower to fix this issue? If this gets fixed, will this be included into the 5.3 branch, or this can only be added with the next major version? Tyrael -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ArrayAccess::offsetGet not returning a ref
Hey all, Was there any more discussion on this? I've been bit by this as well, several times over the past 3 years. I'd opt for option (d) for all prototype/signature checking. Here's why: I don't think the return type should be considered part of the signature when enforcing LSP. PHP (currently), does not care what the type of the return value is, much less if there is even one to be returned. Whether or not it is a reference or a value should not impact the conditions presented to the caller, in other words the preconditions are not strengthened in a subtype. Since PHP does no enforcement of return values, postconditions don't seem to apply. Also, relaxing the checks would be backwards compatible. Since no code should currently exist that does this (its an E_FATAL currently if the signature originates in an interface, E_STRICT notice when the signature originates in an abstract/base class overridden in a subclass). Thoughts? Ralph Schindler Johannes Schlüter wrote: Hi, On Tue, 2010-04-27 at 10:17 +0200, Etienne Kneuss wrote: it looks like the fact that ArrayAccess::offsetGet is not returning a reference is a recurrent problem, I see basically 4 options: The main use case is some nested structure like $o = new ArrayObject(); /*...*/ $o[23][42] = foobar; right? a) Ignore the issue, change nothing b) Rewrite offsetGet to return a ref, breaking BC c) Create a new ArrayAccess interface where it does return a ref d) Relax prototype checks so that both are allowed. If the above case is correct and due to me not liking references I wonder whether there is a way to for an option e) which adds support for this in some way to the engine. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
