-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we deprecate encapsulation violation as an API? #18
Comments
On 10/28/13 9:15 AM, David Golden wrote:
Can you provide an example of where the codebase or the documentation Thank you very much. |
The whole SYNOPSIS is full of |
If we leave things the way they are, consumers of YAML:Tiny need to Also, the current approach was specifically taken to avoid the weight of an
|
Fair enough. I'll move this off the 2.00 milestone list, but keep it as a reminder for later. |
Right now, YAML::Tiny is a blessed arrayref and encourages users to access it directly to get at documents.
In the future, Ingy has indicated that YAML will have an OO API, not a functional one.
By encouraging encapsulation violation, we lock YAML::Tiny into one and only one OO model, which severely limits future options.
For version 2, should we deprecate direct access? (E.g. overload array deref to warn. This would prepare YAML::Tiny for a future OO model not tied to direct arrayref access.
The text was updated successfully, but these errors were encountered: