[PHP] Variables with - in their name
I have made the following variable in a form: (I am referring the ) \r\n"; ?> It could be wrote: Only PHP is treating the hyphen as a minus sign --- which in turn is causing a syntax error. How do I retrieve the value of this variable and over come the “minus” sign that is really a hyphen? Ron Ron Piggott www.TheVerseOfTheDay.info
Re: [PHP] Re: Switch - Case Statement Questions
On Sat, Nov 17, 2012 at 2:59 PM, Sebastian Krebs wrote: > (Beside: Was "the principle of least surprise" not a ruby-thing? ;)) No, but the Ruby (and Rails) world takes concepts like this and really runs with them. Principle of Least Astonishment has been around for quite some time, with examples known in software engineering, user interface design, and even real-world objects, It's been in the Patterns wiki for ages: http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment . -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Switch - Case Statement Questions
On Sat, Nov 17, 2012 at 3:13 PM, Sebastian Krebs wrote: > 2012/11/17 Andrew Ballard > >> On Nov 16, 2012 10:24 PM, "tamouse mailing lists" >> wrote: >> > Just a tad obscure for someone coming along >> > later >> >> Without knowing the intent of the code, it could be a headache to maintain. >> > Interesting, that you see 5 lines of code and assume, that nobody will ever > get the intent of this code ;) Of course the context is missing. I guess, > that "$count" is something like "remaining days", or such, because "7" and > "14" look like "one week" and "two weeks", respectively. Thus I wouldn't > name the variable "$count" [1], but "$remainingDays" and voila: Context is > back and so is the intent :) This was actually the thrust of my remark about obscurity. I could easily see how the refactored algorithm worked from the original code's algorithm. What was obscure was exactly the variable name $count, i.e., the meaning of the data driving the algorithm. When you know the actual meaning of data being used, the obscurity goes away. Hence: useful variable names. Again, well done, Seb. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Switch - Case Statement Questions
2012/11/17 Andrew Ballard
> On Nov 16, 2012 10:24 PM, "tamouse mailing lists"
> wrote:
> >
> > On Fri, Nov 16, 2012 at 12:41 PM, Sebastian Krebs
> wrote:
> > > Beside this it can be rewritten as
> > >
> > > switch ((int) (($count-1) / 7) {
> > > case 0: // 1-7
> > > case 1: // 8 - 14
> > > default: // above 15
> > > }
> >
> > Nice code refactoring :) Just a tad obscure for someone coming along
> > later
>
> Not only obscure, but depending on the rule being processed could be plain
> wrong. It works for the values shown so far, but what if another test is
> added to the use case in the future that doesn't fit the clever solution?
>
Like so often in our developers world many things breaks, when it comes to
new requirements.
> Without knowing the intent of the code, it could be a headache to maintain.
>
Interesting, that you see 5 lines of code and assume, that nobody will ever
get the intent of this code ;) Of course the context is missing. I guess,
that "$count" is something like "remaining days", or such, because "7" and
"14" look like "one week" and "two weeks", respectively. Thus I wouldn't
name the variable "$count" [1], but "$remainingDays" and voila: Context is
back and so is the intent :)
Of course the above code has a quite limited use-case, but that was the
requirement (for now, see KISS). If you need more, refactor/rewrite it.
[1] Even further: I was taught, that if I ever want to name a variable like
"count", "status", "type", ... I should stop and probably don't use this
name. In most cases they are used wrong. This example here is quite good:
"$count" what?
Just my 2 cents.
>
> Andrew
>
--
github.com/KingCrunch
Re: [PHP] Re: Switch - Case Statement Questions
2012/11/17 Tim Streater
> On 17 Nov 2012 at 01:33, Iñigo Medina wrote:
>
> > On Fri, 16 Nov 2012, Jim Giner wrote:
>
> >> Maybe I'm way out of touch, but when I look at php.net for the syntax
> of the
> >> switch statement I see:
> >> switch($var){
> >> case (value):
> >> (do something)
> >> case (other value):
> >> (do something else)
> >> }
> >>
> >> IN your example, you are using a switch syntax that is nothing like
> that. I
> >> think that your "case " statements are not actually evaluating the
> value of
> >> $count, but are themselves evaluating to a true value that has nothing
> to do
> >> with $count.
> >
> > That `switch` is evaluating to true each case. It's an alternative of
> using
> > if-elseif structure.
>
> It may be an alternative, but it breaks the principle of least surprise.
> If I'm looking through someone's code, and I see a switch, I expect to see
> it used as Jim described. If the writer needs a different type of logic to
> make a decision, that is what the cascaded if-elseif-elseif construct is
> for, when the tests don't fall into a simple set-of-values choice.
>
But switch(true) is not a "surprise" by itself, it becomes to, when the
cases are surprising. And the given example directly fall into "a simple
set-of-values choice", but the problem is, that switch(val) by design only
covers equality "==" and thats what this case is: A set like "(1) between 1
and 7, (2) between 8 and 14, (Default) greater than 14". On the other side
a looong if-elseif*-else-chain is often more confusing and needs
refactoring anyway.
(Beside: Was "the principle of least surprise" not a ruby-thing? ;))
>
> The job of a programmer is not to be "clever" with a view to impress those
> who follow, but to achieve the desired outcome while at the same time
> making life easy for those who follow.
>
I don't see a problem in "case ($count <= 7) or case ($count <= 14) or case
($count > 14)"? I think a developer (or maybe programmer) doesn't need to
be very clever to get the idea behind this.
>
> --
> Cheers -- Tim
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
github.com/KingCrunch
Re: [PHP] How to get a PHP bug fixed?
On Sat, Nov 17, 2012 at 1:51 AM, Enumag wrote: > Hi, there is a bug I'd like to be fixed and even a patch is available. But > there is still no reaction at all after 2 years. What else can I do to get > the bug fixed? > > https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13 > https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13 The PHP General mailing list is only for discussing the use of the language and developing in PHP, not really for the development of the language itself. Instead, you should try to discuss these things on the PHP Internals list at intern...@lists.php.net. You may also want to speak with some of the developers via IRC on EFnet #php.pecl to discuss if there is any interest in patching the bugs you've mentioned. -- Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Switch - Case Statement Questions
On Nov 16, 2012 10:24 PM, "tamouse mailing lists"
wrote:
>
> On Fri, Nov 16, 2012 at 12:41 PM, Sebastian Krebs
wrote:
> > Beside this it can be rewritten as
> >
> > switch ((int) (($count-1) / 7) {
> > case 0: // 1-7
> > case 1: // 8 - 14
> > default: // above 15
> > }
>
> Nice code refactoring :) Just a tad obscure for someone coming along
> later
Not only obscure, but depending on the rule being processed could be plain
wrong. It works for the values shown so far, but what if another test is
added to the use case in the future that doesn't fit the clever solution?
Without knowing the intent of the code, it could be a headache to maintain.
Just my 2 cents.
Andrew
Re: [PHP] Re: Switch - Case Statement Questions
On 17 Nov 2012, at 10:53, Tim Streater wrote:
> On 17 Nov 2012 at 01:33, Iñigo Medina wrote:
>
>> On Fri, 16 Nov 2012, Jim Giner wrote:
>
>>> Maybe I'm way out of touch, but when I look at php.net for the syntax of the
>>> switch statement I see:
>>> switch($var){
>>> case (value):
>>> (do something)
>>> case (other value):
>>> (do something else)
>>> }
>>>
>>> IN your example, you are using a switch syntax that is nothing like that. I
>>> think that your "case " statements are not actually evaluating the value of
>>> $count, but are themselves evaluating to a true value that has nothing to do
>>> with $count.
>>
>> That `switch` is evaluating to true each case. It's an alternative of using
>> if-elseif structure.
>
> It may be an alternative, but it breaks the principle of least surprise. If
> I'm looking through someone's code, and I see a switch, I expect to see it
> used as Jim described. If the writer needs a different type of logic to make
> a decision, that is what the cascaded if-elseif-elseif construct is for, when
> the tests don't fall into a simple set-of-values choice.
I don't see how it breaks the "principle of least surprise" (which is a new one
on me. KISS, yes. Least surprise? Wassat?). If you consider that behaviour to
be surprising the don't ever go near Perl.
A switch statement is basically saying "take this value and compare it to each
case below in the order they're presented until one matches, then execute that
block of code until you hit a break which will jump execution out of the switch
statement." I don't see how making "this value" true or false makes it any more
surprising than if it's "squirlookle."
> The job of a programmer is not to be "clever" with a view to impress those
> who follow, but to achieve the desired outcome while at the same time making
> life easy for those who follow.
I don't consider that usage of the switch statement to be "clever." It's a
valid usage of the statement which gives it a lot more power. Specifically the
ability to have the code for a given case deliberately fall through to the next
case block is worth any price of admission. And finally, in my opinion, it's
far cleaner than a succession of if/elseif/else statements, and ultimately gets
compiled to very similar opcodes.
I agree that the job of a programmer is to balance providing a fast, efficient,
correct solution and minimising maintenance issues. I see neither side being
compromised by using a switch statement in this manner, in fact I see both
sides potentially getting a boost. Just because the usage is unfamiliar or even
surprising to you doesn't mean it's wrong.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Switch - Case Statement Questions
On 17 Nov 2012 at 01:33, Iñigo Medina wrote:
> On Fri, 16 Nov 2012, Jim Giner wrote:
>> Maybe I'm way out of touch, but when I look at php.net for the syntax of the
>> switch statement I see:
>> switch($var){
>> case (value):
>> (do something)
>> case (other value):
>> (do something else)
>> }
>>
>> IN your example, you are using a switch syntax that is nothing like that. I
>> think that your "case " statements are not actually evaluating the value of
>> $count, but are themselves evaluating to a true value that has nothing to do
>> with $count.
>
> That `switch` is evaluating to true each case. It's an alternative of using
> if-elseif structure.
It may be an alternative, but it breaks the principle of least surprise. If I'm
looking through someone's code, and I see a switch, I expect to see it used as
Jim described. If the writer needs a different type of logic to make a
decision, that is what the cascaded if-elseif-elseif construct is for, when the
tests don't fall into a simple set-of-values choice.
The job of a programmer is not to be "clever" with a view to impress those who
follow, but to achieve the desired outcome while at the same time making life
easy for those who follow.
--
Cheers -- Tim
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How to get a PHP bug fixed?
On Sat, 17 Nov 2012, Enumag wrote: Hi, there is a bug I'd like to be fixed and even a patch is available. But there is still no reaction at all after 2 years. What else can I do to get the bug fixed? https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13 https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13 It looks like there is a thread about that on the PHP Bugzilla, but it is not admitted as a patch to be accepted. Maybe you might try by GitHub, making a pull request. iñ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
