Ilia Alshanetsky wrote:
On 5-Nov-06, at 6:30 PM, Lester Caine wrote:
Ilia Alshanetsky wrote:
The language always has the best pick of namespaces, this is not just
PHP, but ANY language. The fact we've made a compromise and allows
PEAR to retain the date class IMO has been a horrible mistake
I guess it is a question of frequency, as a rule a valid use of
require/include on a URL is quite unusual. From my experience, I do not
believe the same could be said about smb.
How many apps really need to import includes from foreighn systems which
aren't mounted as drive letters? I don't th
On 5-Nov-06, at 6:30 PM, Lester Caine wrote:
Ilia Alshanetsky wrote:
The language always has the best pick of namespaces, this is not
just PHP, but ANY language. The fact we've made a compromise and
allows PEAR to retain the date class IMO has been a horrible
mistake, one hopefully not t
Hello,
On 11/6/06, Lester Caine <[EMAIL PROTECTED]> wrote:
Ilia Alshanetsky wrote:
> The language always has the best pick of namespaces, this is not just
> PHP, but ANY language. The fact we've made a compromise and allows PEAR
> to retain the date class IMO has been a horrible mistake, one ho
Ilia Alshanetsky wrote:
The language always has the best pick of namespaces, this is not just
PHP, but ANY language. The fact we've made a compromise and allows PEAR
to retain the date class IMO has been a horrible mistake, one hopefully
not to be repeated in the future.
I never used the PEA
Christian Schneider wrote:
> Well, almost: DateTime is a date class, not a time class.
Surely it handles both. A DateTime class encapsulates both date and
time information. Just look at the methods like setTime() and the
properties that it contains. I don't think it is badly named at all.
-Ras
Ilia Alshanetsky wrote:
And your point is what? There are even more rules you need to obey while
My point is: Fewer rules make things easier to learn and use.
Well, almost: DateTime is a date class, not a time class.
Actually it works with both date & time and calling it datedate seems
rat
On 5-Nov-06, at 1:22 PM, Stanislav Malyshev wrote:
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also
why break perfectly valid applications that perform operations on
networked file systems?
Well, it's the same as asking why break valid apps that per
On 5-Nov-06, at 1:32 PM, Christian Schneider wrote:
Ilia Alshanetsky wrote:
There are no "rules" there is just one rule, that's not even
specific to PHP when you think of it. It is generally considered
to be a good practice to prefix your code with app name or similar
to avoid conflicts w
Ilia Alshanetsky wrote:
There are no "rules" there is just one rule, that's not even specific to
PHP when you think of it. It is generally considered to be a good
practice to prefix your code with app name or similar to avoid conflicts
with other libraries and/or applications. When it comes to
Ilia Alshanetsky wrote:
>
> On 5-Nov-06, at 12:13 PM, Rasmus Lerdorf wrote:
>> The exact same argument could me made for a localhost
>> http or ftp include which we also disallow.
>
> For http allowing localhost access is dangerous simply because the
> person could make the script request itself
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on networked
file systems?
Well, it's the same as asking why break valid apps that perform
operations on URL. Because of security policy - i.
Hello Jeff,
Sunday, November 5, 2006, 7:09:26 PM, you wrote:
> On Nov 3, 2006, at 1:11 PM, Marcus Boerger wrote:
>> Liskov applies to static methods as soon as calls via objects are common
>> which is true for PHP. Actually in PHP static methods are inherited as any
>> other method (also true
On 5-Nov-06, at 1:13 PM, Christian Schneider wrote:
Hello Marcus, hello Ilia,
now you two got me confused:
Marcus Boerger wrote:
we have the same problem for functions since years, why is there
suddenly
such a big problem with classes now? All new php/pecl classes will
follow
one of the
Hello Marcus, hello Ilia,
now you two got me confused:
Marcus Boerger wrote:
we have the same problem for functions since years, why is there suddenly
such a big problem with classes now? All new php/pecl classes will follow
one of the following rules:
- Prefix with the extension name
- Postfi
On Nov 3, 2006, at 1:11 PM, Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are
common
which is true for PHP. Actually in PHP static methods are inherited as
any
other method (also true for a lot of other languages). Now given Liskov
rules you can as well
On 5-Nov-06, at 12:59 PM, Christian Schneider wrote:
c) and thus not having to educate users to use prefixes (to have
less guidelines is a Good Thing(tm) IMHO)
I am not even going to bother with this one.
So you don't think fewer rules are easier to learn and use? *puzzled*
There are no
On 5-Nov-06, at 12:13 PM, Rasmus Lerdorf wrote:
The exact same argument could me made for a localhost
http or ftp include which we also disallow.
For http allowing localhost access is dangerous simply because the
person could make the script request itself making a very nasty
request loop
Ilia Alshanetsky wrote:
On 4-Nov-06, at 11:55 PM, Christian Schneider wrote:
But my favourite solution would be to
a) have namespaces handling this issue
Not happening in 5.2 branch.
I know. I'm talking about a long term solution.
b) not introducing (many) more core classes before that
On 5-Nov-06, at 12:48 PM, Christian Schneider wrote:
Ilia Alshanetsky wrote:
When we were picking a name the discussion was public on this very
list and based on our analysis of what names people were using in
their application and what would be an ideal name DateTime was
picked.
I'm not
Hello Lester,
we have the same problem for functions since years, why is there suddenly
such a big problem with classes now? All new php/pecl classes will follow
one of the following rules:
- Prefix with the extension name
- Postfix with "Iterator"
- Postfix with "Exception"
that seems the same
Ilia Alshanetsky wrote:
When we were picking a name the discussion was public on this very list
and based on our analysis of what names people were using in their
application and what would be an ideal name DateTime was picked.
I'm not questioning this decision. I'm talking about the policy f
On 5-Nov-06, at 12:13 PM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on
networked
file systems?
We are only talking about marking them as is_url which doesn't
Ilia Alshanetsky wrote:
> What's to say /drive/smb or letter:// is not an SMB device? Also why
> break perfectly valid applications that perform operations on networked
> file systems?
We are only talking about marking them as is_url which doesn't have
anything to do with performing normal operati
( This should have been to the pigging list sorry Ilia )
Ilia Alshanetsky wrote:
You can use old PHP too, or modify the source code, it is "open
source" after-all.
Come on, that can't be the solution. Think about hosting companies for
example.
They as a rule use old versions, in fact
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on
networked file systems?
On 5-Nov-06, at 11:41 AM, Peter Brodersen wrote:
Hi,
On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals [EMAIL PROTECTED]
(Ilia Alsha
Hi,
On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals [EMAIL PROTECTED]
(Ilia Alshanetsky) wrote:
>> I think it's a fair assumption that a random host specified in that
>> way be treated as suspicious and lumped in under the
>> disable-includes-by-default category.
>
>What's random? Non localho
Hi,
At first I didn't think there would be an easy solution as it isn't
possible to distinguish between requests to a "local" SMB server and
an "outside" server. Both are network requests.
But on the other hand, requesting a file specific via network
protocols in PHP such as SMB or HTTP or FTP re
On 5-Nov-06, at 11:13 AM, Wez Furlong wrote:
I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.
What's random? Non localhost/127.0.0.1 ?
If someone discovers that it breaks their app
On 4-Nov-06, at 11:55 PM, Christian Schneider wrote:
But my favourite solution would be to
a) have namespaces handling this issue
Not happening in 5.2 branch.
b) not introducing (many) more core classes before that
They will continue to be introduced as needs for them appear.
c) and thus
On 4-Nov-06, at 11:21 PM, Christian Schneider wrote:
Ilia Alshanetsky wrote:
On 4-Nov-06, at 11:18 AM, Christian Schneider wrote:
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application
futureproof.
I'm still wary of this approach because it puts the burden on 99%
I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.
If someone discovers that it breaks their app, when they read the docs
for allow_url_include it should be made very clear what the
implica
I think it'd be wrong to consider networked file system as non-local.
Mostly because many times there are no ways to identify them reliable
and the fact this is a perfectly valid usage that if disallowed by
default would break a large number of applications.
On 4-Nov-06, at 4:12 PM, Peter
Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP.
This is common in PHP and you consider this good practice? Interesting,
wasn't what I would have expected...
I didn't say it is good practice, god behave :-)
So you're a
Hi Nuno,
Late reply, but I'm glad the idea was able to be used. :-)
To the other hash people: While checking how Ilia made implode() faster in
5.2, I think I found another optimization that can be done. In
zend_hash_copy/merge, it seems the zend_hash_quick_* functions can be used
instead for as
Ron Korving wrote:
- First of all, people use their classes a lot more than PHP core classes,
and so prefixing application classes is a big burden compared to prefixing
PHP core classes.
Its quite trivial .. all people need to do is stick a single underscore
into their class name [1]. Thats al
You can't rely on people prefixing their classes. In libraries, yes, but in
applications, don't count on it too much.
- First of all, people use their classes a lot more than PHP core classes,
and so prefixing application classes is a big burden compared to prefixing
PHP core classes.
- Second, wi
37 matches
Mail list logo
