[nycphp-talk] Whats the difference between an apostrophe and a quotation
Jonathan Wagener
jonathanw at amoeba.co.za
Fri Jan 11 17:44:35 EST 2008
Hi, whats the difference between an apostrophe and a quotation in php?
Jonathan Wagener
Web Developer / Architect
Amoeba Business Solutions
Cell: +27 72 928 0513
Office: +27 21 785 1424
Web: www.amoeba.co.za
Blog: www.espresso-online.info
-----Original Message-----
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org]
On Behalf Of talk-request at lists.nyphp.org
Sent: 11 January 2008 21:16
To: talk at lists.nyphp.org
Subject: talk Digest, Vol 15, Issue 22
Send talk mailing list submissions to
talk at lists.nyphp.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.nyphp.org/mailman/listinfo/talk
or, via email, send a message with subject or body 'help' to
talk-request at lists.nyphp.org
You can reach the person managing the list at
talk-owner at lists.nyphp.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of talk digest..."
Today's Topics:
1. Re: Namespaces (John Campbell)
2. Question about explicit returns (Tod Dailey)
3. Re: Question about explicit returns (David Krings)
4. Re: Question about explicit returns (Tod Dailey)
5. Re: Question about explicit returns (Ben Sgro)
6. Re: Question about explicit returns (Michael B Allen)
----------------------------------------------------------------------
Message: 1
Date: Fri, 11 Jan 2008 12:08:05 -0500
From: "John Campbell" <jcampbell1 at gmail.com>
Subject: Re: [nycphp-talk] Namespaces
To: "NYPHP Talk" <talk at lists.nyphp.org>
Message-ID:
<8f0676b40801110908o18d742ceg22d3b6d10e9af64d at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Namespaces are supposed to be analogous to folders in the file system.
Folders are how we prevent file name collisions, and namespaces are how
we prevent function/classname collisions. If you have a bunch of files
that might have the same names as an existing file, then you just create
a new folder. If you are importing code that may have function/class
collision, then you import it into a different namespace. Unfortunately
I think the php devs don't think of namespaces in the same way, and it
looks like the 5.3 namespace implementation will lack the ability to
rename the namespace and relies on everyone using a unique namespace.
The domain convention is okay, but I would much rather be able to do
something like:
include 'dkSuperClass.php' into namespace 'foo'
It looks like the php devs are going the Java route, which ain't great
because it relies on every library being changed which will never happen
for compatibility reasons.
I would much rather have a tool that lets me solve collisions today than
a tool that requires libraries to be rewritten and agreement on a naming
convention in order for it to work.
</rant>
Regards,
John Campbell
------------------------------
Message: 2
Date: Fri, 11 Jan 2008 12:45:28 -0500
From: "Tod Dailey" <christiandailey at gmail.com>
Subject: [nycphp-talk] Question about explicit returns
To: talk at lists.nyphp.org
Message-ID:
<6232fa7e0801110945k6a993f2eiab6b7e0ec6861cf4 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The validity of one of my coding practices that I've used for awhile has
recently come under question. I've tried to listen to arguments on both
sides, and there seems to be good points on both ends, but my question
still hasn't been answered to my satisfaction.
When I'm writing a function that returns a Boolean that indicates that
the given process failed or succeeded, I declare the Boolean as a
variable at the top of the function. I feel that this makes the code
easier to read whenever/if-ever I need to come back and add further
logic conditions to that function. When I come back to the function, I
have a short list of accept by exception where I more-or-less just need
to find the point that I return true to understand the function. Verse
inline returns, such as "if ($condition !== true) return false;" that
builds a list of failure by exception. It may just be in my head that
the first method is easier to read, but that's why I'm asking for
input/options. Here are two examples.
They should both return the same value, but by different means. Please
don't be side-track by the over-all quality of code/lack-thereof.
Thanks!
public function checkForSomething($record_id) {
$result = false;
$yourObj = new SomeObject;
$result = $yourObj->loadObjectByRecordId($record_id);
if ($result === true) {as
$restrictedItems = $yourObj->getUnrestictedItems();
if (is_array($restrictedItems)) {
$result =
$yourObj->updateUnrestrictedItems(self::ObjectItemStatus);
if ($result === true) {
$this->setRecordStatusId($yourObj->getRecordStatusId());
$this->setRestrictedItemList($restrictedItems);
$result = true;
}
} else {
$result = false;
}
}
}
public function checkForSomething($record_id) {
$yourObj = new SomeObject;
if ($yourObj->loadObjectByRecordId($record_id) !== true) {
return false;
}
if (!is_array($restrictedItems = $yourObj->getUnrestrictedItems()))
{
return false;
}
if ($yourObj->updateUnrestrictedItems(self::ObjectItemStatus) !==
true) {
return false;
}
$this->setRecordStatusId($yourObj->getRecordStatusId());
$this->setRestrictedItemList($restrictedItems);
return true;
}
Once again, this is pseudo-code...
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.nyphp.org/pipermail/talk/attachments/20080111/d7b10f23/atta
chment-0001.html
------------------------------
Message: 3
Date: Fri, 11 Jan 2008 13:02:43 -0500
From: David Krings <ramons at gmx.net>
Subject: Re: [nycphp-talk] Question about explicit returns
To: NYPHP Talk <talk at lists.nyphp.org>
Message-ID: <4787AF43.5030409 at gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Tod Dailey wrote:
> The validity of one of my coding practices that I've used for awhile
> has recently come under question. I've tried to listen to arguments on
> both sides, and there seems to be good points on both ends, but my
> question still hasn't been answered to my satisfaction.
I use version 1 (can it be that you forgot to return $result at the
end?) where I declare anything that is used in the function at the top,
including booleans. I then do whatever I want/need to do in that
function and set the flag accordingly and then return the result at the
very end of the function
I see the benefits of the second version as there is a direct return
of the state and it saves a variable. Without having it tried out any
other way, I find version 1 to be easier to debug. In v1 you can
evaluate $result before retruning it, can't do that with v2. V2 is
potentially faster as it doesn't have to go through who knows how many
lines of code first before it reaches the return at the end. As soon as
a return is hit in the function the function exits and sends back the
return values.
I'd develop using v1 and then see later if optimizing using v2 makes
sense. It would be interesting to know the pros and cons for either
version that you have heard so far.
David
------------------------------
Message: 4
Date: Fri, 11 Jan 2008 13:23:15 -0500
From: "Tod Dailey" <christiandailey at gmail.com>
Subject: Re: [nycphp-talk] Question about explicit returns
To: "NYPHP Talk" <talk at lists.nyphp.org>
Message-ID:
<6232fa7e0801111023u156b0297w7fbfa63dd1b5f4fa at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
That's part of the reason I'm asking here, as the replies I've received
weren't that informative. I've heard that method #1 is a left-over
practice from C/Java programmers, and isn't necessary with PHP (??).
I've also heard the argument that returning inline values is faster, and
easier to see exactly what is being returned. That pretty much sums up
what I've heard so-far.
Christian
On Jan 11, 2008 1:02 PM, David Krings <ramons at gmx.net> wrote:
> Tod Dailey wrote:
> > The validity of one of my coding practices that I've used for awhile
> > has recently come under question. I've tried to listen to arguments
> > on both sides, and there seems to be good points on both ends, but
> > my question still hasn't been answered to my satisfaction.
>
> I use version 1 (can it be that you forgot to return $result at the
> end?) where I declare anything that is used in the function at the
> top, including booleans. I then do whatever I want/need to do in that
> function and set the flag accordingly and then return the result at
> the very end of the function I see the benefits of the second version
> as there is a direct return of the state and it saves a variable.
> Without having it tried out any other way, I find version 1 to be
> easier to debug. In v1 you can evaluate $result before retruning it,
> can't do that with v2. V2 is potentially faster as it doesn't have to
> go through who knows how many lines of code first before it reaches
> the return at the end. As soon as a return is hit in the function the
> function exits and sends back the return values.
>
> I'd develop using v1 and then see later if optimizing using v2 makes
> sense. It would be interesting to know the pros and cons for either
> version that you have heard so far.
>
> David
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.nyphp.org/pipermail/talk/attachments/20080111/80fff8f9/atta
chment-0001.html
------------------------------
Message: 5
Date: Fri, 11 Jan 2008 13:37:51 -0500
From: Ben Sgro <ben at projectskyline.com>
Subject: Re: [nycphp-talk] Question about explicit returns
To: NYPHP Talk <talk at lists.nyphp.org>
Message-ID: <4787B77F.1090601 at projectskyline.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello,
Word, I immediately feel version 2 is easier to understand. Yeah you
can't check the result, but you could step through with a debugger and
then check the *result*
$result just adds extra complexity; no need to copy the value and then
return it. Just return it at the first point you can return it.
In something more complex, maybe having 50 places you could exit that
function, in that case, save the result and do a return $result; at the
bottom. That's fine, and makes sense.
I can't comment on speed but I'd guess both these methods run pretty
close to the same speed.
I would never waste time optimizing something like this (unless I knew
it was causing a bottleneck).
- Ben
Tod Dailey wrote:
> That's part of the reason I'm asking here, as the replies I've
> received weren't that informative. I've heard that method #1 is a
> left-over practice from C/Java programmers, and isn't necessary with
> PHP (??). I've also heard the argument that returning inline values is
> faster, and easier to see exactly what is being returned. That pretty
> much sums up what I've heard so-far.
>
> Christian
>
>
> On Jan 11, 2008 1:02 PM, David Krings <ramons at gmx.net
> <mailto:ramons at gmx.net>> wrote:
>
> Tod Dailey wrote:
> > The validity of one of my coding practices that I've used for
> awhile has
> > recently come under question. I've tried to listen to arguments
> on both
> > sides, and there seems to be good points on both ends, but my
> question
> > still hasn't been answered to my satisfaction.
>
> I use version 1 (can it be that you forgot to return $result at
> the end?)
> where I declare anything that is used in the function at the top,
> including
> booleans. I then do whatever I want/need to do in that function
> and set the
> flag accordingly and then return the result at the very end of the
> function
> I see the benefits of the second version as there is a direct
> return of the
> state and it saves a variable. Without having it tried out any
> other way, I
> find version 1 to be easier to debug. In v1 you can evaluate
> $result before
> retruning it, can't do that with v2. V2 is potentially faster as
> it doesn't
> have to go through who knows how many lines of code first before
> it reaches
> the return at the end. As soon as a return is hit in the function
> the function
> exits and sends back the return values.
>
> I'd develop using v1 and then see later if optimizing using v2
> makes sense. It
> would be interesting to know the pros and cons for either version
> that you
> have heard so far.
>
> David
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
------------------------------
Message: 6
Date: Fri, 11 Jan 2008 13:56:35 -0500
From: "Michael B Allen" <ioplex at gmail.com>
Subject: Re: [nycphp-talk] Question about explicit returns
To: "NYPHP Talk" <talk at lists.nyphp.org>
Message-ID:
<78c6bd860801111056h2af89e00tac0fe4e0fc2c7c6a at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 1/11/08, Tod Dailey <christiandailey at gmail.com> wrote:
> When I'm writing a function that returns a Boolean that indicates that
> the given process failed or <snip> Verse inline returns, such as "if
> ($condition !== true) return false;" that builds a list of failure by
> exception.
Hi Tod,
I don't think it matters that much. I would rather spend time thinking
about the overall design. Just pick one technique that makes you happy
and stick to it.
This is how I would write it:
public function checkForSomething($record_id) {
$yourObj = new SomeObject;
if ($yourObj->loadObjectByRecordId($record_id)) {
if (is_array($restrictedItems =
$yourObj->getUnrestrictedItems())) {
if
($yourObj->updateUnrestrictedItems(self::ObjectItemStatus)) {
$this->setRecordStatusId($yourObj->getRecordStatusId());
$this->setRestrictedItemList($restrictedItems);
return true;
}
}
}
return false;
}
--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/
------------------------------
_______________________________________________
talk mailing list
talk at lists.nyphp.org
http://lists.nyphp.org/mailman/listinfo/talk
End of talk Digest, Vol 15, Issue 22
************************************
More information about the talk
mailing list