Front page | perl.perl5.porters |
Postings from August 2021
From: Darren Duncan
August 13, 2021 09:55
Message ID: firstname.lastname@example.org
On 2021-08-13 2:18 a.m., Veesh Goldman wrote:
> I think the idea of accessing $other's slots is debatable, and shouldn't be used
> as a driving factor in this syntax discussion.
> In my opinion, anyway, we shouldn't have a default way to access members of
> other objects. If that sort of sharing is needed, it should be explicit with its
> own interface.
How is accessing the slots of $other which is of the SAME CLASS debatable? That
is a completely normal and commonly done thing and is what every single other
language in existence (that I know of) does.
If you didn't have that, how would you code the interaction of 2 objects of the
same class by way of internals that code in other classes isn't supposed to see
and hence no :reader or :writer exists?
Now I can understand Corinna having a feature different from other languages
such that it is even more restrictive, however then we need to provide a way to
grant permission to see slots of other objects of the same class.
This then comes back to the proposal I made months ago where something akin to
Raku's "trusts" feature is important, where a class can enumerate what classes
can access their otherwise private things, and in this case one would declare
that a class trusts itself.
-- Darren Duncan
> On Fri, Aug 13, 2021, 12:13 Darren Duncan wrote:
> On 2021-08-13 1:02 a.m., Tom Molesworth via perl5-porters wrote:
> > On Fri, 13 Aug 2021 at 15:59, Darren Duncan wrote:
> > I believe the best way to design this is to do something that
> directly mirrors
> > the current blessed hashref approach, which is that you ALWAYS
> reference a slot
> > in terms of a subscript of an object of the type.
> > Strong disagreement from me on this - after using Object::Pad for a
> while, it's
> > painful to go back to the old approaches.
> > Slot access is a common operation, so I find the single-character Huffman
> > encoding we have now to be an excellent fit.
> I don't have a problem with the single character Huffman coding as an
> option. But it needs to be in ADDITION to something like what I proposed,
> because that Huffman option itself only gives access to slots for a single
> object of the current class while mine works for all objects of the current
> class. -- Darren Duncan