RE: substr/array_slice in []

php.internals

Ford, Mike [LSS]

18 years ago
On 09 October 2007 08:18, Antony Dovgal wrote:
> On 09.10.2007 10:57, Alexey Zakhlestin wrote: > > > How come? > > > It looks like you're reading $bar[':5'], but forgot the quotes. > > > On the other side, what could be easier than a function call? > > > > operator is definitely easier because it lets us reuse the same > > syntax for strings and arrays (and people would need to learn one > > operator instead of 2 functions and 2 different concatenation > > operators) > > Yes, I see this quite often in the list: "let's invent a new thing > instead of an old thing, that would make peoples' life easier". > > But you forget that both the old and the new thing would co-exist > and people would have to learn BOTH, which definitely doesn't make > any life easier.
You have to be joking!!! People would only *have* to learn one -- whichever they prefer to use. You'd get some people routinely using one, and others routinely using the other -- but *all* of them would be happier using the version they prefer, instead of half of them being pissed off at having to use a crappy unreadable function call instead of a nice, readable alternative syntax. (Just MHO, of course.) Variety is the spice of life, after all! Cheers! Mike --------------------------------------------------------------------- Mike Ford, Electronic Information Services Adviser, JG125, The Headingley Library, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: m.ford@leedsmet.ac.uk Tel: +44 113 812 4730 Fax: +44 113 812 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

Antony Dovgal

18 years ago
On 09.10.2007 12:48, Ford, Mike wrote:
>> Yes, I see this quite often in the list: "let's invent a new thing >> instead of an old thing, that would make peoples' life easier". >> >> But you forget that both the old and the new thing would co-exist >> and people would have to learn BOTH, which definitely doesn't make >> any life easier. > > You have to be joking!!! > > People would only *have* to learn one -- whichever they prefer to use.
Well, if you live in a hole and never come out of it - yes. But when you start looking into other peoples' code.. bummer. Then you discover that your hosting doesn't use bleeding edge PHP version.. bummer. And then you open your old code and.. bummer.
> You'd get some people routinely using one, and others routinely using the other -- > but *all* of them would be happier using the version they prefer, instead of half of > them being pissed off at having to use a crappy unreadable function call instead > of a nice, readable alternative syntax. (Just MHO, of course.)
Right, so let's force other people to learn crappy unreadable syntax duplicating nice and clear function call. I believe our resources are too limited to spend them so carelessly. Instead of adding more and more new features, you'd better spend some time on debugging the ones we already have.
-- Wbr, Antony Dovgal

Stefan Walk

18 years ago
Antony Dovgal wrote:
> Right, so let's force other people to learn crappy unreadable syntax > duplicating nice and clear function call
Oddly, this "crappy unreadable syntax" doesn't lead to any confusion or complaints for newbies of languages like python or ruby, judging from the IRC channels. And it's also odd that ruby users, where String#[] is just an alias for String#slice, prefer this "crappy unreadable syntax" over a "nice and clear" method call. One starts to wonder ... Regards, Stefan

Scott MacVicar

18 years ago
Sure it works fine when it's been in the language for several years and it's guaranteed to be available in the version provided by your hosting company. In reality this isn't the case with PHP so everyone will end up using the older method to support backwards compatibility or mixing it and causing confusion. Scott Stefan Walk wrote:

Richard Quadling

18 years ago
On 09/10/2007, Scott MacVicar <scott@macvicar.net> wrote:
> Sure it works fine when it's been in the language for several years and > it's guaranteed to be available in the version provided by your hosting > company. > > In reality this isn't the case with PHP so everyone will end up using > the older method to support backwards compatibility or mixing it and > causing confusion. > > Scott
OOI. If the ISP is not on the version which would have this particular "feature", how would I create a fallback solution for my clients? Something like PEAR's PHP Compat library. Very useful for giving support to newer functionality. I think I wouldn't bother with the new feature for a while. Maybe if it was major version only (V5 vs V6 is nice and clean, but V5.2.4 vs V5.2.5 is not so easy for some clients to understand that new functionality - rather than bug fixes - requires an upgrade). But having a working method already seems redundant, simply for syntactic sugar.
> > Stefan Walk wrote: > > Antony Dovgal wrote: > >> Right, so let's force other people to learn crappy unreadable syntax > >> duplicating nice and clear function call > > Oddly, this "crappy unreadable syntax" doesn't lead to any confusion or > > complaints for newbies of languages like python or ruby, judging from > > the IRC channels. And it's also odd that ruby users, where String#[] is > > just an alias for String#slice, prefer this "crappy unreadable syntax" > > over a "nice and clear" method call. One starts to wonder ... > > > > Regards, > > Stefan
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"