Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • by zby (4817) on 2010.08.15 4:13 (#72315) Homepage
    Thanks for the reply, what you write here is very close to nothingmuch's two essays: Immutable Data Structures [] and Immutable Data Structures (cont.) []. As a comp-sci graduate and ML programmer I like this style of programming and I understand very well these arguments, but just a few months ago, following links from Psychology of Perl talk links [], I encountered this article: Usability Implications of Requiring Parameters in Objects' Constructors [] which states:

    A comparative study was performed to assess how professional programmers use APIs with required parameters in objects' constructors as opposed to parameterless "default" constructors. It was hypothesized that required parameters would create more usable and self- documenting APIs by guiding programmers toward the correct use of objects and preventing errors. However, in the study, it was found that, contrary to expectations, programmers strongly preferred and were more effective with APIs that did not require constructor parameters.

    • That article's irrelevant.

      1) We're talking about named constructor arguments vs. attribute setters, not positional constructor arguments vs. attribute setters; we already know that named > positional for readability, maintainability, etc. in most cases. OK, now we also know that that's even true if the named arguments are spread out over several lines of code. Big deal.

      2) How people interact with constructor arguments has absolutely nothing to do with the potential complexity of your objects introduced