RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Oh, goodness, deary me -- this sounded so familiar I just had to do some
delving and hey presto! I refer you to:
http://marc.info/?l=php-internals&m=124655821522388
(...which, interestingly, even predates Zeev's 2010 claim, and I believe may
have taken inspiration from yet earlier suggestions back around 2006!!)
--
Mike Ford, Electronic Information Developer, Libraries and Learning Innovation
Leeds Metropolitan University, 403a Sheila Silver Library, Leslie Silver
Building, City Campus, Leeds LS1 3ES, United Kingdom
Tel: +44 113 812 4730 | Email: m.f...@leedsmet.ac.uk
> -Original Message-
> From: Jocelyn Fournier [mailto:jocelyn.fourn...@gmail.com]
> Sent: 14 July 2014 14:30
> To: n...@devilix.net
> Cc: internals@lists.php.net; indey...@gmail.com; Andrea Faulds
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-
> opening)
>
> Hi,
>
> Le 14/07/2014 15:19, Andrey Andreev a écrit :
> > Hi,
> >
> > On Mon, Jul 14, 2014 at 4:12 PM, Alexey Zakhlestin
> wrote:
> >> Some people talk about inconsistency, which is introduced by
> reusing same syntax for "strict parameter types" and "scalar
> parameter casts”. There’s some truth there.
> >> Let’s use different syntax.
> >>
> >> This might work:
> >>
> >> function foo((int) $a)
> >> {
> >> var_dump($a);
> >> }
> >>
> >> I would read it as declaration-level casting
> >
> > I strongly support this.
> >
> > What we currently have with class/array typing is a different
> behavior
> > (regardless of the details behind it), and this syntax would make
> that
> > noticeable, which is a great thing.
>
> Actually both syntax could exists :
>
> function foo((int) $a)
> {
>
> => scalar parameter casts syntax
>
>
> function foo(int $a)
> {
>
> => strict type checking syntax (consistant with array / class
> syntax)
>
>
> I like this approach as well.
>
>
>Jocelyn
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
From 22 September 2014 Leeds Metropolitan University will become Leeds Beckett
University.
Find out more at http://www.leedsbeckett.ac.uk
To view the terms under which this email is distributed, please go to:-
http://www.leedsmet.ac.uk/email-disclaimer.htm
RE: [PHP-DEV] Operator precedence is undefined?
> -Original Message-
> From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of
> Yasuo Ohgaki
>
> Hi all,
>
> 2013/7/21 Sherif Ramadan
>
> > The problem is I'm not sure where this type of information should
> be
> > documented. It makes sense to put this on the increment/decrement
> operators
> > page, but doesn't seem appropriate the operator precedence page.
> So to make
> > sure we're all in agreement I'm suggesting the following language
> to be
> > added as a note on the increment/decrement operators page at
> > www.php.net/language.operators.increment with supplement examples
> > provided above to help users get a better understanding of what we
> mean
> > when we say undefined behavior and add an additional warning box
> not to
> > rely on this type of behavior.
> >
>
> Since the issue int "++$a + $a++" is not a precedence issue, but a
> evaluation orders and side effects. Describing it without complete
> explanation in precedence section makes users confuse. (I'm the one
> also)
>
> I partially agree that documenting the issue in
> www.php.net/language.operators.increment . It would better to be
> described
> fully in a section since it is not a increment/decrement only issue.
I agree with this, mostly. It might well be appropriate to document that,
as a general rule, there is no guarantee in which order the operands of
an arithmetic (at least) operator are evaluated. And you are quite right
that it's not only increment/decrement operators, although those are the
most obvious culprits. Take the following (very contrived!) example:
function f($n) { echo $n; return $n; }
$x = f(1) + f(2);
For the same reason that the ++$a + $a++ example is undefined, it's
undefined whether that will echo 12 or 21 -- even though it's perfectly
well defined that $x will be 3 in either case! For this reason, I'd
probably go with the major warning being on the precedence/associativity
table, with a prominent reference to it on the ++/-- page.
Just my £0.02!
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
403a Leslie Silver Building, City Campus, Leeds Metropolitan University,
Woodhouse Lane, LEEDS, LS1 3ES, United Kingdom
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] property de-referencing
I know I'm still somewhat of a beginner with OOP, and not at all into
large-scale OOP frameworks (yet!), but I'm really struggling to understand why
the existing & reference operator doesn't suffice for what you are after?
If you could explain in words of as few syllables as possible what you would
want to add to:
class User
{
public $name;
}
$user = new User;
$user->name = 'Rasmus';
$nameprop = &$user->name;
var_dump($nameprop); // => 'Rasmus'
$nameprop = 'Bob';
var_dump($nameprop); // => 'Bob'
I would be immensely grateful, as I might then stand a chance of deciding
whether I'm with you or agin you...!
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS, LS1 3HE, United Kingdom
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730
> -Original Message-
> From: Rasmus Schultz [mailto:ras...@mindplay.dk]
> Sent: 01 May 2013 13:35
> To: Rasmus Lerdorf
> Cc: Stas Malyshev; PHP internals
> Subject: Re: [PHP-DEV] property de-referencing
>
> >
> > This is a fringe feature, as evidenced by the fact that you
> > are having a hard time convincing people that it is needed
>
>
> As with anything that isn't already established and well-known, it's
> hard
> to convince anyone they need anything they don't understand - I
> think the
> barrier here is me having difficulty explaining a new idea/concept.
> That
> doesn't make it a fringe feature - I have already demonstrated by
> example
> how this would be useful in practically every mainstream framework.
>
> Properties simply don't carry
> > this information with them so a lot of things would have to change
> > internally for this to ever work
>
>
> I'm not sure what information you're referring to?
>
> Let's say for the sake of argument, I'm going to use a pre-processor
> to
> transform the following code:
>
> $prop = ^$user->name;
>
> var_dump($nameprop->getValue()); // => 'Rasmus'
>
> $nameprop->setValue('Bob');
>
> var_dump($nameprop->getValue()); // => 'Bob'
>
> The pre-processor output might look like this:
>
> $nameprop = new PropertyReference($user, 'name'); // $prop = ^$user-
> >name;
>
> var_dump($nameprop->getValue()); // => 'Rasmus'
>
> $nameprop->setValue('Bob');
>
> var_dump($nameprop->getValue()); // => 'Bob'
>
> Only the first line changes - the rest behaves and runs like any
> normal PHP
> code.
>
> And the PropertyReference class could be implemented in plain PHP
> like this:
>
> class PropertyReference
> {
> private $_object;
>
> private $_propertyName;
>
> public function __construct($object, $propertyName)
> {
> $this->_object = $object;
> $this->_propertyName = $propertyName;
> }
>
> public function getObject()
> {
> return $this->_object;
> }
>
> public function getPropertyName()
> {
> return $this->_propertyName;
> }
>
> public function getValue()
> {
> return $this->_object->{$this->_propertyName};
> }
>
> public function setValue($value)
> {
> $this->_object->{$this->_propertyName} = $value;
> }
>
> // and maybe:
>
> public function getReflection()
> {
> return new ReflectionObject($this->_object);
> }
> }
>
>
> You can see the above example running in a sandbox here:
>
> http://sandbox.onlinephpfunctions.com/code/87c57301e0f6babb51026192b
> d3db84ddaf84c83
>
> Someone said they didn't think this would work for accessors, so I'm
> including a running sample with a User model that uses accessors:
>
> http://sandbox.onlinephpfunctions.com/code/f2922b3a5dc0e12bf1e6fcacd
> 8e73ff80717f3cb
>
> Note that the dynamic User::$name property in this example is
> properly
> documented and will reflect in an IDE.
>
>
> On Tue, Apr 30, 2013 at 8:43 PM, Rasmus Lerdorf
> wrote:
>
> > On 04/30/2013 05:17 PM, Rasmus Schultz wrote:
> >
> > > If the asterisk (or some other character) offers and easier
> > > implementation path, whatever.
> >
> > It doesn't. This is a fringe feature, as evidenced by the fact
> that you
> > are having a hard time convincing people that it is needed, and
> thus
> > shouldn't overload an existing operator. Visually it would be
> confusing
> > to take any well-known operator and give it a different obscure
> meaning.
> > But yes, syntax-wise ^ could be made to work, the implementation
> problem
> > I referred to is lower-level than that. Properties simply don't
> carry
> > this information with them so a lot of things would have to change
> > internally for this to ever work and if a clean implementation
> could be
> > found, like I said, adding it to the reflection functions is the
> proper
> > place.
> >
> > -Rasmus
> >
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development M
RE: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
> -Original Message-
> From: Clint Priest [mailto:cpri...@zerocue.com]
> Sent: 28 October 2012 16:03
>
> So... to be explicit here, you think in this situation:
>
> class a {
>public $b {
> set($x) { $this->b = $x; }
>}
> }
>
> $o = new a();
>
> if(!isset($o->b)) {
>/* delete files */
> }
> echo (int)isset($o->b); /* This should return false and not emit
> any
> sort of warning/notice? */
>
> I mean specifically, there is no getter defined, therefore the
> result
> if isset is indeterminate
I've been holding back from the accessors discussion as I'm hovering
around -0 on the whole thing, but this one is really very simple and
obvious as far as I'm concerned: no getter, means no value, means not
set, means isset() returns FALSE. Also, the description of isset()'s
return value (at http://php.net/isset) is "Returns TRUE if var exists
and has value other than NULL, FALSE otherwise"; this would also seem
to mandate returning FALSE (since a property with no getter effectively
would not exist in a "get" context).
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS, LS1 3HE, United Kingdom
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] Re: Generators in PHP
> -Original Message-
> From: Andrew Faulds [mailto:a...@ajf.me]
> Sent: 25 July 2012 18:03
[...]
> Fact: Adding a new name for a special kind of function as a syntax
> construct is going to cost (possibly unnecessary) time and energy,
> because now you have functions, and weird things that look almost
> like
> functions but aren't and can only be used to make generators.
That looks to me like a perfect argument *in favour* of the
"generator" keyword! I'm a very literal kind of person, and I would
absolutely want "weird things that look almost like functions but
[...] can only be used to make generators" to be clearly labelled
as such without having to hunt through the body of the not-quite-
function.
The signposting needn't even be as in-your-face as a generator
keyword (either instead of or in addition to function): I could get
behind a variation such as:
function f($x, $y) yields {
...
yield $z;
...
}
Or even (stretching a bit to re-use an existing keyword!):
function f($x, $y) return {
...
yield $z;
...
}
Although I like the concept of generators, I would be -1 for any
implementation that doesn't differentiate them in some way from
regular functions.
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS, LS1 3HE, United Kingdom
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: Re: [PHP-DEV] [DRAFT] RFC - array_column() function
> -Original Message- > From: Morgan L. Owens [mailto:pack...@nznet.gen.nz] > Sent: 25 June 2012 15:41 > > On 2012-06-25 04:19, Ralph Schindler wrote: > >> The term 'column' makes a lot of sense for PDO working with > database > >> columns, but there is no concept of a 'column' in the array > structure or > >> PHP as a whole, outside of database related functions. > > > > In the case of this addition, I do indeed like array_pluck as > well, as > > column feel like an overloaded term. > > > While casting around for other array_* names, I remembered that > array_keys() can take a second (and third) argument. With it, the > function returns all keys indexing a given value. > > What we're discussing here is basically a dual to that: return all > values indexed by a given key.[*] > > If the duality is continued, then what we get is > > array_values(array $input[, mixed $key]) I see what you're getting at, but in my opinion the WTF factor is too high on this one -- the change from inspecting the outermost elements to those a level down is too much to load on to a single extra parameter in my opinion. However, I do wonder if a related name may not be the way to go, since it is similar in that both are extracting values from the array -- perhaps: array_inner_values($array, $key); or array_subvalues($array, $key); Also, I wonder if there might be scope for multiple $key parameters, to extract values from defined positions at even lower levels, so that, for example: array_whatever($array, 'colour', 'orange'); would return all sub-elements addressed as $array['colour']['orange']; (Also, also: how would you see this proposal in relation to the one for array_part(), should some version of that gain approval?) Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Portland PD507, City Campus, Leeds Metropolitan University, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
> -Original Message- > From: Larry Garfield [mailto:la...@garfieldtech.com] > Sent: 24 November 2011 22:04 [... BIG SNIP ...] > If that doesn't change, then I rescind my previous panic attack. > > --Larry Garfield I echo that sentiment. On fuller review, I find a very high FUD factor in effect here, and on actually checking my codebase I find only 1 place where an additional is_array() *might* be needed (in several tens of kLOC!). Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Portland PD507, City Campus, Leeds Metropolitan University, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
> -Original Message-
> From: Gustavo Lopes [mailto:glo...@nebm.ist.utl.pt]
> Sent: 23 November 2011 22:31
>
> On Wed, 23 Nov 2011 21:06:09 -, Pierre Joye
>
> wrote:
>
> > The fact that we have reports here showing code not working
> anymore
> > because of this change tells me that it is a BC break. We can call
> it
> > a bug fix but it still breaks code out there for no real benefit
> but
> > edge case usages. We had this situation before, that does not help
> us.
> >
>
> I'd say for no benefit at all. Why would anyone ever want to take a
> string
> offset from a string that certainly has length 1? Except for taking
> satisfaction in this "improved consistency", I see absolutely no
> benefit.
>
> Up until now, it was deemed a useless but innocuous change. Now that
> we
> found it has pernicious side effects, we ought to revert it.
That's exactly my take on it. As far as I can see, if 5.4 is released
with this "fix" in, it will effectively be rendered a non-upgradable-to
version for most big projects.
For what it's worth (not much!), my two pennorth on this is that
whilst, like some others, I can see the marginal benefit of making the
behaviour consistent, I really don't think the change can be done in
one go. Given that this WILL break existing code (some of it mine :( ),
there needs to be a release where the usage generates an error message
- probably an E_WARNING, or maybe an E_STRICT - and an easy alternative
is provided. Since the simplest alternative way of performing the
necessary chained checks would seem to be:
if (is_array($arr) && array_key_exists('key1', $arr)
&& is_array($arr['key1'] && array_key_exists('key2', $arr['key2'])
...
)
which substitutes 2 function calls and 2 array accesses per dimension
for a single function call and 1 multi-dimensional array access, there has
to be scope for a function called something like array_offset_exists with
a signature like
array_offset_exists(array $array, mixed $offset, ...)
(Yes, I know, inconsistent argument order and all that, but)
so that people can have a chance to transform
isset($arr['key1']['key2']['key3'])
into
array_offset_exists($arr, 'key1', 'key2, 'key3')
before the full fix is put into place in a subsequent version.
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS, LS1 3HE, United Kingdom
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)
> -Original Message- > From: John Crenshaw [mailto:johncrens...@priacta.com] > Sent: 01 June 2011 23:00 > > Spot on. It has nothing to do with extra typing (and that sort of > design is part of what ruined Ruby). My fingers move plenty fast and > if extra characters make things more safe or more readable, I'll be > the first to sign up. In this case, however, the extra characters > just make things messy. > 1. The most readable format is pure JSON Matter of opinion. I don't agree. > 2. The most familiar format is pure JSON (because these same > developers are almost certainly already using it in their jQuery > code) Also matter of opinion, and of experience. Apart from the fact that my use of jQuery amounts to a few weeks out of a (mumble)-year programming career, no I don't use pure JSON for it - Javascript object literals, yes, but not pure JSON. > 3. The most compact format is pure JSON Um. Depends. I would tend to write 'a': 'b' in JSON, but 'a'=>'b' in PHP. But YMMV. > 4. The format most consistent with other languages is JSON Again, matter of experience. Last time I counted, I'd used upward of 30 different programming languages and dialects, some of which had very bizarre ways of representing things, and none of which (apart from Javascript!) used a JSON-like array-literal syntax. And, actually, I *want* my PHP arrays to look different from my Javascript/JSON arrays, especially as I might be looking at both as part of the same project -- I *want* a big data structure to scream "I'm PHP" or "I'm Javascript/JSON" at me, to help trigger my brain into the right programming mode. All of this is just IMHO, of course, and probably a lot more than my regulation 2 pennorth, but there you go. Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507 City Campus, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)
> -Original Message- > From: Michael Shadle [mailto:mike...@gmail.com] > Sent: 01 June 2011 21:37 > > On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye > wrote: > > > I modified the vote page, pls move your votes to the desired > syntax > > (or global -1) > > This is a good idea to group things like this. > > Back on the soapbox. All of this is just to reduce typing "array" (5 > characters) before things? Not here. For me, the shorter syntax is simply an order of magnitude more readable. I really don't care how much typing is involved -- if I were really that fussed, I'd simply set my editor to expand a nice short abbreviation (such as "ar", maybe) into array(). In fact, I might go do that right now, now that I've thought of it Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507 City Campus, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
> -Original Message- > From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of > Etienne Kneuss > Sent: 01 June 2011 01:57 > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux) > > +1 for a short array syntax. > > But only if you keep it consistent, PHP has always been using => for > key/val association, I don't see any reason to suddenly provide > "key": > "val", unless what you want is to confuse people. Hear, hear and hear, hear to that! ['a': 'b'] just feels completely un-PHP-like, and I'd be totally against it. If the desire is to have a "native" JSON syntax so that you can eval() imported JSON, then I'm completely anti that, too -- that's a case where I'd far rather be explicit and use json_decode(). And since, no matter how you slice it, you're never going to get a complete fit between native PHP structures and JSON encoding, I don't believe you should even try. I just can't see the problem with saying: PHP arrays (and maybe objects?) look like *this*, and if you want to import/export them from/to a JSON representation, there are functions to do it like *this*. This seems to be the perfectly sensible approach of other languages I've used recently (although my perl is somewhat out-of-date, and my python even more out-of-daterer and minimal at that!). Even ECMAScript is going down the route of explicit conversion with JSON.parse() and JSON.stringify() in ECMAScript 5! All in all, still +1 for [1, 2=>2, 'a'=>'b'], and -several million (for style) for any syntax involving colons. Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507 City Campus, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
> -Original Message- > From: Adam Richardson [mailto:simples...@gmail.com] > Sent: 08 April 2011 08:02 > > Indeed. > > The '?' character already is special, so using '??' seems like a > safe, > practical approach. However, I'd prefer maintaining the form of the > standard > ternary operator with the colon ($value = $var['bar'] ?? : 'Bar was > not > set'; // value ="Bar was not) so the '??' operator could be applied > in any > situation that one would normally use the standard ternary operator. > > // standard > $value = isset($a[$key]) ? $a[$key] : 'Not set'; > > // new ?? double ternary that performs isset check and omits second > expression > $value = $a[$key] ?? : 'Not set'; > > // new ?? double ternary that performs isset check and uses second > expression > $value = $a[$key] ?? strtoupper($a[$key]) : 'Not set'; > Like it! I would have proposed ??: for the isset() variant of ?:, and I think decomposing it into a full ternary operator in this way, with ??: as a degenerate variant, is brilliant. (Only downside is, people would have to stop referring to *the* ternary operator!) Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507 City Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Array Dereferencing
> -Original Message- > From: Jacob Oettinger [mailto:ja...@oettinger.dk] > Sent: 08 June 2010 14:09 > > On 08/06/2010, at 12.41, Johannes Schlüter wrote: > > > On Tue, 2010-06-08 at 12:23 +0200, Jacob Oettinger wrote: > >> Would it be equally simple to allow the syntax below? > >> > >> $result = new ResultMaker()->getIt(); > > > > does this mean > > > >$result = new (ResultMaker()->getIt()); > > > > or > > > >$result = (new ResultMaker())->getIt(); > > > > I assume the later, but that is non-obvious as we allow > > > >$result = new $class(); > > Yes the later. I do not see how the above makes it non-obvious. I think the only problem with deciding which it means is that -> and () are not defined as operators in the PHP documentation, and as such do not have a clearly-defined precedence and associativity. In Javascript, "." (property access) and "()" (function call) both appear in the operator precedence table, so there are definite rules for ascertaining the meaning of such a construct. Up until recently this probably hasn't really been a problem, as it's not been possible to write constructs that needed these rules to decipher them. However, with the previous addition of object access chaining, and now array dereferencing, the time has almost certainly come to add -> and () to the operator documentation, with appropriate precedence and associativity. (Incidentally, other operators which are not documented in the "Operators" section, and probably should be, include :: (which *is* described in the "Classes and Objects" section as the "Scope Resolution Operator", and \ (namespace separator).) Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507, Civic Quarter Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Turkish/Azeri locale support
> -Original Message- > From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf > Of Adam Harvey > Sent: 04 May 2010 13:15 > The options are: > > 1. Apply Tomas's patch to make case-insensitive lookups > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > case-insensitive function/method name lookups for high-bit > characters > in single-byte encodings. (Not that we've ever advertised or > documented that.) > > 2. Make function/method names case-sensitive, per Stan's e-mail. > Pros: > fixes problem; brings PHP into line with most other languages; extra > consistency with variables; possible performance improvement. Cons: > BC > break from current documented behaviour. > > 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to > annoy Turkish and Azeri developers and those developing for those > locales. Low karma here, too, but for what it's worth I'm for option 2. (I can never remember what's case sensitive and what's not, so I always write code that would work either way anyway!) Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507, Civic Quarter Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] reference caller object
> -Original Message- > From: Richard Quadling [mailto:rquadl...@googlemail.com] > Sent: 18 September 2009 10:43 > > Considering we have func_get_args(), maybe func_get_caller() would > be > a nice fit. > > I don't like the idea of a constant (CALLER) which changes value as > you move around the code. Quite obviously, it isn't constant! Well, that sounds like a pretty good definition of a "magic" constant, so maybe __CALLER__ might be appropriate as well? Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507, Civic Quarter Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] Re: Flexible type hinting
> -Original Message- > From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] > Sent: 02 July 2009 14:05 > To: Ilia Alshanetsky > Cc: Paul Biggar; PHP Internals; Derick Rethans; Stanislav Malyshev; > Hannes Magnusson > Subject: Re: [PHP-DEV] Re: Flexible type hinting > > > On 02.07.2009, at 15:02, Ilia Alshanetsky wrote: > > > Personally, I am uncertain about +int or -int in general, IMO that > > compromise will eventually be identical to numeric an cause > endless > > confusion for the users between (+/-)int and int. The reason I > used > > a completely different name is to prevent confusion. > > > I do not see the risk for confusion as being high. > Like I said, I havent made up my mind on this proposal, however for > now Paul mainly asked for feedback in the general concept, not > necessarily on the syntax. Interesting discussion. Not sure where I stand on this one, but I definitely don't like the [+-]int syntax. Even before Paul's proposal came out, though, I was thinking that I'd want to consider leveraging an existing well-understood syntax, so I could write function func(int $i) for strict type checking, and function func((int)$i) for coercion aka casting (although now I've seen it written down I'm not so sure! ;). I don't see the need for another option beyond the current syntax/behaviour -- in my opinion, anything else is documentation and should be treated as such. Cheers! Mike -- Mike Ford, Electronic Information Developer, C507, Leeds Metropolitan University, Civic Quarter Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Short syntax for array literals [...]
On 28 May 2008 08:20, Derick Rethans advised: > Right, and I will add immediately to my coding standard that this is > forbidden to use. As is, of course, your right -- just as it would be mine to immediately add to my coding standards that it is compulsory! +1 (my irrelevant personal opinion being that it is elegant, expressive and highly readable ;) Cheers! Mike -- Mike Ford, Electronic Information Developer, C507, Leeds Metropolitan University, Civic Quarter Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Traits for PHP
On 19 February 2008 21:03, [EMAIL PROTECTED] advised:
> Hi Marcus,
> Hi Troels,
>
>> The biggest issue I see is finding a syntax everyone likes.
> Well, lets try some variations.
>
> [2a] ! is not readable --> except
> use Trait {
> except foo1, foo2;
> bar => foo1
> }
>
> [2b] ! is not readable --> without
> use Trait {
> without foo1;
> without foo2;
> bar => foo1;
> }
>
> [Aa] Aliasing is not obvious
> use Trait {
> bar is foo1; //aliasMethod is method
> }
>
> [Ab] Aliasing is not obvious
> use Trait {
> bar from foo1; //aliasMethod from method
> }
I may be completely off base with this suggestion, but how about
something as simple as "not" and "as" (which also has the advantage of
not requiring new keywords!):
use Trait { not foo1 }
use Trait { foo1 as bar }
Although I can see how this might be considered a touch ugly:
use Trait { not foo1; foo1 as bar }
--
Mike Ford, Electronic Information Services Adviser,
JG125, The Headingley Library,
James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Array syntax []
+1 for (b) FWIW 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: [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
On 07 December 2007 17:36, Gregory Beaver wrote: > The suggestion to make "namespace __php__;" implicit is very > interesting, but would defeat its purpose, which is to separate > declarations from use. Oh, I missed that little wrinkle -- I did say I was only skimming! I guess it could still be done, but at somewhat greater cost in the engine than I was imagining, which probably isn't worthwhile. 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: [EMAIL PROTECTED] 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
RE: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
On 07 December 2007 01:36, Gregory Beaver wrote: [...snip...] > In other words, 1 line of code is needed to take advantage of > namespace's full protection and ability to import conflicting class > names into the "global" (in this case unqualified, not > containing :: in > the name) scope, while at the same time preserving BC with > existing code > (no modification needed beyond addition of "namespace __php__;"). > > I recommend that the manual specify this convention, and will happily > take on the documentation of it. I've only been skimming the namespace argument, so forgive me if this is totally non-sensible, but if such usage is fully BC, and has only upsides with no downside, would there be any mileage in making it implicit rather than explicit -- i.e., any code not explicitly namespaced is automatically in the reserved namespace __php__? Such usage could be completely invisible to your everyday PHP user, and only need explaining in an intro to namespaces section. Cheers! Mike Mike Ford, Electronic Information Services Adviser, JG125, The Headingley Library James Graham Building, Headingley Campus Tel: extn 24730Fax: extn 23211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
RE: [PHP-DEV] Re: import/use last call
On 23 October 2007 19:57, Gregory Beaver wrote: > Giedrius D wrote: > > > > Anyway my main question was: is there any reason not to use > keyword "use"? > The only reason for me is that "use" implies some kind of autoloading, > as I suggested in one of my other mails. H'mm, that's interesting. As I think I've said before, for me "use" implies using something that's already sitting around waiting to be used, whereas "import" suggests an actual "go fetch" action, such as include/autoload (and then using the result). I think I'd be slightly confused by a "use" that does an autoload and an "import" that doesn't. ;) Cheers! Mike Mike Ford, Electronic Information Services Adviser, JG125, The Headingley Library, James Graham Building, Headingley Campus, Beckett Park, LEEDS, LS6 3QS United Kingdom 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] substr/array_slice in []
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: [EMAIL PROTECTED] 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
RE: [PHP-DEV] substr/array_slice in []
On 01 October 2007 13:46, Antony Dovgal wrote: > On 01.10.2007 16:32, Ilia Alshanetsky wrote: > > This was not on the table and the time of the 5.3 discussion, I for > > one think its a bit too much magic. > > Yeah, too Perl-ish for me. > Please stop this. The minutes of the Paris meeting committed to implementing this for PHP 6, and it's a much-needed feature (IMHO, of course!). If you're going to start arguing against what looks very much like a firm decision of an eminent group of PHP core developers, you need *much* better reasons than "I don't like it" or "too like language x". 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: [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] T_IMPORT vs. T_USE
On 02 October 2007 07:16, Sebastian Nohn wrote: > Andi Gutmans wrote: > > Hi Johannes, > > Our preference would be to stick to "import" because I > think the perception many will have of "use" is that it also > includes files (just based on some other languages). I don't know much about "other languages", but purely in terms of English I would expect "use" to work with something that's already lying around ready to be used, whereas "import" would go and fetch something from somewhere else and make it ready to be used in the current context. In other words, I would probably expect "import" to potentially have an implied "include", and "use" not to. But then, in the global polyglot marketplace, this argument may not have much force!! ;) 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: [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RC announcements at php.net
On 15 February 2007 16:45, Antony Dovgal wrote: > On 02/15/2007 07:42 PM, Steph Fox wrote: > > > On 02/15/2007 07:22 PM, Steph Fox wrote: > > > > Hi Tony, > > > > > > > > We've been here before. Last time it got taken off again > > > > because it led to user confusion. People didn't seem to know > > > > the difference between a release candidate and a full release; > > > > "It was official, it was on php.net." > > > > > > .. it was explained that it's not a release, but a release > > > candidate. ? > > > > I know that, you know that, but thousands don't know what a release > > candidate even is :) > > Then we should describe the difference as clear as we can. DON'T use the word release -- it may carry on being a release candidate to those in the know, but in my opinion "release" is likely to imply "official" to your general everyday user. Call it a preview, or test version, or similar. The word blocks could run something like this: Current Release: 5.2.1 For production use Preview of version 5.2.2 For testing only or maybe even as simple as Current Release: 5.2.1 Next version: 5.2.2 -- I think the use of the word "Next" is a very clear indicator of its status, and may not require further qualification. I suppose, in either case, you could leave RCx appended to the second version number -- even if you don't know what RC stands for, this is another clue that it's not a standard released version. (And serious RC testers can see when it changes, too!) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Syntactic improvement to array
> -Original Message- > From: Richard Lynch [mailto:[EMAIL PROTECTED] > Sent: 07 February 2007 02:34 > > I was specifically thinking of the sheer number of emails to > PHP-General that would result. > > Even if 90% of the newbies "get it" without any research, and > 5% more figure it out from context or reading or trying, > there's still a heck of a lot who will end up posting. OK, OK, just to show how big my +1 was in favour of this, I'll step up and say *I'M* prepared to answer all those questions -- especially as I don't believe it'll actually be anywhere near as many as you fear. Cheers! Mike Mike Ford, Electronic Information Services Adviser, Learning Support Services, JG125, The Library, James Graham Building, Headingley Campus, Beckett Park, LEEDS, LS6 3QS, United Kingdom Tel: +44 113 283 2600 extn 4730Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
> -Original Message- > From: Robert Cummings [mailto:[EMAIL PROTECTED] > Sent: 06 February 2007 16:09 > > I know how much you want to feel special, but here's the > definition of "read". Your description of how you interpret > what you see falls into this definition: Oh, no fair! You've out-pedanted a pedant! And actually I think it's very borderline whether this definition encompasses my experience or not. Regardless, it *still* takes me an order of magnitude longer to comfortably comprehend one notation over the other, whether you call it comprehending, grokking, or just plain reading. And actually, no, I'd rather not be special -- then I wouldn't be irritated by so many everyday things, or spend so much time wondering so many people have so much trouble with so many "easy" things... ;) Cheers! Mike Mike Ford, Electronic Information Services Adviser, Learning Support Services, JG125, The Library, James Graham Building, Headingley Campus, Beckett Park, LEEDS, LS6 3QS, United Kingdom Tel: +44 113 283 2600 extn 4730Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
On 06 February 2007 14:42, Robert Cummings wrote:
> On Tue, 2007-02-06 at 14:08 +0000, Ford, Mike wrote:
> > On 05 February 2007 17:29, Brian Moon wrote:
> > > That is why you have coding standards. Our doucment states that
> > > this should be written as:
> > >
> > > $a = array(
> > > 1 => array('pears', 'apples'),
> > > 2 => array('juice', 'oranges')
> > > );
> > >
> > > I believe in either syntax, proper formatting of complex data can
> > > solve the readablity problems.
> >
> > Solve, no. Alleviate, yes.
> >
> > Given the above, the layout tells me there's some kind of structure
> > going on, but I still have to actually *read* it to discover
> > that there are arrays involved (and where they start and end).
> >
> > With this version:
> >
> > $a = [
> > 1 => ['pears', 'apples'],
> > 2 => ['juice', 'oranges']
> > ];
> >
> > I can take one glance and tell there are nested arrays involved, and
> > what their scopes are -- I'd say my comprehension speed is at least
> > an order of magnitude faster!
> >
> > *That* makes this syntax a no-brainer for me, personally ;-)
>
> Ummm, you still had to read it. One "glance" just so happens to
> involve the brain grokking the content, just like reading.
No, I didn't have to read it. I had to look at it and see its shape, and I may
or may not have grokked it, but I didn't read it. I still have no idea what's
actually *in* the arrays, I just know there are arrays and how they're
structured. My brain, virtually instantaneously, goes, "Oh, brackets, nested
arrays, 2 short arrays nested in an enclosing outer one!". I don't class that
as reading, just visual comprehension.
With the long version, my thought process goes more like "Uh, oh, indentation,
must be some structure here. Can't see any obvious syntactic markers, just a
mush of characters, so better read it. 'array', uh, ok an array, what's in it?
explicit index 1 is, oh, 'array' again, ok, so we've got nested arrays,
presumably this line is a self-contained inner array? let's see, 'pears',
'apples', and, oh yes, a proper matching close parenthesis; next line similar,
explicit index 2, 'juice', 'oranges' and a close parenthesis, yup and a proper
closing parenthesis for the outer array; right, 2 short arrays nested in an
outer enclosing one." See how I've actually had to read and process *every*
*single* *word* *and* *character* on the page? See how much slower it was?
Now, that's what I call reading.
My brain may be weird and unusual in working this way, but it does so I've
become accustomed to it! I know it's off the norm in other areas (I have no
problem keeping a dozen or so PINs in my head and reliably producing the right
one without hesitation, and I generally remember personal ID, bank account and
credit card numbers without even trying) so it wouldn't surprise me to find I'm
way off the curve here too. Just permit me my little foibles, eh?
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Removing if: endif; syntax
On 05 February 2007 17:32, Brian Moon wrote: > Reading the array thread, someone mentioned having several ways of > doing things. One of their examples was the if: endif; syntax. > Forgive me if this has been discussed, but has anyone proposed > removing that for PHP6? Seems like the perfect time to do it. Its > not recommended. Editors that check PHP syntax warn about it. It > just seems like a no brainer. =) Please don't. I have several tens of thousands of lines of code using this syntax, and I really, really would not want to have to rewrite them into the less readable, less maintainable pure curly brackets form (which I hate with a passion!). Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
On 05 February 2007 17:29, Brian Moon wrote:
> Ford, Mike wrote:
> > > I don't find:
> > >
> > > $a = [1 => ['pears', 'apples'], 2 => ['juice', 'oranges']];
> > >
> > > any less readable than:
> > >
> > > $a = array(1 => array('pears', 'apples'), 2 => array('juice',
> > > 'oranges'));
> > >
> > > Quite the opposite actually :)
> >
> > Me too - I go beyond Edin on this one, as I find the
> array() version actually quite UNreadable and I have
> difficulty picking out what the individual arrays are;
> conversely, the [] version I take in at a glance.
>
> That is why you have coding standards. Our doucment states that this
> should be written as:
>
> $a = array(
> 1 => array('pears', 'apples'),
> 2 => array('juice', 'oranges')
> );
>
> I believe in either syntax, proper formatting of complex data
> can solve
> the readablity problems.
Solve, no. Alleviate, yes.
Given the above, the layout tells me there's some kind of structure
going on, but I still have to actually *read* it to discover
that there are arrays involved (and where they start and end).
With this version:
$a = [
1 => ['pears', 'apples'],
2 => ['juice', 'oranges']
];
I can take one glance and tell there are nested arrays involved, and
what their scopes are -- I'd say my comprehension speed is at least
an order of magnitude faster!
*That* makes this syntax a no-brainer for me, personally ;-)
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Syntactic improvement to array
On 04 February 2007 21:41, Zeev Suraski wrote: > At 23:27 04-02-07, Pierre wrote: > > On 2/4/07, Zeev Suraski <[EMAIL PROTECTED]> wrote: > > > At 20:14 04-02-07, Pierre wrote: > > > > Hi, > > > > > > > > On 2/4/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: > > > > > I personally find array extremely clear, in recent weeks I > > > > > had to do A LOT of JavaScript work where the array syntax > > > > > works in a manner you suggest for PHP and its a massive pain. > > > > > It does not make for a very clear code. I think the syntax > > > > > you propose is extremely confusing and we should stick to > > > > > what we have right now. > > > > > > > > If someone does not like this new syntax, he can stick to > > > > array(). It is in no way an argument to refuse the new syntax > > > > addition. > > > > > > We never believed in that approach and we're not about to start > > > now :). > > > > What I mean is that the new syntax does not any drawback besides > > hurting a couple of people eyes (I'm pretty sure that most of our > > users will like it). The changes have no effect on how your scripts > > will run, not like the numerous changes we applied in 5.x until now. > > One of the key guidelines of the language definition process of PHP > was that we don't want multiple ways of doing the same thing, and we > don't buy the argument of 'why do you care? you can still do it the > other way'. Only if the new way is significantly better than the old > way of doing things (i.e. much faster / much simpler, etc.) we > consider it. I think it's been a very good guideline and helped us a > lot in keeping PHP relatively clean for a very long time. I hadn't come across this as a stated PHP principle, and I actually don't buy it either in respect of PHP[*] or in general. It's often the case, as is becoming clear with this, that different people have widely divergent views about what is clear and easy to use/read and what isn't, and providing alternatives that suit both camps is to me a very positive move -- you'd end up pleasing far more people far more of the time than by sticking rigidly to the original option. [*] I enter into evidence here the alternative ":" block structure, which dates back further than I care to delve (but am extremely glad of); many function (or language construct) aliases, such as print/echo, exit/die; foreach in place of reset()/each(); 3 different ways (soon to be 4) to write a string literal; and even the inclusion of string slicing using (ironically) a [:] syntax on the PHP 6 feature list. > The new array syntax is arguably clearer (although some here > disagree). It's not MUCH clearer to the sense that it's a no > brainer, which makes things more complicated. In your opinion. Personally, I find the [] syntax so much clearer that I would rate it a no-brainer to include it. But, by the same token, there are also people on here who would rate it a no-brainer *not* to include it. Finally, I really don't see the argument that the [] syntax is non- obvious. If you're working with arrays at all, you have to know that [] is used to subscript out individual elements, so it seems to me abundantly clear that other uses of [] are most likely to be array- related and a quick step to the Arrays section of the manual would be in order. OK, as a mere enthusiastic user I've probably said more than I am entitled to, so I'll disappear for now...!! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
On 04 February 2007 18:38, Edin Kadribasic wrote:
> Lukas Kahwe Smith wrote:
> > Yes, you will come across it if its added.
> > I find the Javascript syntax confusing to read as well. However more
> > importantly I do not see the point in adding this sugar to save 5
> > chars.
>
> Nested arrays become very unreadable with the current PHP syntax. I
> think killing those 5 chars per array would actually make thing more
> readable.
>
>
> I don't find:
>
> $a = [1 => ['pears', 'apples'], 2 => ['juice', 'oranges']];
>
> any less readable than:
>
> $a = array(1 => array('pears', 'apples'), 2 => array('juice',
> 'oranges'));
>
> Quite the opposite actually :)
Me too - I go beyond Edin on this one, as I find the array() version actually
quite UNreadable and I have difficulty picking out what the individual arrays
are; conversely, the [] version I take in at a glance.
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Syntactic improvement to array
On 04 February 2007 07:25, Andi Gutmans wrote:
> Hi,
>
> I thought I may have brought this up a long time ago but
> couldn't find anything in the archives.
> For a long time already I've been thinking about possibly
> adding a new syntax for array(...) which would be shorter. I'd suggest
> [...]. While I am usually not in favor of having more than
> one way to do things, I think it'd look much more elegant
> especially (but
> not only) for nested arrays.
>
> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>
> $arr = [1, 2, 3]
> vs.
> $arr = array(1, 2, 3)
>
> Well enough examples given :)
> I think it's not worth doing unless there's overwhelming
> support as it's not desperately needed. But I'd be interested to hear
> people's thoughts. It seems implementation shouldn't be an
> issue but I'd have to dive a bit deeper.
Overwhelming support from here ;-D
Seriously, I personally find the [...] syntax really elegant and
intuitive, and the array(...) syntax really hard to read and
obfuscating.
A BIG +1
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Autoglobal CVs without silence -- Summary
> -Original Message- > From: Sara Golemon [mailto:[EMAIL PROTECTED] > Sent: 23 January 2007 19:02 > * - Sidenote: I refuse to call object behavior "reference by > default", > I've had too many people notice that it's not actually true Hear, hear. My favourite terminology here (and I'm sure it was in the original description, when the change was first proposed, but got lost along the way) is to say that objects are always represented by their *handle*. Then variables contain the handle, and you can have copies of the handle and references to the handle which now behave exactly as expected. I've produced a couple of major lightbulb moments in people with this explanation, but it all stems from introducing the concept of an object's handle rather than saying objects are reference by default. Please consider promoting this terminolgy to general use -- it would make it so much easier to explain certain behaviours which currently have high WTF factors. Cheers! Mike Mike Ford, Electronic Information Services Adviser, Learning Support Services, JG125, The Library, James Graham Building, Headingley Campus, Beckett Park, LEEDS, LS6 3QS, United Kingdom Tel: +44 113 283 2600 extn 4730Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Missing __toString() part
On 04 June 2006 17:18, Rasmus Lerdorf wrote:
> I think if we implement a way to get a hash from an object,
> or at least
> a unique identifier that can be used as a hash, then it should be
> implicit just like other things are implicitly converted when the
> context is clear. Of course, you should also be able to force it
> explicitly. And I don't think there is any point in doing
> this unless
> we also implicitly go the other way. From unique identifier
> to object.
> As in:
>
>class foo { function bar($arg) { echo $arg; } }
>$obj1 = new foo;
>$obj2 = new foo;
>
>$a = array($obj1=>1,$obj2=>2);
>foreach($a as $k=>$v) {
> $k->bar($v);
>}
>
> Unless this works, I am not sure there is any point to all
> this. To me
> the end goal is to make it possible to use types other than strings
> and numbers as array indices which to me also means we should
> look at doing
> the same for arrays.
Thank you Rasmus, that was my exact concern too. Unless this works as you've
specified, I'd be -1 for anything but explicit $a[(string)$b].
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Flamewar Summary
Ilia Alshanetsky wrote:
> The two topics are:
>
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1/+1
E_RECOVERABLE_ERROR has to be in as it's taken over some previously E_ERROR
situations.
It's probably too soon for E_STRICT right now, although it should be enabled in
some 5.x.0 release (with sufficient fanfare!).
> Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-0
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
[PHP-DEV] RE: #36983 [Bgs] (Meaning of "Bogus")
On 05 April 2006 21:22, crisp at tweakers dot net wrote: > ID: 36983 > User updated by: crisp at tweakers dot net > Reported By: crisp at tweakers dot net > Status: Bogus > > That last remark is taking my well-meant criticism to the extreme; > surely you will know that that was not what I meant. > 'bogus' has a negative ring to it - at least it does for me as a > non-native English-speaking person. Redirecting this to internals@ as I want to comment but don't think the public bugs forum is appropriate. As an English-native English speaker, I've long been dissatisfied with the "Bogus" status. To me, "bogus" means false, fake, fraudulent, made-up with intent to deceive; I've come to understand that it is not so strongly negative in American English, but nonetheless it still jars every time I see it. As an international project, should PHP not strongly consider changing something that has such bad connotations for a significant part of the English-speaking community? Even if you (we) avoid offending only a handful of people, is that not a worthwhile payback? Not sure what you'd use as a replacement -- "Not PHP Bug" sounds good, but doesn't really work for submissions currently bogussed for being duplicates. Thoughts? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] GOTO and/or BREAK LABEL
On 07 March 2006 09:28, Dmitry Stogov wrote:
> Please reviw and vote.
>
> 1) goto and break label
> 2) goto only (like C)
> 3) break label only (like Java)
> 4) nothing
1) +0.25
2) -1e38
3) +1e38
4) -infinity
Or, in other words, I want labelled break, and I don't want to have to emulate
it with goto.
As a user who spent several *days* tracking down a subtle bug caused by a
continue n that hadn't been altered to continue n+1, I regard labelled break as
a vital addition -- for me, it's not the frequency with which it is used (very
low, I agree), but the incredibly disproportionate maintenance burden
(potentially extremely high). In my case, I was adding a level to a heavily
nested looping/conditional structure (7 or 8 levels deep) extending over
several hundred lines, and out of the few break/continue statements that needed
adjusting I missed just one. If they had been labelled breaks, there would
have been *no* maintenance problem, and I'd have had several more days on the
next step.
If the "Java-like" syntax is seen as confusing, what about, as in some other
languages, interpolating the label into the for/foreach/while statement:
for () label {...} or for label (...) {...}
This is clearly a different animal from a goto target label: (but should be in
the same namespace, of course).
OK, I'll shut up now and slope off into a corner. (Perhaps I should design my
own language whilst I'm there ... but nah, did that decades ago and got bored
-- prefer higher-level programming these days!)
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Labeled Break (nothing at all whatsoever to do with GOTO)
On 30 November 2005 01:41, Sara Golemon wrote:
> , I'd like to turn the topic to a completely
> different language
> feature which (might) please enough people to get a rousing consensus.
>
> Actual labeled breaks. Not the break+jump that was proposed
> earlier in the
> guise of a break statement, but an actual straightforward, no
> funny-business labeled break which does no more and no less than the
> current break N; construct, but allows the use of identifier labels
> rather
> than numbers which
> may change as the result of the addition or removal of break
> containers.
Well, as this is exactly what I proposed just yesterday, I'm + several thousand
for it (modulo my fairly nonexistent karma!). I'd love to see this implemented
regardless of what happens to goto, as I completely don't care whether PHP has
goto or not.
>
> http://libssh2.org/patches/true_labeled_break.diff
>
> Usage:
>
> while FOO ($condition) {
> /* statements */
> break FOO;
> /* more statements */
> }
>
> Or a stacked example:
>
> for FOO(;;) {
> while BAR (true) {
> foreach BAZ ($arr as $val) {
> switch Foof ($value) {
> default:
> do Plop {
> break FOO;
> } while (false);
> }
> }
> }
> }
I'm fairly agnostic on which syntax to use, although I see some benefit in
distinguishing break labels from goto labels. I do quite like the "as"
suggestion -- it seems really clear and readable.
> * Labels can be repeated by siblings. I'm not married to this, and it
> certainly has WTF potential.
Mmmm -- not too sure about this. As you say, it possibly has slightly too much
WTF potential.
> * Labeled breaks also apply to continue; For example:
Of course. I thought that went without saying. ;)
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Namespaces: Technical proposal
On 29 November 2005 15:27, Sara Golemon wrote:
> > Just wondering. There's another thread about goto and labels
> > running as well. If they vote for something like:
> >
> > LABEL:while (cond) {
> >
> > }
> >
> > Wouldn't this add another technical diffuculty with using ':' as a
> > namespace seporator?
> >
> Fortunately this is another new feature so there's no old
> code to break.
> It's simply a matter of giving namespace:class precedence
> over label:expr.
>
> Though yes, preventing that duality of meaning is a good thing.
That's one reason I suggested possible alternatives such as:
while LABEL (cond) {
or
while (cond) LABEL {
I've no particular preference for any one variation -- whatever parses
easiest!
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Labeled Breaks (not the G-word)
On 29 November 2005 09:18, Bart de Boer wrote:
> I feel we're comparing apples with oranges here.
>
> Break; is for breaking out of loops. It shouldn't have anything to do
> with jumping to somewhere else. Let's say *if* PHP supported jumping
> through the code. The following should then be two different things:
>
> while (loop) {
> goto LABEL;
> }
> > LABEL
>
> while (loop) {
> break;
> }
>
> I think the question here is if we want to implement jumping
> through the
> code or not. If we do jumping in the code, this should be a
> full-fledged feature. If not, there should be no jumping. And it
> should, in my opinion, certainly not change the way break; works.
I'm completely indifferent about goto (in any form), but *PLEASE* can we have
labelled break/continue -- something like:
LABEL: while (cond):
...
break LABEL;
...
endwhile;
or
while LABEL (cond):
...
break LABEL;
...
endwhile;
or
while (cond) LABEL:
...
break LABEL;
...
endwhile;
I can't tell you the number of times I've broken my own code by adding or
removing an inner loop and failing to notice that a break/continue count needs
incrementing/decrementing. Labelled breaks are a relatively simple addition to
the syntax that would improve the programming experience out of all proportion.
Yes it's complete syntactic sugar -- it doesn't do anything you can't
currently do, just does it in a much more friendly way -- but incredibly
helpful sugar ;)
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] namespace separator poll, update
On 28 November 2005 09:50, Stanislav Malyshev wrote: > > > BUT the discussion is not only about possibility but also about > > > what you would like. The ":" for example would work if mandatory > > > whitespace would be introduced for the ternary BUT this is very > > > very bad. > > If my vote is counted (not that I asked for it :) then I vote against > all funky syntax, present and future. :: is only thing that is > obvious and somehow connected to the world of PHP as we know it now. Wow! I go home early on a Friday, and come back to a veritable php-dev flood in my Inbox! That must be the most active weekend since I started reading the list!! My point of view is similar to Stanislav's: any operator chosen should have some echo of existing syntax -- this rules out the original suggestion of \ and many of the suggested alternatives. I'm also completely against any solution that introduces new enforced whitespace, however unlikely the construct -- that just doesn't seem like "the PHP way". The two existing "class to member" operators are :: and ->, so I'd be looking at analogues of these. I'm not keen on :: itself performing double-duty here, and I hate ::: and most of the repeated-character suggestions (%%, .., **, etc.) -- especially as the single-character versions all have completely unrelated meanings. This leaves me looking for something not dissimilar to ->. It's a shame that => is already taken, as that would have done nicely. :> (or ::>), despite their smiley-ness, are actually quite clever suggestions, containing echoes of both :: and -> -- I'd be ok with either of these. Another possibility I haven't seen offered, and that has strong echoes of ->, is ~>. I can't see any conflicts here, it's sufficiently similar to be obviously related, but sufficiently different to be easily distinguished. What do people think? (Space for flame here...) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] dropping curly braces
On 17 November 2005 21:42, Rasmus Lerdorf wrote:
> Andreas Korthaus wrote:
>
> > Can someone tell me the reason for this decision?
>
> Very few people converted to using {} so the argument about
> reading old
> code doesn't really hold. If you go and grep through all the public
> code out there, pretty much none of it uses {} for character offsets.
> And internally there is absolutely no difference between {} and [].
So all of those who belived the "[] for string access is deprecated" line (or
simply prefer the visual differentiation) and have 10s of thousands of lines of
code with liberal use of $string{} are going to have to spend ages fixing that
up?
> Having two syntaxes for the same thing makes no sense,
I don't buy this -- having two ways of doing certain things is one feature that
makes PHP so great -- it increases the user base who find it easy to use, as
they can pick the method that makes most sense to them. I love the {} syntax,
so let me use it. You don't -- fine, don't use it. (I won't convert to [] --
I'll go for substr(..,..,1) instead). Another example: I hate proliferating {}
for control structures and use exclusively the if (): ... endif; form -- fine,
let me use it; your preference may be otherwise, but that's fine too. In the
end, each of us gets the PHP syntax we find easiest to use, without denying the
other his preference. What's so wrong with that?
> As far a code readability and obviousness goes, I doubt anybody would
> guess their way to the $str{5} syntax. If you were new to
> PHP and you
> were going to try to guess how you would get a character offset in a
> string, what would your first guess be?
Well, it wouldn't be [] because I'd guess that's for array access as in other
languages. I probably wouldn't guess at all, but look it up, and be very happy
to find it was {}. I remember being very, very surprised to find [] doing
double duty, and glad that {} existed as an alternative.
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] dropping curly braces
On 18 November 2005 11:48, Derick Rethans wrote:
> On Fri, 18 Nov 2005, Andreas Korthaus wrote:
>
> > Derick Rethans wrote:
> >
> > > > That's the problem - also grep does not know if [] is used for
> > > > arrays or stings. That's the same for programmers, it's often
> > > > not easy to conclude from context - that's my point.
> > >
> > > grep won't, but php -l will.
> >
> > That's true. But what about "reducing complexity"?
> >
> > Don't you think it's useful to allow a convention like {} for
> > strings and [] for arrays, so you can be sure what $str{1} means
> > without looking at any context?
>
> No.
Why not? If users demand it, why not allow them that facility?
I think the visual difference between [] for arrays and {} for string access is
a superb feature of PHP. (Personally, I'd like to see it extended to something
like $s{2:5} or $s{2,3} for longer substrings, but I've proposed that before
and been shot down so I won't mention it ;)
If {} for string access goes away, I won't be converting to [] becasue I think
a visual difference is vital -- so all my $s{$x} will be turned into substr($s,
$x, 1).
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] what happened to that new isset() like language
On 29 October 2005 22:56, Greg Beaver wrote: > For an operation as complicated as "use the first variable > that exists" > I would be most comfortable with: > > $d = first-existing: $a, $b, $c; That's a horrible syntax, but a fantastic name for a language construct to do the job. Even better might be (something like) first_isset($a, $b, $c) which tells you precisely what's happening: you get the first value that passes the isset() test. I also find the ?? / ??= suggestion very attractive - it would have been my suggestion for a suitable operator. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] $ref =& $this;
On 03 October 2005 15:41, Robert Cummings wrote: > Amazing how fast the assumption has become that passing > object values in > PHP5 is identical to passing the object by reference. It is not the > same, there are subtle differences. Either way I'm not weighing in on > the $ref = &$this issue, only that $obj = $someObj is NOT the same as > $obj = &$someObj. Yes, very true. I've mentioned before that I think PHP 5's object thingummies should be referred to as "handles" (and I'm sure I actually saw this usage in early versions of the PHP 5 or Zend Engine 2 proposals). Then, it's much clearer that: $obj2 = $obj1 gives you a copy of the object handle, but: $obj2 = &$obj1 gives you a reference to the handle. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-CVS] cvs: php-src /ext/ftp ftp.c
On 18 August 2005 13:37, Jani Taskinen wrote: > sniperThu Aug 18 08:37:25 2005 EDT > > Modified files: > /php-src/ext/ftp ftp.c > - php_error_docref(NULL TSRMLS_CC, > E_WARNING, "PHP cannot handle files greater then 2147483647 > bytes.\n"); + php_error_docref(NULL TSRMLS_CC, > E_WARNING, "PHP cannot handle files greater then 2147483647 bytes."); Whilst you're there, all these messages also need a typo correcting: "greater then" should be "greater than". Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Negative string offset support
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
On 30 October 2004 02:03, Andi Gutmans wrote:
> Nah that patch won't do because it'll effect [] also.
> It's more complicated than that. I've tried separating them in the
> past and it was annoying (and didn't have time to finish it off).
Well, according to the docs, the [] syntax is deprecated -- *if* the
[]and {} syntaxes are fully separated, and *if* functionality is
added to the {} syntax only, wouldn't this be a good time to
emphasize that deprecation and set an actual cutoff for it (such as
PHP 6.0?)?
Incidentally, I'd be about +100 (if my opinion counted for that
much!) for $string{-1}, purely for readability -- any performance
gain would be a bonus.
> At 05:51 PM 10/29/2004 -0700, Sara Golemon wrote:
> >
> > > - People might want to take this even further and request {1,3},
> > > {-3,2} and the like. (This was expressed in the past when
> > > talking about this stuff)
> > >
> > They might... and the response to that is that it's a more
> > siginificant modification/glut of the exisiting code than merely
> > allowing negative offsets. The fact is allowing negative string
> > offsets via the {} operator involves changing one line, and it's no
> > major waste of CPU cycles. Full substr()esque behavior would be
> > more bloat-intensive of course and I'd be inclined to side against
> > that.
I'd also be +several for folding substr() behaviour into the {} string
syntax -- I've often thought that if I ever have time to muck about
with the source, I'd like to make that my first little project.
(Incidentally, re another post, I'd expect $string{$m, $l} to be the
substring clone, and $string{$m:$n} to be "from offset $m to offset $n"
syntax -- and, personally, I'd like to see both. But then, I'm a
programmer with over 20 years experience, so probably not your typical
PHP user at all, and I can quite see the argument about not cluttering
up PHP with potentially obscure syntaxes. So I'll shut up now! ;)
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] GOTO operator
On 30 July 2004 18:45, Andi Gutmans wrote: > At 10:32 AM 7/30/2004 -0700, Sara Golemon wrote: > > > Secondly, I just don't understand what the sudden necessity for > > > the goto construct is when over the years we have barely ever had > > > a PHP developer asking for it. > > > > > We clearly travel in different circles. I've heard GOTO requested > > at least monthly from a different person each time and have never > > heard someone say "I can't wait till PHP5 is ready so I can use > > exceptions". > > I guess so, because I haven't hear the former but have heard the > latter :) > > Anyway goto tends to be used mostly when you need a double or triple > break, which is no problem with PHP as it is. Well, it *is* a problem in that (i) you have to count the levels in the first place and (ii) if you add another level somewhere in between, you have to *remember* that you've got that break in that now needs to be a break . I've been bitten by this a couple times and spent a good few hours debugging it each time (yes, I do write monster loops!). (This has also been mentioned in a Feature Request (not mine!): http://bugs.php.net/bug.php?id=29287) I'm just about +0 on goto, but if the part of this patch that allows labelled statements could also be applied to provide a labelled break, I'd be +several gazillion for that!! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error_handler
On 18 December 2003 23:38, Andi Gutmans wrote: > At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote: > I agree wholeheartedly, especially since one can set > reporting to E_ALL and > then ignore whatever one likes but with the way it is now > there is no way > of not being called for everything. [...] > There seems to be some opposition to this fix. I don't quite > understand why but if there is a true need, we might need an > additional INI > option such as > custom_error_handler_error_reporting_mask which would be used. How about a new optional 2nd argument to set_error_handler? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] E_STRICT
On 19 November 2003 20:34, Steph wrote: > > Not to branch the discussion, but again: if we never plan on > > removing functions, why go to the trouble of deprecating them? > > Deprecation implies it will be removed. > > > > .. and as Andi said earlier, removal without loud and clear warning > will break thousands of scripts out there. Making users do something > special if they want to use their old code, is a much kinder option. > It might also kick people into updating those scripts before the > deprecated functions actually die. IMHO, progress from deprecated to removal should go through phases of increasing warning severity: (1) the proposed E_STRICT (or E_DEPRECATED) which will emit a "silent" warning. (2) a noisy warning -- at, say, E_WARNING level, which should catch most test servers but still be maskable on production boxes. (This could even have its own new warning level of, say, E_UNSUPPORTED.) (3) removal of the feature with an E_ERROR message. My 2-pennorth would be that (1) and (3) should only happen at an X.0.0 release, with (2) ocurring somewhere suitable in between. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: E_STRICT
On 19 November 2003 06:12, Andi Gutmans contributed these pearls of wisdom: > Just a warning. > I commited your patch. Not sure about the naming but it's the > status quo for now :) > Andi > >> + case E_STRICT: >> + error_type_str = "Strict >> Standards"; >> + break; As it's a prefix to a more substantive error message, I'd go for something like "Deprecated Usage" or "No Longer Supported". (The former would also match up to an (en|dis)able_deprecated option.) Cheers! Mike -- Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: Array syntax
On 05 November 2003 18:39, Andrei Zmievski wrote: > On Wed, 05 Nov 2003, Ford, Mike [LSS] wrote: > > > > I don't think the number of characters is the main issue here -- > > it's about having a *nicer* set of characters. Personally, I'd be > > still be in favour (although not quite as much) if the proposed > > syntax were [[[1,2,3]]] -- for me, it's about having a syntax that > > shouts *ARRAY* rather than whispers it. > > And array() steps too softly for you? In comparison to [], yes. I mean, I've got used to array() and all, and I'd happily carry on using it if the consensus goes that way, but I'd also switch all my scripts to [] in a twinkling if it became permitted. (Hell, let's face it, you can get used to anything if it's the right tool for the job -- and almost anything's an improvement over spending an afternoon counting parentheses in a LISP program, curly brackets in a B program, or the number of implied REFs in an Algol68 type declaration...!) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: Array syntax
On 05 November 2003 17:19, Marco Tabini wrote: > Ford, Mike [LSS] wrote: > > On 05 November 2003 17:06, Marco Tabini contributed these pearls of > > wisdom: > > > > > > > Christian Schneider wrote: > > > > > > > Marco Tabini wrote: > > > > > > > > > > > > > $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]]; > > > > > > > > > > > > $a = array(array(1,2,3),array(1=>array(1,3,2,2), > > > > "a"=>array(array(1,2,3,4),4,array(1,2))); > > > > > > > > > > Besides my previous points, something even more abominable: > > > > > > $a = [1,2,$b[11]]; > > > > > > Is that confusing enough for you? ;-) > > > > > > What's confusing about it? > > > > The fact that $b[11] references an item of an array, while > [1,2,$b[11]] assigns values to the array $a. That's not confusing -- at least no more so than the different meanings of - in $b = -$a and $b = $c - $a. > The fact that you (and, > probably, most of us) can't tell right off the bat Bzzt! Wrong! It was because I *could* tell right off the bat exactly what it meant that I asked why it was confusing. > is a clear sign > that this is a bad idea, because it's ambiguous and confusing. And again, wrong assumption -- I asked what's confusing because to me it looks completely unambiguous and totally clear. > The same line using the current syntax, btw, would have looked like > this: > > $a = array (1,3,$b[11]); Well, I can see true enough that that has the same meaning, but for me it's harder to read and interpret. I see the () first and start assuming it's a function, before my eyes and brain have time to digest that the name of the "function" is array -- result: a moment's confusion whilst I deal with the ambiguity of using function syntax for a language construct. With the [] syntax, I see the square brackets and they immediately shout ARRAY CONSTRUCTOR at me -- result: instant understanding and I'm on to the next line of code in a flash. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: Array syntax
On 05 November 2003 16:52, Marco Tabini contributed these pearls of wisdom: > > $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]]; > > I don't know about you, but I can't even begin to count the > brackets in there... :-) At quick glance says it looks unbalanced. A count shows why: 7 [s and 6 ]s ;) I couldn't begin to suggest whether you left out a ] or have one too many [, or where...!! Cheers! Mike -- Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: Array syntax
On 05 November 2003 17:06, Marco Tabini contributed these pearls of wisdom: > Christian Schneider wrote: >> Marco Tabini wrote: >> >>> $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]]; >> >> >> $a = array(array(1,2,3),array(1=>array(1,3,2,2), >> "a"=>array(array(1,2,3,4),4,array(1,2))); >> > > Besides my previous points, something even more abominable: > > $a = [1,2,$b[11]]; > > Is that confusing enough for you? ;-) What's confusing about it? Cheers! Mike -- Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: Array syntax
On 05 November 2003 16:48, Ilia Alshanetsky contributed these pearls of wisdom: > I mean c'mon, is 5 characters that much of a problem and is > absolute code clarity not worth those 5 characters? Character > efficiency is done in Perl, where you can do things like ~= > and @_, but that makes Perl code naturally obfuscated and I do > not think that's a good way to go. I don't think the number of characters is the main issue here -- it's about having a *nicer* set of characters. Personally, I'd be still be in favour (although not quite as much) if the proposed syntax were [[[1,2,3]]] -- for me, it's about having a syntax that shouts *ARRAY* rather than whispers it. (Although the reduction in characters is handy -- particularly in a construct like ['foo' => ['bar'=>'on', 'baz'=>[2,3,5,7]], 'bedrock'=>['rubble'=>['barney', 'betty'], 'flintstone'=>['fred', 'wilma']]].) Cheers! Mike -- Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: Array syntax
On 05 November 2003 15:57, Ilia Alshanetsky contributed these pearls of wisdom: > On November 5, 2003 10:34 am, Christian Schneider wrote: >> PHP is a mix of C, Perl and other styles anyway, why deny it? >> It's strength is that it's a pragmatic and simple language >> but that doesn't mean that nothing should be changed ever. > > PHP strength (IMHO) is it's simple and clear syntax, which > allows people who > come from background in other programming languages can > quickly recognize and > get used to. Creating confusing alternate syntaxes will bring > us ever closer > to Perl 6 where there are dozens of way to do the same thing. > The end results > in a confusing and hard to read/write language that all but > the most dedicated of users refuse to use. Yes, I agree with this, but I also think that a modicum of alternatives in a few strategically chosen places also makes a language easier to use for people coming from different backgrounds and with different style prejudices -- or even just with differently-built brains! A prime example of this is the "alternative structure syntax" -- as a confirmed and long-time hater of the curly-brackets-for-everything style (as a result of many years of using it in B, c, JavaScript and others), I was overjoyed to discover the alternative :-syntax in PHP and use it exclusively in all my scripts. Contrariwise, there are some features in (and not in!) PHP that I think are pretty silly, but some of its prime maintainers defend to the death -- well, that's their opinion and I would defend to the death their right to have it, whilst nevertheless continuing to disagree with them. >> I don't want to break existing programs. And I don't care >> about range() (or even list() too much for that matter), I >> just recognize the fact the I'm using a lot of array() and it >> is both unnecessarily hard to write _and_ read. > > That's bull, 5 characters is hard to write? If anything those > 5 characters make it absolutely clear to ANYONE that the data > is an array > and not an > object or a string or some other type. When I first saw the > syntax is took me > a few seconds to realize what it does and the problem would > only be compounded when the code is found within an > pre-existing > complex script. Well, my view on that is the exact contrary -- I find the 5 letters in question and their associated parentheses easy to lose in the surrounding and very similar code, whereas the [] syntax both stands out much better against surrounding noise and is, for me, more intuitive. I think there's room for both -- I and all the other +1s would no doubt enthusiastically switch over wholesale to [], whilst you and the other -1s would stick with array(). I would have no problem with that, and to me it would be an advantage of the language that it supports such choice. Cheers! Mike -- Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: Array syntax
On 05 November 2003 08:50, Andi Gutmans contributed these pearls of wisdom: > At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote: >> I propose to add an alternative (backward compatible) short >> array creation syntax: $a = [ 1, 2, 3 ]; and $a = [ 'a' => >> 42, 'b' => "foo" ]; > > Personally I don't like having two ways of doing things. It > makes it harder > for people to read scripts. > However, I think the proposed syntax is significantly more > elegant than > today's array() which makes me think twice about the idea and > possibly making an exception to the rule. I think it'll > improve the > look of PHP > scripts. Also I think people calling methods using > call_user_method([$obj, > "method"]); will find it sexier than the array() syntax. > I guess I think it'd be interesting to see what other's think. I would be greatly in favour of the [] construct. I've used a number of languages over the years which feature this kind of syntax (a current example being JavaScript), and always found the array() syntax clumsy by comparison. (And, to answer another thread, personally I don't think it's any more "magic" than the use of [] to access individual array elements -- and the two are so clearly related that once you know what one does it would be easy to guess the meaning of the other.) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Make switch/case to type sensitive comparison in PH P 5?
> -Original Message- > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] > Sent: 26 March 2003 16:42 > To: Ford, Mike [LSS] > > > I'd really not love to see it :) Use an if-else chain of === > > > comparisons > > > instead if that's what you really need. > > > > Oh, well, fair enough -- I can live with that, although I > think it's a less > > elegant way of programming it. Still, nothing ventured > nothing gained...! > > ;) > > Mike, changing this would break all sorts of stuff, and I > think it would > confuse a lot of people. Huh??? What would it break? And I don't see how it would be confusing (in fact, in my opinion it would be exactly the reverse). Choosing between "case 0:" and (say) "case_identical 0:" would only be the same as choosing between == and === in an if statement -- it would just give the opportunity to do it using the elegant switch structure instead of the clumsy if...elseif...else chain. It just seems a shame not to have an === equivalent available within switch structures -- but, hey, it was only a speculative suggestion, I'm perfectly happy to bow to contrary opinion, and this is absolutely my last word on the subject ... ;)) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Make switch/case to type sensitive comparison in PH P 5?
> -Original Message- > From: Zeev Suraski [mailto:[EMAIL PROTECTED] > Sent: 26 March 2003 01:47 > To: Ford, Mike [LSS] > > At 03:27 25/03/2003, Ford, Mike [LSS] wrote: > >I'd love to see, say, case_identical for requesting an === > comparison, with > >case continuing as before to do an == comparison. > > I'd really not love to see it :) Use an if-else chain of === > comparisons > instead if that's what you really need. Oh, well, fair enough -- I can live with that, although I think it's a less elegant way of programming it. Still, nothing ventured nothing gained...! ;) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Make switch/case to type sensitive comparison in PHP 5?
> -Original Message-
> From: Zeev Suraski [mailto:[EMAIL PROTECTED]
> Sent: 24 March 2003 17:58
> To: Joey Smith
>
> At 05:07 24/03/2003, Joey Smith wrote:
> >I was reminded tonight of the following 'feature' of switch:
> >
> >$a = 0;
> >switch($a) {
> > case 'somestring': echo 'Bug?'; break;
> > case 0: echo 'Not a bug'; break;
> >}
> >
> >This will echo 'Bug?' with PHP 4. It seems more logical to
> have switch
> >comparing with T_IS_IDENTICAL than with T_IS_EQUAL. Is this
> something that
> >might be changed as we move to PHP 5.0?>
> It's not a 'feature', it's a feature. It's not likely to
> change, dynamic
> type conversion is one of the foundations of PHP.
Well, yes, but we have == and === for other situations, so some sort of
analogue for use in switches would be nice (I've been bitten by this one
more than once myself!).
I'd love to see, say, case_identical for requesting an === comparison, with
case continuing as before to do an == comparison.
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.3.2RC1 released.
> -Original Message- > From: Jani Taskinen [mailto:[EMAIL PROTECTED] > Sent: 13 March 2003 17:15 > > This is the first release candidate of the upcoming > maintenance release of PHP 4.3.2. > > Please download and test it as much as possible on real-life > applications to uncover any remaining issues. > > > List of additions/changes/fixes can be found here: > > > http://cvs.php.net/diff.php/php4/NEWS?login=2&r1=1.1247.2.35.4 .1&r2=1.1247.2.134&ty=h H'mm, I've just read through this; a couple of comments: (i) The entry "Fixed bug #22017 (date() does not support negative timestamps on win32)" is rather misleading, as it suggests that -ve timestamps will now work on Windows (this is likely to produce yet another bug-report blitz for this when people find it actually doesn't!) A better entry would be something like "(misleading error from date() on win32 for unsupported negative timestamps)". There might be other entries which have sub-optimal descriptions, but I didn't spot any on a brief perusal. (ii) the above URL links to a full diff between this and a previous version of the NEWS, which seems a bit odd; wouldn't http://cvs.php.net/co.php/php4/NEWS?login=2&r=1.1247.2.134 have been better? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
