php-general Digest 18 Nov 2012 06:09:28 -0000 Issue 8045
Topics (messages 319724 through 319730):
Re: Switch - Case Statement Questions
319724 by: Andrew Ballard
319726 by: Sebastian Krebs
319727 by: Sebastian Krebs
319728 by: tamouse mailing lists
319729 by: tamouse mailing lists
Re: How to get a PHP bug fixed?
319725 by: Daniel Brown
Variables with - in their name
319730 by: Ron Piggott
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Nov 16, 2012 10:24 PM, "tamouse mailing lists" <tamouse.li...@gmail.com>
wrote:
>
> On Fri, Nov 16, 2012 at 12:41 PM, Sebastian Krebs <krebs....@gmail.com>
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
--- End Message ---
--- Begin Message ---
2012/11/17 Tim Streater <t...@clothears.org.uk>
> On 17 Nov 2012 at 01:33, Iñigo Medina <imed...@grosshat.com> 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
--- End Message ---
--- Begin Message ---
2012/11/17 Andrew Ballard <aball...@gmail.com>
> On Nov 16, 2012 10:24 PM, "tamouse mailing lists" <tamouse.li...@gmail.com>
> wrote:
> >
> > On Fri, Nov 16, 2012 at 12:41 PM, Sebastian Krebs <krebs....@gmail.com>
> 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
--- End Message ---
--- Begin Message ---
On Sat, Nov 17, 2012 at 3:13 PM, Sebastian Krebs <krebs....@gmail.com> wrote:
> 2012/11/17 Andrew Ballard <aball...@gmail.com>
>
>> On Nov 16, 2012 10:24 PM, "tamouse mailing lists" <tamouse.li...@gmail.com>
>> 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.
--- End Message ---
--- Begin Message ---
On Sat, Nov 17, 2012 at 2:59 PM, Sebastian Krebs <krebs....@gmail.com> 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 .
--- End Message ---
--- Begin Message ---
On Sat, Nov 17, 2012 at 1:51 AM, Enumag <enu...@gmail.com> 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.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
I have made the following variable in a form: (I am referring the <select> )
<?php
$row['promo_code_prefix'] = 42;
$row['promo_code_suffix'] = 2;
echo "<select name=\"distributor-" . $row['promo_code_prefix'] . "-" .
$row['promo_code_suffix'] . "\" style=\"text-align: center;\">\r\n";
?>
It could be wrote:
<?php
echo $distributor-42-2;
?>
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
--- End Message ---
