php-general Digest 9 Apr 2012 13:58:06 -0000 Issue 7767

Topics (messages 317489 through 317492):

Re: php books
        317489 by: Jason Pruim
        317490 by: Jason Pruim

insteadof considered harmful
        317491 by: Szczepan Hołyszewski
        317492 by: TR Shaw

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 Apr 8, 2012, at 8:53 PM, Kirk Bailey <kbai...@howlermonkey.net> wrote:

> Revisiting said dead horse, it's interesting there is no clear  consensus of 
> opinion about what is the best book to use to learn php. Generally, you get 
> several people chiming in talking about the website. Now the website is the 
> bomb indeed, BUT IT'S NOT A BOUND BOOK! So that's a terrific answer to a 
> totally different question.
> 
> It's interesting really; it suggests there is a wide range of perspectives 
> and mindsets about wha is the best way to come to understand php. Possibly 
> this suggests something about the general mindset of the php community- wide 
> ranging individualism?

By our nature as programmers we all have very different ways to look at things. 
And if we don't like the way things are being done with the current tools we 
change it... We "fix it " 

That being said I've been considering a project that would take sample code and 
explain why it dos what it does... Make it reviewed by the big wigs here and 
possibly go as far as printing it... But definitely an ebook type thing.

Anyone interested in helping on a project like that?

--- End Message ---
--- Begin Message ---

On Apr 8, 2012, at 9:15 PM, Jason Pruim <li...@pruimphotography.com> wrote:

> 
> 
> On Apr 8, 2012, at 8:53 PM, Kirk Bailey <kbai...@howlermonkey.net> wrote:
> 
>> Revisiting said dead horse, it's interesting there is no clear  consensus of 
>> opinion about what is the best book to use to learn php. Generally, you get 
>> several people chiming in talking about the website. Now the website is the 
>> bomb indeed, BUT IT'S NOT A BOUND BOOK! So that's a terrific answer to a 
>> totally different question.
>> 
>> It's interesting really; it suggests there is a wide range of perspectives 
>> and mindsets about wha is the best way to come to understand php. Possibly 
>> this suggests something about the general mindset of the php community- wide 
>> ranging individualism?
> 
> By our nature as programmers we all have very different ways to look at 
> things. And if we don't like the way things are being done with the current 
> tools we change it... We "fix it " 
> 
> That being said I've been considering a project that would take sample code 
> and explain why it dos what it does... Make it reviewed by the big wigs here 
> and possibly go as far as printing it... But definitely an ebook type thing.
> 
> Anyone interested in helping on a project like that?

And I just realized I hijacked your thread... I apologize! My brain has not 
started up from the weekend yet.... If there is interest I'll start a specific 
thread for it! :)

*slaps his own wrist*


--- End Message ---
--- Begin Message ---
I must admit with embarrassment that after months of googling and posting 
questions to various forums I still fail to understand the purpose of the 
"insteadof" keyword and the insteadof clause.

As I currently see it, the whole insteadof clause is completely redundant. In 
a clause like this:

Foo::tweak insteadof Bar;

the "insteadof Bar" part does not specify any information that is not already 
unambiguously specified by the "Foo::tweak" part. "Foo::tweak;" already 
conveys the intention of using tweak from the trait Foo instead of any other 
trait that has a member named tweak. What if we are using seven such traits? 
Do we have to list them all after insteadof? Why do we have to explicitly 
enumerate things that we DON'T want to use?

I would like to see a small code example where the insteadof clause provides  
information that is BOTH necessary to make the program unambiguous AND cannot 
be conveyed with the simple "Foo::tweak;" syntax. Absent such example, I 
consider "insteadof" harmful because it does nothing and adds a maintenance 
chore. It should be made optional and deprecated ASAP, and removed at some 
point in the future.

Szczepan Hołyszewski

--- End Message ---
--- Begin Message ---
On Apr 9, 2012, at 7:15 AM, Szczepan Hołyszewski wrote:

> 
> I must admit with embarrassment that after months of googling and posting 
> questions to various forums I still fail to understand the purpose of the 
> "insteadof" keyword and the insteadof clause.
> 
> As I currently see it, the whole insteadof clause is completely redundant. In 
> a clause like this:
> 
> Foo::tweak insteadof Bar;
> 
> the "insteadof Bar" part does not specify any information that is not already 
> unambiguously specified by the "Foo::tweak" part. "Foo::tweak;" already 
> conveys the intention of using tweak from the trait Foo instead of any other 
> trait that has a member named tweak. What if we are using seven such traits? 
> Do we have to list them all after insteadof? Why do we have to explicitly 
> enumerate things that we DON'T want to use?
> 
> I would like to see a small code example where the insteadof clause provides  
> information that is BOTH necessary to make the program unambiguous AND cannot 
> be conveyed with the simple "Foo::tweak;" syntax. Absent such example, I 
> consider "insteadof" harmful because it does nothing and adds a maintenance 
> chore. It should be made optional and deprecated ASAP, and removed at some 
> point in the future.

See http://us.php.net/manual/en/language.oop5.traits.php and scroll down to 
conflict resolution
to see simple example. It is used to resolve method naming conflicts when 
multiple traits are used to emulate multiple inheritance.

Tom


--- End Message ---

Reply via email to