Front page | perl.perl5.porters |
Postings from June 2021
> On Jun 20, 2021, at 10:37 PM, Tom Molesworth <tom@binary.com> wrote:
>
[…]
> Right - but most classes provide few guarantees about internals. The guarantees for classes that are intended for inheritance are typically not much more than "it's a hashref"; the keys could change or someone could decide that it's time to revisit inside-out objects again. You could say the same about `->{key}` for any of those: unless explicitly documented, it's a side effect of the implementation. There are other classes which use blessed arrayrefs, coderefs, scalar refs or other types... each class has its own implementation details for that data.
>
> The guarantees are around things like blessed() providing the class name, ref() returning true, methods available via ->method_name, ability to check for presence of a method via ->can($method_name)... I'd expect all of these to be preserved.
>
Yeah y’all have done an excellent job with Object::Pad. I think we are in vigorous agreement from different ends of the elephant.
My point is that from the conceptual level we need to have a new Object primitive that encourage the opacity of the instance representation. The current OO system in Perl encourages the opposite in my experience.
That we need a new scope primitive that focuses on the aggregation of data as well as behavior, rather than the current package primitive that focuses on the aggregation of behavior (even though I was reminded that packages are in-fact all state and the behavior is just a special kind of state).
Object::Pad does both of these. And based on what Paul said elsewhere in this thread, the plan is to use Object::Pad as the start for implementation. I think there are some edges that need polishing … the array ref shouldn’t be exposed for example. I’d like to see an expansion of the MOP too.
-Chris
Thread Previous
|
Thread Next