According to perlref for 5.8.0, the fields pragma will remain available in future versions. It's not going away -- p5p doesn't break backwards compatability that lightly. (Underneath, it may actually use locked hash keys!)
| [reply] |
You missed the main point. I would agree with you, if
- "use fields" is just a single use statement
- its user interface is stable and independent from its underlying implementation
Unfortunately, this is not the case.
If those were true statement, then you would be right, as the compatibility (when one uses the word "compatibility", always ask the question "what is the level of compatibility?") is fully granted.
However, "use fields" comes with a really clumsy interface, which is tightly coupled with its underlying pseudo hash, which has attracted lots of strong criticism, since its birth.
Logically, whether "use fields" would be there in the future is irrelevent here.
Especially if what you guessed is true that the underlying implementation would change to use lock_keys, then it makes even less sense using fields in NEW development, instead of using lock_keys directly.
| [reply] |
No, the problem with using lock_keys directly is that it's a run-time solution rather than a declarative solution. In the long run this will make it more difficult to translate to Perl 6. In other words, it's making the same mistake that pseudo hashes did, insofar as it reveals too much of the underlying machinery.
| [reply] |
All right. So you say I don't want to "use fields". Is there a standard package that provides the same easy one-shot definition of fields with inheritance? (That's what I wanted to "use fields/base" for.)
And believe me, I'm plenty aware of the wealth of modules on CPAN in Class::*. Is one of them on the way to becoming the non-deprecated replacement for "fields" in 5.10?
| [reply] |
