Re^3: Subroutines in Dispatch Tables

Indeed.

However, there's a bit of information I haven't ('til now) divulged: In (AFAIR) both cases, despite the extensive use perl, the average perl 'reading age' was extremely low - typified by the lack ('til I introduced them) of dispatch tables anywhere (in matter of fact, the almost complete absence of other than the most simple of lookup tables) - I even encountered hashes keyed on sequential integers !!

Having introduced them [dispatch tables] and using calls of the form you exemplify, the code was considered unreadable by virtue of the implication of the use of parentheses.

However, they were eventually to adopt the structure - the final persuasive factor was the use of the form &{ ... }(...), which, they considered, would facilitate the readability of the code - since the fact that a call was being made (via a dispatch table) became explicit/obvious ... certainly to the reader of low perl 'reading age'.

A user level that continues to overstate my experience :-))

Comment on Re^3: Subroutines in Dispatch Tables Download Code

Replies are listed 'Best First'.
Re^4: Subroutines in Dispatch Tables by Tanktalus (Canon) on Sep 23, 2009 at 15:59 UTC
Generally speaking, I've preferred teaching perl developers a higher level of understanding to catering to lower levels. And, honestly, I find `$foo->()` eminently more readable than `&{ $foo }()` anyway. Of course, the problem I've had with my approach has been getting said developers to want to learn more... which generally tells me how much I want them to continue to work on the code or not. If I had any say in who worked on the perl code, there'd be much higher turnover thus far. The lack of desire to learn, nay, the desire not to learn, would be a huge factor in this.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Subroutines in Dispatch Tables
by Tanktalus (Canon) on Sep 23, 2009 at 15:59 UTC

Generally speaking, I've preferred teaching perl developers a higher level of understanding to catering to lower levels. And, honestly, I find $foo->() eminently more readable than &{ $foo }() anyway.

Of course, the problem I've had with my approach has been getting said developers to want to learn more... which generally tells me how much I want them to continue to work on the code or not. If I had any say in who worked on the perl code, there'd be much higher turnover thus far. The lack of desire to learn, nay, the desire not to learn, would be a huge factor in this.

[reply]
[d/l]
[select]