[nycphp-talk] Whats the difference between an apostrophe and a quotation
Donald J Organ IV
dorgan at donaldorgan.com
Fri Jan 11 17:59:09 EST 2008
Yes single quotes only look like apostrophe's in specific fonts, but
that is what they are.
Ajai Khattri wrote:
> On Sat, 12 Jan 2008, Jonathan Wagener wrote:
>
>
>> Hi, whats the difference between an apostrophe and a quotation in php?
>>
>
> We have single quotes, double quotes and back quotes - which do you mean?
>
> I would say apostrophe == single quote.
>
>
>
>> 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
>> ************************************
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
>
More information about the talk
mailing list